Aspen: an open-source Git server for agents handles 567 pushes per second

If you have run several coding agents against the same repository, you know the pain: they push frequently, concurrently, and without any discipline. Conventional Git servers were designed for humans who commit a couple of times an hour. Agents, by contrast, can each do it dozens of times per minute, turning the server into a bottleneck. Startup Reason Machines (YC F26) is proposing a solution: Aspen, an open-source Git server built specifically for this kind of workload.

What is being claimed

The authors highlight one headline number: a single 8-core machine handles 567 pushes per second to the same repository. The second part of the claim matters too: every push is persisted before git prints "ok." In other words, the speed does not come at the expense of reliability: if the client receives confirmation, the data has already been written.

The third point is perhaps the most practical: the client remains standard git. There is nothing to install — no proprietary plugins, separate SDK, or custom protocol. The agent still runs git push, just to a different address.

Why this matters specifically for agents

Consider a typical agent setup: an orchestrator launches 50 parallel workers, each of which takes a task, edits code, and pushes a branch or an intermediate state. Humans barely participate in this setup, while Git serves as the log and synchronization point. Contention over a single repository means locks for updating references, writing objects, and running integrity checks. At high volumes, all of this becomes a throughput ceiling.

For now, all we have is a claim in a post, but the direction is clear: Git used as working memory for agents requires a different server architecture from Git used as a collaborative development tool.

Limitations and caveats

At this point, we essentially have a single post on X with one metric. It is unclear exactly how the test was configured: the size of the pushes, the disks used, the number of simultaneous clients, and whether multiple pushes conflicted on the same branches. Achieving 567 pushes per second with empty or tiny commits is very different from achieving the same figure with real changes in a monorepo. It is also unclear how Aspen handles hooks, access controls, code review, and the integrations GitHub and GitLab users expect. The project is young, and it is too early to expect product maturity.

What to do in practice

If you are building a multi-agent system and Git has become a bottleneck, it is worth spending an evening spinning up Aspen, running your real workload, and comparing it with your current server. Look beyond peak throughput: measure push latency under your workload, behavior during conflicts, and recovery after a failure. If you are building an agent platform, pay attention to the broader trend: infrastructure around agents is beginning to be rewritten around their usage patterns, and Git hosting for machines will probably become a distinct niche. Because the client remains standard, the experiment is inexpensive: switching the remote takes a minute, and rolling back is just as quick.