Evidence at a glance
Agents Push the Old Model to Its Limit
Classic Git servers assume humans are committing: not too often, with conflicts serialized through merge requests or explicit locks. Agents behave differently, pushing every few minutes while CI fetches right after each push. Per Reason Machines, a classic server queues every push to a repository together and builds a fresh pack for every fetch, so server work grows with the number of clients rather than the amount of new code.
OpenAI hit that wall and built Pando, which it says cut median push latency by nearly 5x and serves nearly a petabyte a day. Those are OpenAI's figures for its own production system, measured under different conditions, so they are not a like-for-like comparison with Aspen. Aspen takes another route: rather than copying Pando's code, it is an independent implementation of the published design, released under Apache 2.0 and deployable on your own hardware.
Compare-and-Swap, One Branch at a Time
Aspen drops two assumptions most Git servers still keep. The first is lock granularity. Each branch is a chain of versions held in one PostgreSQL row: a push uploads its pack, then moves the branch pointer with a single compare-and-swap. Pushes to different branches therefore never wait on each other. If two pushes race on the same branch, one wins and the other gets Git's familiar "fetch first" error, so conflict handling stays on the client's existing path. The cost is that branches may be read at slightly different moments.
The second assumption is how packs are produced. Aspen never unpacks a push; it verifies the pack, completes any missing bases, and stores it as-is in S3-compatible object storage. On fetch it streams the stored packs the client lacks, recompressing nothing, and those packs can be served from a CDN via signed URLs. To keep negotiation small, pushes see only the trunk branch, so the negotiation surface stays tiny even with a million branches. Background compaction merges packs 16 at a time in levels, like a log-structured merge tree, so a far-behind client receives a few dozen packs rather than thousands, and depth-1 CI fetches share a tip pack built once.
How the 567-per-Second Figure Was Measured
The test ran on one 8-core server with S3 Standard and a 4-core PostgreSQL, targeting a copy of git.git, about 4,500 files and 75,000 commits, pushing to a branch-scoped URL. It sustained 567 pushes per second for 5 minutes with no errors, and each push reached S3 and PostgreSQL before Git printed "ok." Median push latency was 208 ms, the 99th percentile 314 ms, and another client saw a push about 30 ms after acknowledgement at the median.
The measurement deserves context. The README calls Aspen's figures indicative rather than performance claims; this is vendor self-testing with no third-party reproduction. The project's public benchmark notes describe a different setup, a single 4-vCPU machine running aspen dev on SQLite and local disk, where some comparisons were run under differing memory conditions, usually once each, and a 1,000-concurrent shallow-clone test saw many failures before a fix and a re-run. Conflating the two sets of results would be wrong. For outside context, Cursor reports up to 120 pushes per second on S3 Standard and more than 300 on S3 Express One Zone, but that is a replicated cluster on its own monorepo with a different configuration.
How Fast It Runs Depends on Which Branch You Write
The 567-per-second figure holds only when writes spread across branches. When every update lands on main, each commit must build on the previous result, and Reason Machines puts that trunk-landing path at about 4 per second today. Races on a single branch still occur; they surface as Git's standard "fetch first" error and a client retry, which for high-frequency agents makes retry logic and branch partitioning part of the effective throughput.
In the depth-1 fetch storm test, Aspen moved 1.029x the bytes of stock git upload-pack on git.git, essentially on par, so reusing stored packs does not trade bandwidth for CPU. Still, these numbers describe one repository size on one storage backend and should not be extrapolated into a claim that Aspen reaches that rate across all repositories and workloads.