GitHub Redesigns Git Storage: 5,000 Agents in One Repo, 7,200 Pushes per Second

Git was created for humans. A developer makes a commit, pushes a couple of times a day, occasionally runs into a conflict with a colleague, and all of that produces a modest load on the server. Agents break this model: they write code in parallel, frequently, and without coffee breaks. GitHub has reported a test showing how far it is prepared to take this shift.

What GitHub announced

According to the official account, GitHub's new Git storage architecture supported 5,000 agents working simultaneously in a single repository during internal testing. They generated 7,200 pushes per second. At the same time, the service continued handling read requests with consistently low latency. The post itself provides no details, only a link to the article. Everything below about the system's design should therefore be read as a framework for thinking, not as a reconstruction of the architecture.

What problem this solves

Imagine a busy intersection with traffic lights designed for five cars per minute. As long as humans are driving, everything works. When 5,000 autonomous cars arrive, congestion begins. A repository faces a similar problem: every push updates references and writes objects, and under heavy contention, writes begin interfering with reads. Yet everyone needs reads: cloning, CI, reviews, and neighboring agents pulling the latest code.

The key figure here is not 5,000 agents, but the combination of two conditions: high write throughput and low read latency at the same time. Write spikes can also be absorbed by degrading everything else. The claim here is that read performance did not collapse.

Why this matters right now

Agentic workflows are rapidly moving away from the model in which one assistant helps one person. Increasingly, one person launches dozens of parallel attempts to solve a task, with each attempt living in its own branch. If the infrastructure cannot handle that load, teams run into storage, limits, and queues rather than model quality.

For product teams and founders, this is a signal: development platforms are being rebuilt for a new user that is not human. Tools that treat an agent as an ordinary client with ordinary limits will soon become bottlenecks.

What to do in practice

First, estimate how many pushes per minute your agent system actually generates. For most teams, the number is in the single digits or dozens, not thousands, so GitHub's record does not affect them yet.

Second, identify your current bottleneck. Common causes include merge conflicts in the same file, slow CI on every commit, and API limits. Storage is usually not the first constraint.

Third, separate agents' work by branches and areas of the codebase. Five thousand agents editing the same file will drown in conflicts regardless of server speed.

Fourth, watch how GitHub turns this into a product, including which plans receive it and what limits apply. For now, this is an announcement about internal testing.

Limitations

The test was internal, and its methodology was not disclosed. We do not know the repository size, push size, proportion of conflicting changes, or what “low latency” means in milliseconds. It is also unclear when the capability will become available and to whom. The right response is therefore to treat it as a signal about the direction of development, but not to build these figures into plans until independent measurements are available.

The conclusion is simple. With agents, Git is evolving from a tool for humans into a high-load system. GitHub says it is preparing for that transition. Everyone else should start considering how their processes will behave when the number of pushes increases one hundredfold.