GitHub is rebuilding Git's core for a world of AI agents

GitHub is rebuilding the Git infrastructure underneath every repository on the site, and it is doing the work while the service keeps running. The company says the driving force is agentic development, where fleets of AI agents commit and checkpoint in tight loops alongside human engineers.

The numbers behind the rebuild

Total Git activity on GitHub grew from 218.2 billion events a month in September 2025 to 473.3 billion in August 2026, more than doubling in a year. In September 2026 alone, developers and agents made 7.38 billion commits, over five times as many as a year earlier. Pushes rose 4.9 times year on year, from 0.69 billion to 3.35 billion a month, and GitHub Actions ran 3.26 billion times in September, more than four times its volume a year before.

The distribution is brutally uneven. The busiest single repository on GitHub took roughly a billion requests in August 2026, and pull request merges across the platform have grown to nearly four times their earlier volume.

Why writes are the hard part

Reads scale cheaply. Caching and replicating the same bytes to more clients is a well-worn problem, and GitHub leans on it. Writes are different, because every push has to be stored durably and made consistently visible before the next agent or CI job builds on top of it.

GitHub's current design keeps a full copy of each repository on the local disks of five fileservers by default, and a three-phase commit protocol with a quorum keeps CI, the web UI and API clients in agreement. That serves more than a billion repositories, but the mechanism for durability is also the mechanism for scale: every replica takes part in every write, so adding read capacity adds write overhead, losing a replica cuts read capacity, and losing quorum stops writes altogether.

An agent in a loop commits after nearly every action, so its speed is bounded by how fast one push completes. Latency a human would never notice becomes the bottleneck, which is why GitHub describes the problem as thousands of agents working on their own branches, all converging on a single reference.

Separating storage from compute

The new design splits the two jobs apart. Authoritative repository data moves to Azure Blob Storage, while lightweight compute workers cache data to serve requests, so read capacity can grow without adding durable copies to every push. Maintenance such as compaction and garbage collection moves off the serving path onto separate workers that run against durable storage.

Only the reference update itself has to be agreed, GitHub argues; storing objects, validating connectivity and secret scanning can mostly proceed in parallel. In internal benchmarks the company claims up to 35 times higher write throughput, with read capacity scaling independently. Losing a compute worker becomes closer to a cache miss than a rebuild, and capacity can be added or removed around bursts such as a release or a new agent fleet coming online.

Our opinion

The number worth sitting with is 7.38 billion commits in a month. That is not a growth curve a mostly human platform produces, and it is the clearest signal yet that agent traffic is becoming the ordinary load rather than a novelty bolted on top. GitHub's own framing is telling: the three-phase quorum that kept repositories consistent is the same thing making pushes slow, because one mechanism is doing reliability and scale at once.

Moving the authoritative copy to object storage is a sensible answer to that coupling, and doing it with no maintenance window is the harder half of the promise. It also concentrates a great deal of the world's code on one cloud's storage layer, which is worth watching: the read path now recovers like a cache miss, but the durability guarantee behind it is someone else's product page.