GitHub builds Git storage for thousands of agents on one repository at once
GitHub is rebuilding the storage behind Git because coding agents are driving a sharp rise in traffic. In internal tests the new architecture sustained 5,000 concurrent agents on one repository, with 7,200 pushes per second to that repo while reads stayed fast. The storage is in a limited private preview; according to GitHub a broader rollout is planned for early next year.
If you work with agentic AI yourself, this mainly shows where traffic is heading: not one developer pushing now and then, but dozens or hundreds of agents creating branches, committing and opening pull requests at the same time.
Why GitHub is doing this
In a first blog post in October GitHub describes the growth. Total Git activity rose from 218.2 billion to 473.3 billion events per month between September 2025 and August 2026. In September developers and agents made 7.38 billion commits, "more than five times as many as a year earlier". Pushes grew 4.9 times in a year, from 0.69 billion to 3.35 billion per month. The busiest repository received about a billion requests in August.
The current system, Spokes, keeps full copies of every repository on several file servers, five by default. Every copy takes part in every write. More read capacity therefore means another full copy, and every extra copy makes pushes slower.
What changes in the architecture
The second blog post of November 5 explains the new design. GitHub sums up the two principles as "minimize coordination, and decouple storage from compute".
- Only references need agreement. Git objects are immutable and named by their content. Only updating a reference, such as a branch, needs coordination. A separate replicated log handles that with compare-and-swap per reference; an update counts once a majority of replicas has recorded it.
- Storage separate from compute. Packs, indexes and read accelerators live in Azure Blob Storage. The servers that handle requests only hold disposable caches.
- Maintenance off the serving path. Separate background nodes merge packs, so the number of packs stays roughly flat as pushes grow.
The figures from the tests
| Measurement | Value according to GitHub |
|---|---|
| Concurrent agents on one repository | 5,000 (internal test) |
| Pushes per second to that repository | 7,200 (internal test) |
| Write throughput in benchmarks | Up to 35 times higher |
| Reference operations per second (Ref-CAS) | Tens of thousands |
| Current peak on the busiest repos | At most dozens of writes per second |
| Status | Limited private preview; broader rollout early next year |
These are figures from GitHub's own tests, not production measurements. GitHub aimed for at least two orders of magnitude more scale than is needed today. Two earlier designs fell short: a single write-ahead log in one blob topped out at a few hundred writes per second, and splitting references across separate blobs made writes faster but reads slower.
What this means for your work with agents
According to GitHub nothing changes in how you work: there is no maintenance window, and branch protection, required reviews, audit logs and repository visibility stay in place. You only notice the difference when you let many agents work on one repo in parallel, for example with Claude Code, Codex or Copilot. Today you hit waiting times or rejected pushes sooner; the new storage is meant to absorb that.
For small teams the practical advice stays the same: let agents work on their own branches, keep pull requests small and let a human merge. The signal also appeared in the Radar of November 7 and the briefing of November 7.
What we did not check
We could not recalculate the figures ourselves; they come from GitHub's two blog posts. Who gets access to the private preview, and on what terms, is not stated in the posts.
Checked on November 8, 2026.
This article was written with AI (Claude, Anthropic) and checked against the sources below.
Sources
- GitHub Blog, Building Git infrastructure for agent-scale development (Brian Celenza, October 6, 2026): github.blog
- GitHub Blog, Inside GitHub's new Git storage architecture (Karthik Raman, November 5, 2026): github.blog
- Announcement on X by @github: x.com/github
