GitHub is rebuilding the infrastructure underneath Git and GitHub because software development is beginning to move at machine speed. The company says developers and AI agents made 7.38 billion commits in September 2026, more than five times the volume from a year earlier, while total Git activity reached 473.3 billion events per month in August.
The change is not a new version of the Git command-line tool. It is a redesign of GitHub’s server-side repository architecture—the storage, replication, caching, coordination and maintenance systems that have to keep every push, clone, fetch, merge and CI job consistent. GitHub laid out the plan in a new engineering deep dive on agent-scale Git infrastructure.
AI agents change the workload more than autocomplete ever did
A human developer might make a few meaningful commits during a work session. A coding agent can inspect a repository, edit files, run tests, commit a checkpoint, discover a failure, make another change and repeat that loop continuously. Multiply that behavior across many agents and the repository stops seeing human-paced traffic.
GitHub says monthly pushes increased from roughly 690 million to 3.35 billion year over year. Pull-request merges grew to nearly four times their earlier volume, while GitHub Actions ran 3.26 billion times in September—more than four times the year-earlier level. The busiest repository on the platform handled roughly one billion requests in August.
This is the infrastructure version of the shift already visible in agent harness engineering and the broader agentic AI software stack. Once agents can operate independently, the constraint moves from “Can the model write code?” to “Can the surrounding development system safely absorb everything the agents do?”
GitHub’s current design couples durability and scale
GitHub currently stores repositories using a system called Spokes. A repository is kept as full copies on local disks across several file servers—five by default. Those replicas provide redundancy and let read traffic spread across multiple machines.
The tradeoff appears when writes arrive. GitHub uses a three-phase commit protocol and a quorum so that repository state remains consistent across the web interface, APIs and automation. Every durable replica participates in a write, which means adding replicas to gain read capacity can also add work and latency to pushes.
That model has worked at enormous scale—GitHub says it serves roughly a billion repositories—but the highest-activity repositories increasingly expose the ceiling. Agent fleets can generate many concurrent branches and pushes, while CI, code scanning and other systems fan each new branch tip back out into large numbers of reads.
The new architecture separates storage from compute
GitHub’s redesign separates the authoritative repository data from the workers that answer Git requests. Durable repository data will live in Azure Blob Storage, while a compute layer can scale independently and cache the data needed to serve clones, fetches and other reads.
That separation changes the failure model. If a serving worker disappears, GitHub does not need to rebuild another full durable repository replica before restoring capacity. A replacement worker can start serving and refill its cache from the durable storage layer as demand arrives.
It also means a temporary burst—such as a release, a giant CI fan-out or thousands of agents hitting one codebase—can receive more serving capacity without permanently adding another replica to every write path.
GitHub wants less coordination in the critical path
Git semantics still require agreement when a reference such as a branch tip is updated. But GitHub argues that much of the surrounding work does not need to block that update. Object storage, connectivity validation and secret scanning can run in parallel rather than expanding the critical path of every push.
Heavy maintenance operations such as repository compaction and garbage collection are also being moved away from the hosts serving live Git traffic. Separate workers can optimize repository data in the background against durable storage instead of competing directly with active pushes and fetches.
Internal tests show up to 35× higher write throughput
GitHub says the future architecture has delivered up to 35 times higher write throughput in internal benchmarks, while allowing read capacity to scale independently. That is a benchmark result rather than a blanket promise for every repository, but it shows the size of the bottleneck the company is trying to remove.
The reliability work is part of a broader response to rapidly rising AI-driven traffic. In a separate GitHub availability report, the company said AI-assisted and agentic development had become a major driver of traffic growth and described investments in Azure capacity, service isolation and removal of shared failure points.
Git itself is not being replaced
The most important distinction is that GitHub is not abandoning the familiar developer model. Branches, commits, history, pull requests, required reviews, branch protections and audit logs remain central. The company says the goal is to keep the workflows people already trust while making the infrastructure behind them tolerate far more concurrent machine activity.
That makes this less a story about replacing version control and more a story about what happens when software development stops being limited by human typing speed. If AI agents continue multiplying the number of branches, commits, tests and automated reviews, the infrastructure beneath modern coding platforms has to become as elastic as the agents using it.
Editor’s note: Usage figures and benchmark results in this article are based on GitHub’s own engineering disclosures and should be read as platform-specific measurements rather than universal Git performance numbers.
Disclaimer: BitcoinVersus.Tech publishes technology news and analysis for informational and educational purposes.
Leave a Reply