- GitHub Engineering says agent-driven activity is outgrowing its Git design, because adding read capacity slows writes. It is rebuilding storage and compute as separate layers.
- Its figures: pushes rose 4.9x in a year, and internal benchmarks show up to 35x higher write throughput. These are GitHub's own numbers.
- Teams that run CI and agent fleets on GitHub should ask how push speed, merge queues and audit controls hold up as volume grows.
A ceiling that only the busiest repositories hit
GitHub Engineering describes an agent working in a tight loop. It saves its work with a commit or checkpoint after almost every step, so its pace depends on how quickly each push finishes. A pause too short for a person to feel can cap how much an agent gets done.
That is the idea behind GitHub's new post. Serving code quickly to readers is the easier problem. GitHub argues the harder one is accepting new code. The new code must survive a failure. Everything that reads the repository afterward must agree on what it now contains. Only then can the next agent or CI job start from it. Thousands of agents can work on their own branches in one repository. GitHub says that creates a steady write load converging on a single point in its architecture.
The lesson here is that agents turn a back-end design choice into a business speed limit.
What GitHub reported
GitHub's numbers show how fast the load is rising. Monthly Git events went from 218.2 billion to 473.3 billion between September 2025 and August 2026.
Commits from people and agents combined came to 7.38 billion in September. GitHub puts that at more than five times the figure a year earlier. Pull request merges grew to nearly 4x their volume of a year ago.
Automation adds to the load. GitHub Actions, its workflow service, logged 3.26 billion runs in September, over 4x the prior year. A single push can also set off a flood of copies. GitHub says test pipelines and code scanners pull the same latest commit thousands of times a minute, and that has to stay cheap.
Why more read capacity makes writes slower
GitHub's repository storage system is called Spokes. By default, five fileservers each keep a whole copy of every repository on their own local disks. Before a push moves a branch, the copies vote, and a majority must agree. GitHub uses a three-phase commit protocol for this. The vote keeps CI, the web interface and API clients looking at the same repository state.
The catch is that the same copies do two jobs. They are the durable record, and they also answer read requests. More read capacity therefore means another full durable copy. Each copy takes part in every write, so the slowest copy sets the pace of a push. The result, in GitHub's account: more read replicas, slower writes.
GitHub says the design suits most repositories. For the busiest, it calls the tradeoff a "ceiling." Each added read replica adds write overhead. Losing a replica lowers read capacity. Losing quorum halts writes.
The redesign: separate the record from the workers
GitHub says authoritative repository data will live in Azure Blob Storage, which already handles durability and replication. On top sit lightweight compute workers that cache data to answer requests. Losing one is closer to a cache miss. A replacement can start serving and fill its cache as traffic arrives.
The second change is narrowing what needs agreement. GitHub says only the branch update itself truly needs coordination. Storing objects, checking connectivity and secret scanning can mostly run in parallel. Heavy maintenance, such as compaction and garbage collection, moves to separate workers.
Treat that figure carefully. GitHub says it comes from internal benchmarks and gives no test conditions in this post. The next post in the series is promised to cover the architecture in more depth.
What leaders should ask
GitHub frames this as a rebuild done while the service keeps running. It says branch protections, required reviews and audit logs must be preserved. Those controls are what let a company have agents write code and still show who approved what.
If your engineers run agent fleets or heavy CI on GitHub, these questions are worth an hour:
First, where does your pipeline wait on a single push or a single branch? GitHub names merge queues and release trains as points where work converges on one reference. Second, how many automated jobs fetch the same commit after each push? GitHub calls this fan-out and says it has to be cheap. Third, which review and audit controls do your agents depend on, and who would notice if they changed?
Systems built for human teams were tuned for reading. Agents write constantly, and agreement is what slows them down. Teams that know where their pipeline must agree can find the limit before it shows up as a slow release.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Engineering.
