GitHub's Rubicon Rewrites Git Storage to Handle 7,200 AI Agent Pushes per Second

GitHub is rebuilding its Git storage backend to handle repositories updated by thousands of coding agents at machine speed. The new architecture, nicknamed Rubicon, reached 7,200 pushes per second and supported 5,000 concurrent agents on one repository in GitHub’s internal tests, while read latency remained stable.

Pushes arrive at machine speed

GitHub’s busiest repositories previously received no more than a few dozen writes per second, usually in short bursts. Human workflows tend to push completed units of work. Coding agents may commit and push after every step, creating sustained write traffic that exceeds the assumptions behind GitHub’s existing storage system.

Each push also triggers read traffic as CI runners, deployment systems, code scanners, and other agents fetch the new objects. GitHub says its write throughput grew 4.9 times year over year, increasing pressure on both sides of the request path.

Spokes tied reads to the write quorum

GitHub’s previous backend, Spokes, stored complete repository copies on multiple local disks. A three-phase commit protocol required a quorum of replicas to acknowledge each write, while those same replicas served live Git requests. Adding replicas increased read capacity and expanded the coordination required for writes.

Consensus shrinks to one pointer

The architecture described in GitHub’s technical account separates immutable Git objects from mutable references. Commits, trees, and blobs go to Azure Blob Storage. A replicated service called Ref-CAS coordinates updates to branch and tag pointers.

1. Receive the push. A virtual replica accepts the client’s Git request.
2. Store immutable objects. The replica writes commits, trees, and blobs to Azure Blob Storage, whose storage layer provides replication and durability.
3. Update the reference. Ref-CAS records the change to a pointer such as refs/heads/main .
4. Compact in the background. Separate nodes consolidate packfiles, the compressed bundles Git uses to store and transfer objects efficiently.

Git objects are content-addressed: their identifiers derive from their contents, and an existing object never changes. Many agents can therefore write objects concurrently without negotiating ownership or ordering.

Git references require coordination because they are mutable names that point to object identifiers. Ref-CAS applies compare-and-swap semantics, accepting an update only when the reference still has the expected value. Two agents racing to advance main cannot both apply the same transition, so the service preserves ordering and detects conflicts while keeping large object transfers outside the consensus path.

Virtual replicas use local disks as caches and can be replaced without losing durable repository data. GitHub can add replicas to absorb read traffic without enlarging the reference quorum, allowing compute and storage capacity to scale independently.

Benchmarks, with boundaries

GitHub reports the following results from internal testing. The figures describe controlled benchmarks and design targets, with no published production service-level guarantee.

• Up to 35 times higher write throughput than the previous architecture.
• Support for 5,000 concurrent agents on one repository.
• Up to 7,200 pushes per second to a single repository.
• Stable read latency during the reported high-write test.
• A design target of at least 100 times more single-repository scale.

Existing clients keep working

Git clients continue using the same wire protocol and repository semantics, including existing protections. The backend change increases GitHub.com’s capacity without requiring agent frameworks, CI systems, or developer workstations to adopt a new source-control API.

Workloads that spread updates across many branches gain the most room to scale:

• Agent fleets pushing frequent checkpoints to separate branches in one monorepo.
• CI, deployment, and scanning systems fetching every new commit.
• Merge queues processing a high volume of pull requests.
• Agent frameworks treating git push as a routine checkpoint.

The hot branch stays hot

Rubicon is an internal GitHub.com backend, with no self-hosted package announced. At the time of the announcement, GitHub was operating a limited private preview and planned a broader rollout for early the following year.

Shared references remain serialized coordination points. Every accepted update to main must observe the previous value, so thousands of agents pushing directly to that branch would still compete. Branch-per-agent designs distribute that contention, while merge queues continue to order final updates.

Separating storage from compute also adds operational components, including blob storage, virtual replicas, Ref-CAS, caches, and compaction workers. GitHub must monitor failures and consistency across those services while migrating repositories beneath a running platform.

Machine-paced Git changes the budget

Rubicon shows how agent workloads alter version-control infrastructure: pushes become frequent checkpoints, and every write fans out into multiple reads. Its design places immutable content in scalable object storage, confines coordination to mutable references, and makes request-serving compute replaceable.

Developers building systems between agents and Git should budget for sustained push rates, read amplification, and contention on shared branches. Git’s content-addressed object model supports broad parallelism, while its references remain the narrow resource that determines how much concurrent work can converge on one line of development.