Reason Machines Open-Sources Aspen, a Git Server Built for AI Agents

When hundreds of coding agents share one repository, the bottleneck stops being the model and starts being the plumbing. A classic Git server serializes pushes per repository and rebuilds a pack for every fetch, so load climbs with the number of clients rather than the amount of new code.

Reason Machines has now released Aspen under Apache 2.0: a single Rust binary that keeps branch state in PostgreSQL or SQLite, stores packs in S3-compatible object storage, and works with stock git clients. Until now, the comparable systems, OpenAI's Pando and GitHub's Spokes, were internal, and Cursor's Origin is part of a commercial platform. An open version changes who gets to run agent-scale version control.

We like this one. The core idea is simple and well argued: move each branch with a single compare-and-swap, so pushes to different branches never wait on each other, and serve fetches from packs that were stored once instead of recompressing for every client. If two agents race on the same branch, one gets the ordinary "fetch first" error. That's honest engineering; it keeps Git's semantics instead of inventing new ones.

The headline number is 567 pushes per second sustained for five minutes on one 8-core server, with a p99 push latency of 314 ms. Treat that carefully. It's self-reported, it was measured on a copy of git.git, and the README itself calls the figures indicative. Cursor's published Origin numbers come from a replicated cluster on a far larger monorepo, so the comparison is apples to oranges.

The weaker spots are named in the release, which we appreciate. Landing on main runs at roughly four per second, the project is pre-alpha, there are no releases or web UI, and its own 24-hour durability gate hasn't been met. For a system whose whole job is not losing code, that last item matters most. Nobody should put production history on this yet.

There's also a bigger trajectory question. A server that makes it cheap for a thousand agents to push branches also makes it cheap to generate a thousand branches nobody reviews. The trunk is still the narrow gate, and four merges a second is a human-review problem long before it's a throughput problem. I'm watching whether teams pair tools like this with stronger merge policy, or just let the branch count explode.

One more detail worth sitting with: the company says one of its own agents built Aspen from first commit to public in four days across 151 merged PRs. That's either a striking proof of the workload it's designed for, or a reason to read the durability code twice. Probably both.

OpenAI previously described Pando, an internal Git backend it built after hitting this same wall, reporting a nearly 5x cut in median push latency and close to a petabyte served daily. Aspen is an independent, open implementation of that published design, and it adds a mirror mode that sits in front of GitHub or GitLab so teams can trial it without migrating.