GitHub has unveiled a rebuilt Git storage architecture designed for a world in which AI agents, rather than people, do much of the pushing to a repository. The design, codenamed Project Rubicon, handled 5,000 concurrent agents working on one repository and 7,200 pushes a second in internal testing, while keeping read latency low.

The company set out the design in a post on its engineering blog on 5 November, the final part of a three-post series following an announcement at GitHub Universe. Today, the busiest repositories receive at most dozens of writes in a single second, typically in short bursts. GitHub expects those bursts to become a sustained rate within the next year as agents work in parallel around the clock, so it set a target of at least two orders of magnitude more scale.

Rubicon rests on two principles: minimise coordination, and separate storage from compute. Git objects are immutable and named by their contents, so two writers can store them at the same time without agreeing on anything. Only the reference update at the end of a push needs agreement, and that update is tiny by comparison.

Durable data now lives in two places. Packs of Git objects sit in Azure Blob Storage, while references and the list of packs making up a repository live in a separate replicated log service called Ref-CAS, short for Reference Compare-and-Swap. Each reference update is committed by a quorum, and a virtual replica that falls behind can catch up by downloading only the data it needs.

Compaction, which merges packs to keep reads fast, runs entirely in the background on separate nodes rather than on the machines serving traffic. The architecture is available in a limited private preview now, with a broader rollout planned early next year. Developers will not need to change how they push, fetch or branch.