Aspen Gives AI Agents a Git Server Built for Massive Branch Traffic

AI agents are turning Git repositories into high-traffic coordination systems, and Reason Machines has released Aspen to handle the surge. This open-source Git server targets repositories where hundreds of agents push code at once, bringing a new architecture to one of the hardest problems in agent-scale development.

Aspen is self-hostable, speaks plain Git over HTTPS and SSH, and works with existing clients without changes. Its key move is simple but powerful: writes scale per branch instead of per repository, allowing separate branches to accept pushes without forcing every client into one shared queue.

A Git Architecture Built Around Branches

A classic Git server queues every push to a repository together, then builds a fresh pack for every fetch. As the number of clients grows, server work grows with them, creating a wall for systems where agents constantly write and fetch code.

OpenAI hit that wall and built Pando. Aspen independently implements the design OpenAI described for Pando, while releasing an Apache 2.0 implementation that teams can run themselves. The system drops two assumptions that most Git servers keep: every repository needs one central write path, and every fetch needs a newly built pack.

In Aspen, each branch becomes a chain of versions stored in one PostgreSQL row. Pushes to different branches never wait for one another. If two pushes race on the same branch, one wins and the other receives Git’s usual “fetch first” error, keeping branch history clear without introducing a new client workflow.

Repository data takes two paths. Packs go to S3-compatible object storage, while branch history goes to PostgreSQL. Aspen never unpacks a push; it checks the pack, completes missing bases, and stores the result as-is. When a client fetches, Aspen streams the stored packs that client lacks and recompresses nothing.

That design also opens a path to edge delivery. Signed URLs can serve packs from a CDN, moving pack delivery away from the main Git server and toward storage infrastructure built for large volumes of repeated reads.

Small Negotiation, Reusable Packs, Faster Fetches

A push sees only the trunk branch, so negotiation stays small even when a repository contains a million branches. Background compaction merges packs 16 at a time in levels like a log-structured merge tree, which keeps long branch histories from turning every fetch into a search through thousands of separate files.

A client that falls far behind gets a few dozen packs instead of thousands. Depth-1 continuous integration fetches receive another efficiency gain: Aspen builds a tip pack once, then serves that same pack to every job.

The performance test used one 8-core server, S3 Standard, and a 4-core Postgres. The target was a copy of git.git with about 4,500 files and 75,000 commits. Aspen sustained 567 pushes per second for 5 minutes with no errors, and each push reached S3 and Postgres before Git printed “ok.”

• Median push latency reached 208 ms.
• The 99th percentile push latency reached 314 ms.
• Another client saw each push 30 ms after acknowledgement at the median.
• A depth-1 fetch storm used 1.029x the bytes of stock git upload-pack on git.git.

The project presents these figures as indicative, not as performance claims. Cursor reports up to 120 pushes per second for Origin on S3 Standard, while Origin exceeds 300 pushes per second on S3 Express One Zone. Those numbers frame the market Aspen is entering: agent systems need Git backends that absorb many small writes without making every branch compete for the same repository-wide pipeline.

From Local Experiment to Cloud Deployment

Aspen arrives as one Rust binary, giving developers a direct route from source build to a running Git service. The aspen dev command runs everything with SQLite and a local directory, which creates a compact setup for testing the architecture without PostgreSQL or object storage.

Teams can move beyond that local mode with Docker Compose, PostgreSQL, and MinIO. A Helm chart supports another deployment path, while Terraform covers AWS, Google Cloud, Azure, and Hetzner. Mirror mode can front GitHub or GitLab, letting teams trial Aspen without migrating their repositories first.

The project also offers a live demo built around a 64 x 64 pixel canvas, where each click represents one pushed commit. Behind the playful interface sits a direct demonstration of the system’s focus: many small writes arriving as Git traffic and becoming visible through stored branch history.

Per the company, one Reason agent built Aspen from its first commit to public release in 4 days, producing 151 merged PRs. That detail turns the project itself into a test case for the problem it addresses. If agents are generating code, opening branches, and pushing commits at this pace, the infrastructure beneath them must handle concurrency as a first-class requirement.

Aspen gives that emerging workflow an open-source foundation: ordinary Git clients, branch-level writes, reusable packs, object storage, and deployment options that span a laptop to cloud infrastructure. The next contest in agent development may not center only on better models. It may also depend on whether the systems around those models can keep every branch moving.

Stay connected via Google News

Follow us for the latest AI News