Aspen: scaling agentic commits beyond what Git was built for

Git was built for people. A person pushes a few times a day. An agent pushes every few minutes, and a team running a few hundred of them turns one repository into a firehose: hundreds of branches moving at once, and a CI fetch after every push.

A classic Git server doesn’t keep up. It takes every push to a repository through one queue, so a push to your branch waits on pushes to everyone else’s, and it builds a fresh pack for every clone and fetch, compressing the same history again for each client. A pack is Git’s file format for shipping objects (files, directories and commits) in bulk. The server’s work grows with the number of clients, not with the amount of new code.

OpenAI hit this wall with their monorepo and wrote up how they got past it in “Scaling Git at OpenAI”. Their answer is Pando, an internal Git backend.¹ We liked the design enough to build it in the open. Today we’re releasing Aspen, an independent, open-source implementation that anyone can run, under the Apache License 2.0.²

Aspen speaks plain Git over HTTPS and SSH, so nothing changes for the client: git push and git clone work as they always have. The difference is all on the server.

Two things we gave up

A Git server has to scale two ways: many writers pushing to different branches, and many readers fetching the same history. Following Pando, Aspen drops two guarantees most Git servers treat as sacred.

One snapshot of every branch Each branch is a chain of versions in Postgres, and moves on its own. A push uploads its pack, then moves its branch with one compare-and-swap on a single row: “move this branch from commit A to commit B, but only if it still points at A.” Pushes to different branches never wait for each other. Two pushes to the same branch race on that row, and one wins cleanly; the other gets Git’s usual “fetch first” and rebases. The cost: a reader looking at several branches may see each one at a slightly different moment. Agents don’t care.

A custom pack for every client Aspen never unpacks a push. It checks the pack, fills in the objects Git left out because the server already had them, and stores it in object storage (S3, GCS, Azure Blob or a plain directory) exactly as it arrived. When someone fetches, Aspen works out which stored packs hold what they’re missing and streams those, recompressing nothing. It can also hand out signed URLs so clients download the packs straight from a CDN.

A canvas anyone can push to

To show Aspen to people rather than to a load generator, we put it behind place.reasonmachines.com: a shared 64 × 64 pixel canvas with no sign-in. Every pixel is a file in a Git repository, and clicking a tile makes one commit and one push to Aspen. A bot merges everyone’s branches into main, and main is mirrored to GitHub, whose README shows the canvas live.

You can paint from a terminal too: clone it, change a tile’s file and git push. Or press Copy prompt on the page and hand the prompt to Claude Code, Codex or any coding agent; it asks what you want to paint and where, shows you a preview, and pushes once you say go.

git clone --depth=1 https://place.reasonmachines.com/canvas.git
cd canvas && printf '#3690ea\n' > tiles/10_20.txt
git add tiles && git commit -m paint && git push origin HEAD:paint/you

A push only sees trunk

When you push, a normal server first lists every branch it has, so your client can skip objects the server already holds. With a million branches, that list alone is enormous, and the pack your client builds depends on whichever branches happened to be listed, so nobody else can reuse it.

Aspen lists only the trunk branch. Your push then carries everything since trunk, and anyone who has trunk can fetch your branch with that one pack. Pushes get a little larger; the conversation stays the same size no matter how many branches exist. The one visible difference: git push --force and --delete need an extra -o force.

Compaction

If every push stores one small pack, a client that’s a day behind needs tens of thousands of them. So Aspen merges packs in the background, sixteen at a time, in levels, the way a log-structured merge tree compacts its files. A fresh clone gets a few large packs, and a client that’s nearly current gets a few small ones.

Shallow clones get their own fast path, because CI fetches with --depth=1 by default. Aspen builds the depth-1 pack for a branch tip once and serves it to every CI job that asks.

How fast

The number that matters for agents is pushes a second to one repository, counted only once each push is safely stored. Cursor published theirs for its Git server, Origin: up to 120 pushes a second on S3 Standard, and more than 300 on the faster S3 Express One Zone, with every push to a repository going through one log.³ Aspen only orders pushes to the same branch, so it has no per-repository ceiling of that kind.²

On one 8-core server, S3 Standard and a 4-core Postgres, pushing to git.git through Aspen’s branch URL, Aspen sustained 567 pushes a second for five minutes with no errors. Each push was in S3 and Postgres before Git printed “ok”, with a median push of 208 ms and a 99th percentile of 314 ms. Another client saw each push 30 ms after it was acknowledged, at the median.

OpenAI didn’t publish a push rate for Pando. It reports results against its own previous system: median push latency down by nearly 80%, a petabyte of Git data served a day from a handful of cores, and clones that fill a 10 Gbps link.¹ Pando’s design is what Aspen follows, so the honest comparison there is the shape of the numbers: pushes that don’t wait on each other, and fetches served from stored packs rather than rebuilt ones.

Landing on main is a different kind of number. Every landing builds on the one before it, so separate landings run one at a time; Aspen manages about 4 a second that way, limited by round trips rather than load. Aspen also has a server-side merge queue that lands many PRs, each its own commit, in one update of main; we’ll publish its number once it’s measured. None of these numbers include CI.

Open source, and early

The code is on GitHub. aspen dev runs a server on your laptop with SQLite and a local directory; for a team there’s a Docker Compose stack, a Helm chart, and Terraform for AWS, Google Cloud, Azure and Hetzner.

We only trust Aspen where stock Git agrees with it. A differential test suite replays random pushes, deletes and races against Aspen and against Git’s own server and requires identical results; every night, Git versions from 2.30 to the latest, plus JGit, run against it; fuzzers and a chaos suite that kills servers mid-push run alongside. Like Pando, Aspen was built mostly by agents: one Reason took it from first commit to public in four days, over 151 merged pull requests.¹

It’s pre-alpha. Aspen is the Git part only, with no web UI, and no partial clones, SHA-256 repositories or RSA SSH keys yet. If you run agents against one repository, try it, break it, and tell us on GitHub.