One repository. Three months. Traffic multiplied by four. When GitHub engineers watched a single repo balloon from 44 million to 181 million daily requests, they reached an uncomfortable conclusion: the storage layer powering the world’s largest code host was never designed for AI agents. Project Rubicon is their response — a ground-up rebuild of Git’s storage architecture that handled 7,200 pushes per second in internal tests. Broad rollout lands in early 2027.
Spokes Was Never Built for This
GitHub’s old storage system, Spokes, ran on a three-phase commit protocol. Every push required quorum acknowledgment from multiple replicas before completing. Principal engineer Brian Celenza put it plainly: “every push is bounded by the slowest replica required for quorum.” That design made sense when developers pushed code occasionally. It did not survive AI agents pushing code constantly.
The numbers tell the story. Platform events grew from 218 billion to 473 billion monthly in just one year. September 2026 logged 7.38 billion commits — five times September 2025. Full-year commits are pacing toward 14 billion, a 14x increase, with nearly all growth from automated agents. GitHub logged ten performance incidents in April 2026 and nine more in May. Three systemic failure patterns emerged in every incident: cascading failures from tight service coupling, no way to shed load from misbehaving clients, and insufficient operator controls during active incidents.
Spokes also had a structural trap: adding read replicas slowed writes, and losing quorum halted writes entirely. Scaling up made the problem worse.
The Key Insight Behind Rubicon
Git objects — file blobs, trees, commits — are immutable and content-addressed. Two agents writing identical content produce identical hashes. There is no conflict and no coordination needed. The only thing requiring coordination is a branch pointer update: when a ref moves from one commit hash to another, something has to serialize that.
Rubicon splits these two concerns apart entirely.
Immutable objects now live in Azure Blob Storage. Cloud storage handles replication automatically — no quorum logic, no slow replica bottleneck. Before a commit is finalized, the virtual replica uploads the pack to Blob Storage, ensuring objects exist before any reference points to them.
Ref-CAS — a new dedicated Compare-and-Swap service — handles only reference updates. With coordination scoped to individual ref changes rather than entire repository state, throughput jumps to tens of thousands of operations per second, up from the mid-hundreds Spokes achieved.
Virtual Replicas are disposable compute nodes that handle reads and writes. They scale horizontally as repository traffic grows and rebuild their local caches on demand. Compaction — merging packs and garbage collecting — runs in background nodes that never block incoming writes.
What 7,200 Pushes Per Second Actually Means
Internal tests ran 7,200 pushes per second to a single repository with 5,000 concurrent agents, while read latency stayed consistently low throughout. That is roughly 35 times the throughput Spokes could deliver. For context: one of GitHub’s heaviest customers grew from 44 million to 181 million daily requests in three months. Rubicon handles that trajectory without special-casing or repository migrations.
What Changes for Developers (Mostly Nothing Yet)
Rubicon is currently in limited private preview. Broad rollout is expected in early 2027. No code changes are required — git push, git fetch, and git branch work identically. The upgrade is entirely invisible to the developer workflow.
What comes next is more interesting. GitHub is building on Rubicon to deliver features the old architecture could not support: a “work without a clone” mode for agents that do not need a full local checkout, and an atomic commit API that lets agents commit multiple files without intermediate broken states. If you are building agent systems today, implement exponential backoff on push failures for large fleets — that best practice does not change until atomic commits arrive.
The Bigger Picture: Git Wasn’t Built for Agents
GitHub named this project Rubicon deliberately — “a nod to the point of no return the industry crossed with agentic development.” Rather than replace Git, GitHub bet on evolving it. That is a defensible call. Git’s object model is actually well-suited for agents; only the reference coordination layer needed rethinking.
Compare this to Anthropic’s response: they built a custom Git replacement for AI agents handling 30,000 merges per day, abandoning Git entirely. GitHub chose backward compatibility over the clean-slate approach. With a billion repositories on the platform, that was probably the only realistic option — but it also means every existing Git tool, CI pipeline, and agent integration keeps working on day one of the rollout.
Git was designed for humans committing occasionally. Rubicon is Git redesigned for machines committing constantly. The rest of the dev toolchain is following the same path.
