Git works fine on a laptop and badly as a shared service, and the reason is a file format almost nobody outside systems engineering thinks about. Cursor’s engineering blog spent roughly 5,000 words on it, in a post by engineer Vicent Marti. It frames that mechanism as the reasoning behind Continuity, the storage system that runs Origin, the Git host Cursor pushed to paid users days before GitHub went dark. The product story is already told. The engineering underneath it is not.
Every object in a Git repository, meaning every file, folder, and commit, is stored by the hash of its contents and linked to its neighbors in a graph. To do almost anything with a repository, from listing recent commits to running a clone, Git has to walk that graph one link at a time. It cannot know which object comes next until the previous one has already arrived. When you push or pull, that data moves as a packfile: a compressed binary blob where most objects are not stored intact but as deltas against others packed alongside them. Reading one file can mean unpacking several neighbors first. That access pattern is cheap on one fast local disk and punishing for anything that has to cross a network.
Three broad approaches exist for spreading that load across machines, roughly in order of how hard they are to pull off.
- Replicate the objects themselves, turning the repository into a distributed key-value store keyed by hash. It looks like a clean fit for content-addressed data, and Google tried exactly this years ago, spreading objects across a distributed hash table through JGit, a custom Java implementation of Git. Routine operations worked. Cloning did not: the Git wire protocol still has to assemble a packfile for transfer regardless of backend storage, and a graph walk against a distributed store made that too slow.
- Replicate the disk instead of the application, so the app layer stays untouched while repositories move onto a shared or synchronized filesystem. GitHub tried this first, running NFS, then block-level replication through tools like GFS and DRBD. Every attempt hit the same wall: reading a packfile means jumping around inside gigabytes of data. No networked filesystem tolerates that without caching whole files locally, which is unrealistic at hundreds of thousands of repos.
- Replicate whole repositories at the application layer, keeping each copy an ordinary Git repository on fast local disk and running a consensus protocol to keep copies in sync. That is what GitHub’s Spokes system has done since roughly 2013, using three-phase commit so a push only counts once most replicas confirm it. Spokes became the industry default, and it works, at a cost: consensus speed is capped by the slowest replica, so adding replicas makes each push slower, not faster.
That last tradeoff is the one Cursor’s post spends the most time on, because it breaks under how coding agents use Git today. A fixed replica count that suited an ordinary repository in 2013 is thin for a monorepo absorbing nonstop CI traffic. It is also wasteful for the flood of small, disposable repositories agents spin up and abandon, each still carrying the same fixed number of idle copies to stay consistent.
Continuity, Cursor’s answer, keeps repositories as real Git repos on local disk (Marti credits Spokes for getting that part right). But it swaps fixed-quorum consensus for a write-ahead log kept in S3-compatible storage as the single source of truth. Replicas catch up from that log independently instead of voting on every push, which decouples consistency from replica count. A heavily loaded monorepo can run across hundreds of replicas, while a throwaway repository gets one, built on demand and dropped when idle. Cursor reports linear read scaling in stress tests up to 100 replicas. Push throughput reached 120 pushes per second on standard S3 storage, rising past 300 per second on the faster S3 Express One Zone tier.
Cursor has an obvious reason to publish this much storage-engine detail now: it just started charging for a Git host. The clearest way to justify that is arguing the incumbent architecture, the Spokes-style replication that GitHub and most rivals run some version of, was built for traffic that agents have already outgrown. That does not make the underlying claim wrong. The packfile bottleneck and the three-phase commit throughput ceiling are documented failure modes in distributed systems generally, independent of who is selling the fix.
For engineering teams weighing Git hosts as agents multiply branch counts and CI volume, the useful question is not whose writeup reads more convincingly. It is whether a vendor’s replication model scales replicas independently for oversized monorepos and undersized throwaway repos, or forces every repository through the same fixed quorum. That is worth asking any Git hosting vendor before the next renewal.
Cursor published this post, “Git at any scale,” by engineer Vicent Marti, on its engineering blog, cursor.com, accessed August 19, 2026.
