How Cursor Overcame Git's Scalability Challenges

Git was never designed for an agent-written world

Cursor — yes, a SpaceX subsidiary — published a detailed engineering post this month from principal systems engineer Vicent Martí walking through Origin, a Git-based repository service built on top of an internal engine called Continuity. The bet is plain: stop pretending Git's content-addressable store can survive object-count blowup on its own, and rehost the whole distributed version control system on top of object storage. It's a real architectural change, not a tuning exercise, and reading Martí's writeup is a reminder of how much of modern dev infrastructure is held together by duct tape and NVMe arrays.

If you've been on call during a GitHub outage this year, this post is for you.

Git's original design is the bottleneck

Linus Torvalds built Git around a content-addressable data store, indexed by the SHA-1 hash of each object's contents. The repository is a directed acyclic graph: every commit is a node, every parent pointer is an edge. That's elegant and gives you local integrity for free — but it also means the server has to know every object by hash, or it has to walk the DAG step by step to find the ones it's missing.

That tradeoff is fine at ten thousand commits. At four hundred million repositories, it breaks.

Martí spells it out: a client asking for a packfile, or even just a list of recent commits, forces the server to traverse the entire graph to assemble the right objects. The lookup table is the graph. The cache misses are not exceptional — they're structural. Every read path ends in a graph walk, and graph walks don't parallelize cheaply.

// Git's content-addressable model maps cleanly onto an object store:
//   key   = sha1(object_contents)
//   value = the object bytes (blob, tree, commit, or tag)
//
// The original Git server held these in packfiles on local disk.
// Continuity holds them in an object store, keyed the same way.
//
// A clone becomes: "list all keys in this repo's namespace"
// A fetch becomes: "give me the bytes for these specific keys"
// No DAG walk needed for the bulk object transfer.

GitHub's answer: Spokes

The industry's largest Git host already had to confront this. After years of fiddling, GitHub engineers landed on an architecture called Spokes: at least three tightly synchronized copies of every repository, kept on fast NVMe disks. It's a brute-force answer — replicate the whole repo aggressively, pay for the disk, hope locality saves you.

Spokes works. It also has a ceiling. NVMe is fast but not infinite; replicas have to be re-replicated as repos grow; and the synchronization layer is itself a complex distributed system. GitHub's scaling story has always been "throw more metal at it, very cleverly." That's gotten us to four hundred million repositories, but the agent era is going to blow past that ceiling fast.

Cursor has the advantage of starting from a blank slate in 2026, when S3-shaped infrastructure is taken for granted. GitHub's Spokes stack was the right answer in 2017. The question is whether it's the right answer for the next decade.

Cursor's bet: Git on object storage

Origin is Cursor's Git-based repository service, and Continuity is the internal engine underneath it. The architectural shift, as Martí's post describes it, is to stop treating object storage as a backing layer for a Git server and instead treat object storage as the source of truth — rehosting the whole distributed version control system on top of object storage. The content-addressable nature of Git, where every object is keyed by its content hash, maps cleanly onto an object store: lookups become direct key fetches instead of DAG walks.

The wins show up where you'd expect. Object stores are designed to be cheap, durable, and effectively infinite in capacity. Walking the DAG is still expensive, but serving a known object by its content key is exactly what an object store was built for. Packfile assembly and lookup get to be the same operation, and they scale horizontally the way storage systems actually scale — by adding more buckets, not more spindles to one server.

It's also a bet on agents. Martí's quote from the post is the clearest articulation of the moment:

"Agents have fundamentally changed the way we work with software, and in many ways they've made this situation worse. More code, more PRs, more CI runs. Version control is at the core of all of this, and it is possibly the hardest thing to change overnight."

That quote is worth sitting with. More commits, more branches, more merges, more CI — every developer-tool vendor is staring at the same hockey-stick in their metrics. The systems that worked in 2019 will not work in 2027.

How to try Origin today

Here's the honest version. Origin is in beta and is available to paid Cursor plans. There's no free-tier path documented in the post; if you want to kick the tires you need to be on a Cursor subscription that includes Origin access, then opt into the beta from your dashboard.

The path looks like this:

1. Get on a paid Cursor plan that includes Origin. The post doesn't enumerate which tier — Cursor's pricing page will.
2. Opt into the Origin beta from your Cursor dashboard. Beta programs at this stage are usually flag-gated; expect to wait for a cohort invite.
3. Create or migrate a repository. Origin presents as a normal Git remote — git push origin main should work — so existing Git muscle memory applies. The plumbing underneath is what changes.
4. Wire it into your CI. Any runner that can speak Git over HTTPS or SSH should just work. The win shows up in clone times and in how the server handles large monorepos at peak.

A few things to watch for while you're evaluating:

• Beta status is beta status. Expect rough edges, especially around partial-clone edge cases, submodules, and LFS.
• Pricing model. Cursor hasn't published per-repository pricing for Origin the way GitHub charges per-seat. If you're moving a monorepo with hundreds of engineers, get clarity on cost before you migrate.
• Lock-in surface. Your data is still Git objects — you can always push to another remote. The lock-in risk is on the UI and the agent-integration surface, not on the bytes.

If you can't get into the beta, the next-best thing is reading Martí's full post and applying the architectural pattern to your own Git infrastructure: separate hot metadata from cold object storage, and stop treating the Git server as a single chokepoint.

The agent multiplier

The interesting question is not "is Origin faster than Spokes." The interesting question is what happens to every other system in your stack when commit volume goes up 10× because every PR has a parallel agent branch.

CI runners. Code review queues. Branch protection rules. Release trains. Every part of your delivery system that assumes one engineer, one branch, one PR, gets stressed. The agent era doesn't just change how much code ships; it changes the shape of the pull request graph — more short-lived branches, more stacked PRs, more rebase churn, more automation traffic between commits and merges.

This is why Cursor's move matters beyond Cursor. They had the engineering resources to build a real solution because they were getting crushed by their own product's success. The rest of the industry is about to be crushed by their users' agents, and most of us don't have an in-house.

Origin is a genuine engineering win, and Cursor deserves credit for shipping it rather than paper-masking the problem with another NVMe rack.

What doesn't change when your VCS does

Here's the part worth saying out loud: every architectural bet on the backend — Spokes, Continuity, whatever comes after — is a bet on how bytes flow between machines. None of it changes the part of the stack your users actually touch.

The web view, the iOS app, the Android app, the design system, the component library — these are the parts that ship product. When the team at Cursor rewrote how Git fetches objects, they did not also rewrite how their editor renders a dialog box. And when the next VCS shift lands — and another one will, inside two years — that part still won't be rewritten.

That's the layer worth investing in: the part that survives the backend churn. Pick a component model that gives you one API across web and native. Pick a styling system that doesn't need a rewrite when the rendering target changes. Pick a theming layer that survives a rebuild. None of that depends on which company is hosting your objects this quarter.

Agents will keep generating more code. More PRs will keep hitting more CI. Version control will keep being the bottleneck — first at GitHub, then at Cursor, then somewhere else. The interesting engineering is happening there, and Origin is a genuinely good piece of it. The interesting product engineering is happening one layer up, in the parts of the system that don't care which object store is underneath.