GitHub unveils Rubicon, a git storage layer rebuilt for the agent era

GitHub published an engineering post on November 5, 2026 titled “Inside GitHub’s new Git storage architecture,” and the architecture has a name: Rubicon, a storage layer rebuilt for what the company calls agent-scale development. In internal stress tests, a single repository carried 5,000 concurrent agents on top of 7,200 pushes per second. Rubicon keeps git — objects move to Azure Blob Storage, reference updates go through a small consensus group called Ref-CAS, and reads and writes finally scale independently. It is in a limited private preview today, with a broader rollout planned for early next year.

Key points

• Rubicon was announced on 2026-11-05; the project started in May 2026, and the name nods to crossing the point of no return in agentic development. It is in limited private preview now.
• Stress tests pushed a single repository to 5,000 concurrent agents and 7,200 pushes per second — while the busiest real repository on the platform today peaks at a few dozen writes per second in short bursts.
• Objects live in Azure Blob Storage; only ref updates touch the Ref-CAS consensus group, which handles tens of thousands of ref transactions per second. Reads run on disposable virtual replicas, and compaction has left the serving path entirely.

Background

Rubicon is answering traffic that has already doubled, not a forecast. GitHub’s earlier series post from October 6, 2026 put numbers on it: monthly Git events across the platform went from 218.2 billion to 473.3 billion, monthly pushes from 690 million to 3.35 billion (about 4.9x), and the single busiest repository absorbed roughly a billion requests in August alone. One typical repository saw its daily requests quadruple between March and May, and the curve has stayed exponential since. GitHub’s own projection: within a year, today’s short bursts become sustained high-throughput load.

The driver is a changed way of working. Agents checkpoint and push after every step, so push latency caps the speed of each agent; every push then fans out into thousands of reads, as CI pipelines, deploy systems and other agents all pull the same branch tip — GitHub calls this Read Fan-out. GitHub Octoverse 2026 shows the same shift from the other side: by September, more than 40% of pull requests started as agent drafts.

The industry is not solving this one way. We covered Anthropic dropping git for its in-house Scion and OpenAI acquiring Pierre, folding its Code Storage team into Codex; The New Stack has also tracked OpenAI’s Rust-based git backend Pando and Zed’s Delta. Scion replaces git outright; Pando, Delta and Rubicon all rebuild around it.

How Rubicon works

The storage layer has three moving parts. Git objects and read-acceleration data live in Azure Blob Storage — immutable and content-addressed. References (branches, tags) and pack manifests live in Ref-CAS, Reference Compare-and-Swap: a small consensus group that stores pointers only and never holds object data. The existing Spokes layer keeps doing routing and load balancing.

A write happens in two steps. A virtual replica indexes the incoming pack and uploads it to Blob Storage, then commits one transaction to Ref-CAS. That transaction locks only the refs it touches and completes as a quorum-based compare-and-swap, so writes to different references proceed in parallel. Every commit carries an LSN; the repository version is the newest commit’s LSN, and a version-consistent read confirms it is current with a single comparison. Per the post, Ref-CAS reaches tens of thousands of ref transactions per second — the first Blob Storage design managed only a few hundred.

Reads scale separately from writes. Requests are routed to a pool of virtual replicas for the same repository; each replica’s local disk is a disposable cache, and the replica checks the Ref-CAS version to decide whether to pull new packs. Compaction runs on separate background nodes that lease shards and merge packs in size tiers, off the serving path. The lineage is on the record: the October 21 post reported Azure hosting 99.99999% of repositories (about five replicas each, two in Azure) with 3–4x higher write throughput per-reference, and the October 6 post cited internal benchmarks of up to 35x write throughput.

The facts

Rubicon’s official numbers, all vendor benchmarks or platform statistics, as of 2026-11-05:

Metric	Figure	Source and date
Concurrent agents per repo (stress)	5,000	Official post 2026-11-05
Pushes per second per repo (stress)	7,200	Official post 2026-11-05
Busiest real repo write peak	A few dozen/sec, short bursts	Official post 2026-11-05
Monthly pushes platform-wide	690M → 3.35B	Series post 2026-10-06
Monthly Git events platform-wide	218.2B → 473.3B	Series post 2026-10-06
Busiest repo, single-month requests	~1B (August 2026)	Series post 2026-10-06
Ref-CAS ref transaction throughput	Tens of thousands/sec	Official post 2026-11-05
Availability	Limited private preview	Official post 2026-11-05

Three caveats before quoting any of this. First, the 5,000 agents and 7,200 pushes come from GitHub’s own lab environment, not independent measurement, and they sit about two orders of magnitude above today’s real peak traffic. Second, the project started in May 2026; the first Blob Storage design, at a few hundred transactions per second, was thrown out for Ref-CAS. Third, GitHub has not published a preview application path, pricing or a GA date. The post is credited to GitHub distinguished engineer Karthik Raman and principal engineer Brian Celenza.

What others say

By the time Rubicon landed, the source-control fight had split into two camps. Anthropic’s Scion is the replacement route: its own post calls it “by no means a suitable replacement for git for general use,” and it is closed source — The New Stack’s write-up (Meredith Shubel, 2026-10-15) put that in the headline: “But you can’t have it.” OpenAI’s Pando stays git-compatible: the same outlet’s follow-up (Frederic Lardinois, 2026-11-02) recorded push latency cut nearly 5x and close to a petabyte of git data served per day. Rubicon stands with Pando — same protocol and clients, new storage underneath.

One line from Anthropic’s post keeps getting quoted across both outlets: “The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.” Rubicon is GitHub’s platform-scale answer to the same diagnosis. Chinese coverage came via IT之家 on 2026-11-07, which relayed the official figures verbatim and placed 7,200 pushes per second next to the few-dozen-writes reality of today’s busiest repository.

Community reaction has not formed yet: as of 2026-11-07 there is no dedicated Hacker News thread on Rubicon, against 649 points and 617 comments for Scion’s October launch. Expect skepticism and independent benchmarks only after the rollout widens.

Our take

For teams running agents against GitHub, Rubicon matters because the relief would be platform-level: faster pushes and calmer CI checkouts without leaving git, unlike Scion or Pando, which serve exactly one shop each. The more crowded the repo and the more agents on it, the more direct the benefit.

Treat the numbers as lab results, though. The 5,000 agents and 7,200 pushes are GitHub’s own stress figures; the private preview has no public application path; and the hardest case — merge-queue contention on a single trunk ref — is the one scenario for which GitHub offers a direction (per-reference consensus) but no numbers. Whether the early-2027 rollout lands smoothly is the real test. Until then, Rubicon is best read as a route map, not a shipping feature.

What to watch

One dated commitment exists: a broader rollout in early 2027, after the private preview. Two things are worth tracking: whether the wider preview brings a public application channel and quota terms, and whether GitHub publishes real figures for single-ref trunk contention — the spot where Rubicon meets the company’s own merge queue.