GitHub detailed the internals of its new Git storage architecture this month, and the test numbers are the interesting part: 5,000 concurrent agents working on a single repository, sending 7,200 pushes per second, with read traffic still serving at low latency. The project is called Rubicon, which the engineering post describes as a nod to the point of no return the industry crossed with agentic development.

It is the second rebuild of Git's backend inside one week. OpenAI published Scaling Git at OpenAI on November 2, describing Pando, the backend it built after its own monorepo started buckling under agent load. Read the two posts together and one thing stands out: two teams solved the same problem independently and gave up the same guarantee to do it. That guarantee is the part worth understanding, because it changes what your repository promises your tooling.

Why now: agents start 40% of pull requests

The 2026 Octoverse report puts numbers on the pressure. By September, developers started more than 40% of pull requests with an agent's first draft, up from 17% in March. That was 110 million agent-started pull requests in September alone, about six times March's volume. Pushes reached 17.9 billion for the year, more than 2024 and 2025 combined, and commits hit 34.3 billion.

One line in that report matters more if you maintain agent configs. Among repositories created this year, the average repo with an agent configuration file logged eight times as many commits as the average new repo without one. The busiest repositories are disproportionately the ones with a config file at the root.

GitHub's framing in the Rubicon post: the busiest repositories today receive at most dozens of writes in a single second, typically in short bursts. They expect those bursts to become a sustained rate within a year, so they designed for at least two orders of magnitude more scale.

What Rubicon changes under your repo

The design rests on one observation: very little of a push needs ordering. Git objects are immutable and named by their content, so two writers can store objects without agreeing on anything. Only the reference update needs agreement.

So pack data goes to Azure Blob Storage, part of a migration that moved 99.99999% of repositories into Azure, while references and the pack manifest live in a replicated log service GitHub calls Ref-CAS, short for Reference Compare-and-Swap. Each reference update is a compare-and-swap committed by a quorum, and a transaction locks only the references it touches. Serving happens on virtual replicas, disposable compute whose local disk is a cache that can be rebuilt at any time, while a separate fleet of compaction nodes merges packs in the background so serving nodes stay dedicated to requests.

Their first design kept every reference update in one write-ahead log blob. It was correct and reads were cheap, but every update had to win a conditional write against that single blob, and writes fell short of the target. Rubicon is in limited private preview now, with a broader rollout planned for early next year.

Pando hit the same wall first

OpenAI's monorepo ran into the same physics late last year: slow fetches, failed merges, reliability at times below 90%. The cause was Codex agents working in parallel. One engineer now has several changes in CI at once, and each push sets several jobs fetching the same commit. Pando keeps the Git protocol and the standard client, stores incoming packfiles as immutable blobs, and records a version per branch update. Median push latency dropped by nearly 5x, and the system now serves close to a petabyte of Git data per day.

The same week, OpenAI also announced it will acquire Pierre Computer Company, whose open-source Trees and Diffs libraries already power file browsing and change review in the Codex app. Storage first, then the review surface.

The guarantee both dropped: one snapshot of all refs

Both systems stopped promising a single point-in-time view of every reference in a repository. Updates to a single branch stay serializable, and two clients only contend when they push the same ref. But a client reading several branches can see them at different moments. Pando's post gives the concrete case: during a full clone's negotiation, one client may observe one branch at version 1 and a second branch at version 2, while another client sees the reverse.

If your tooling assumes coherence across refs, that is the audit item:

# fine: branch checkout, CI pinned to one ref git fetch origin && git checkout release # audit this class: assumes both tips share one snapshot git rev-parse origin/main origin/release

Mirroring tooling, release tooling that cuts from several refs atomically, anything that compares branch tips and treats the result as one moment in time. For branch-based work and CI on a single ref, nothing changes.

The second trade is packfile reuse. Pando serves the same pack bytes to many clients instead of building a fresh pack per fetch, and a client may download some objects it already has. Bandwidth is cheaper than per-fetch CPU, until you are the one paying for CI egress.

Push latency is now agent latency

GitHub lists minimized commit latency as a core design requirement and explains why: an agent waits on each push before it moves to its next step. On a human cadence a slow push is an annoyance. In an agent loop it multiplies across thousands of runs. Reads amplify the effect, since every push fans out to CI, deployment systems, and other agents fetching the new commit.

For repos that run agent fleets today, the practical pattern already matches the architecture:

# one branch per run: per-ref updates don't contend git push origin HEAD:refs/heads/agent/$RUN_ID # merges into trunk still serialize, so batch them

Storage scales, review doesn't

Rubicon scales the repository layer. It does nothing for review capacity. Octoverse notes that agent-started pull requests change multiple files more often, about 87% of the time versus 79% for pull requests without detected agent involvement. On the Latent Space podcast recorded after his Universe keynote, Jay Parikh described his own tinkering repos where he skips pull requests entirely, and said GitHub intends to keep concepts like the PR configurable rather than mandatory.

That leaves the trust decisions sitting in config, where they already live. Which commands an agent may run without asking, the question Copilot's assisted permissions now answers with a model. And what your agent writes into files that later get committed, the failure mode behind the don't-ask-again settings file that carried 1,379 secrets into public repos.

What to actually do

  • Nothing migrates. Git stays Git, same client, same commands, same protections.
  • Audit anything that reads multiple refs and assumes one coherent snapshot.
  • If agents push to your repos, give each run its own branch and batch merges into trunk.
  • Watch fetch volumes if you pay for egress, since shared packs can redeliver objects you already have.
  • Treat the headline numbers as vendor-reported. The 5,000 agents and 7,200 pushes per second come from internal testing, and Pando is not available to run today. The design reasoning is the transferable part.