Reason Machines Open-Sources Aspen: A Git Server Built for AI Agents

AI Agents are moving from demos into production environments, but the way they use Git is fundamentally different from human developers. Aspen, open-sourced by Reason Machines, is a self-hosted Git server designed precisely for this scenario. It follows the design approach of OpenAI's Pando, and in the company's internal testing, a single 8-core server sustained 567 pushes per second.

Why AI Agents Need a Dedicated Git Server

Most existing Git hosting services are designed around human collaboration: code review, branching strategies, and permission models all assume the operator is an engineer with judgment. When large numbers of autonomous Agents read and write to repositories simultaneously, the bottlenecks in these designs quickly become apparent—high-frequency, short bursts of pushes, concurrent branch creation, and intensive metadata queries all overwhelm servers optimized for human-paced workflows.

Aspen's positioning is therefore not "yet another Git hosting platform," but a foundational component for Agent infrastructure. Its lineage from OpenAI's Pando suggests a growing industry consensus on dedicated version control infrastructure for Agents: code changes produced by Agents need an independent, self-hostable, load-testable channel rather than being squeezed into human workflows.

What is Pando: OpenAI has publicly described Pando, its internal approach to Agent-oriented version control. The core idea is to treat Git repositories as a storage layer that programs can access concurrently at scale, rather than as a human collaboration interface. It emphasizes optimization for high-frequency small commits, parallel branches, and metadata queries, while de-emphasizing traditional code review workflows. Aspen follows this design orientation, meaning it is not simply a wrapper around an off-the-shelf Git service, but rather makes targeted adjustments at the protocol and storage layers for how Agents access repositories. Understanding Pando helps clarify Aspen's positioning: it is more like a "write channel" in Agent infrastructure than another human-facing GitHub alternative.

What 567 Pushes Per Second Means

The performance figure Reason Machines published is a sustained 567 pushes per second on a single 8-core server. The key point here is not the absolute number but the word "sustained": Agent write patterns tend to be bursty and dense, and short-term peaks are easy to inflate, but it is long-duration stable throughput that determines production viability.

Worth noting for comparison: this result comes from the company's own testing, not a third-party benchmark. For teams planning to self-host Aspen, actual performance will be affected by disk I/O, network topology, the number of concurrent Agents, and other factors. It is advisable to reproduce and validate under your own hardware conditions before doing capacity planning.

The cost of push in the Git protocol: a single git push is not a single network request but involves multiple stages including object packing, transfer, server-side unpacking, reference updates, and hook execution. In high-frequency push scenarios, the server often becomes a bottleneck on reference lock contention, object storage writes, and hook scripts. Therefore "pushes per second" measures the throughput of the complete write path, not just network bandwidth. 567 per second means the server has made significant optimizations in object handling and reference updates, which is also a key architectural difference between an Agent-dedicated Git server and general-purpose hosting services.

The Control That Self-Hosting and Open Source Provide

Choosing open source and self-hosting has practical significance for Agent scenarios. Code written by Agents and metadata they commit may contain sensitive context; keeping version control within your own network avoids external dependencies. At the same time, teams can customize authentication, rate limiting, and audit policies for Agent access patterns.

Aspen is still an early-stage project, and its ecosystem tooling, client compatibility, and operations documentation will take time to mature. It is better suited to teams that have already hit Git bottlenecks in multi-Agent pipelines and have the capability to maintain the service themselves, rather than ordinary users looking for an out-of-the-box hosted service.

Security boundaries of self-hosting in Agent scenarios: during operation, Agents write context such as prompts, tool call results, and internal paths into commit messages and file contents. Once this data flows to an external hosting service, it may fall outside the team's data governance scope. Self-hosting keeps repositories, authentication, and audit logs within the team's own network, enabling fine-grained rate limiting and traceability for Agent access. Open source also means the server-side behavior can be audited and hooks and authentication logic modified as needed, which is especially important for teams requiring compliance review. The trade-off is that operational responsibility shifts to the user, including backups, upgrades, and troubleshooting.

Key Takeaways

• Aspen is a self-hosted Git server for AI Agents, released as open source.
• Its design follows OpenAI's Pando approach, reflecting growing multi-party interest in dedicated version control infrastructure for Agents.
• In the company's internal testing, a single 8-core server sustained 567 pushes per second.
• The performance figures come from internal testing and should be validated in your own environment before deployment.
• The self-hosted model gives teams control over authentication, rate limiting, and auditing of Agent code changes.

FAQ

What is the difference between Aspen and an ordinary Git server?

It is optimized for the high-frequency, concurrent, and dense read/write patterns of Agents, rather than being designed around human code review workflows.

Can 567 pushes per second be used as a basis for selection?

It can serve as a reference order of magnitude, but since the figure comes from vendor self-testing, actual performance depends on hardware and network conditions. It is recommended to run your own load tests.

What kind of team is suited to using Aspen?

Engineering teams that already run multi-Agent pipelines, have encountered Git write bottlenecks, and have the capability to operate self-hosted services.