Cursor built a Git server on object storage, wrapped around a custom engine called Continuity, and put a beta behind its paid plans. That sounds like plumbing. It isn't: Git's data model hasn't been seriously re-thought for scale since GitHub's Spokes design, and Cursor just shipped a different credible answer to the same problem — designed by someone who helped build the first.
The reason anyone outside Cursor should care is the one the Register's writeup opens with: GitHub's recent outages, and the fact that AI agents are pushing every version-control system past the load it was designed for.
Why Git hurts at 400 million repos
Linus Torvalds designed Git as a content-addressable data store. Every object — commit, tree, blob, tag — is identified by the SHA-1 hash of its bytes, and the repository is a directed acyclic graph of those objects connected by pointers. Look something up by SHA and you find it instantly. Don't have the SHA and you walk the DAG node by node until you do.
For the client, that walk is invisible. git clone asks for a packfile; git log asks for the last N commits. From the server's side, every one of those requests is "traverse the graph, then assemble the right objects":
# server side, answering "give me the last 100 commits on main"
#
# for each commit in requested range:
# resolve parent SHA → fetch commit object
# resolve tree SHA → fetch tree object
# for each entry in tree:
# if entry is a subtree, recurse
# finally: assemble packfile
#
# at 400M repos, this is the entire hot path.
At a few thousand commits that's fine. At four hundred million repositories, with thousands of commits each, it is not fine.
GitHub's answer, after what principal systems engineer Vicent Martí describes as "some fiddling about," was Spokes: keep at least three tightly synchronized copies of every repository on fast NVMe disks. It worked. It also locked GitHub into a specific disk shape — and when that shape hiccuped, every developer on the platform noticed.
[[DIAGRAM: client request → SHA lookup → if miss, walk DAG step by step → assemble packfile → return; same path at 1k commits and 400M repos]]
What Cursor changed
Martí spent a decade at GitHub, which is the relevant credential. The architecture Cursor published lays out an explicit bet: stop treating Git as something you store on local disks, and start treating it as something you serve from object storage. That is, fundamentally, what Origin is.
The hard part isn't the storage decision. The hard part is everything you used to do with on-disk reads — incremental updates, ref advertisement, partial clone resolution, GC, the lot — has to be expressed against an API that doesn't speak POSIX. That's where Continuity comes in. Cursor calls it an internal engine; reading between the lines of the announcement, it's the layer that owns Git semantics on top of an object store and presents them back to the rest of Cursor's stack in terms the rest of the stack can use.
Two consequences worth flagging:
- No DAG walks on the hot path. Object stores are addressable by key. Continuity can index Git objects the way Spokes' replicas did, but without three live copies of every repo on spinning disk.
- The data plane decouples from the disk. If object storage is healthy, your Git is healthy. If it isn't, the failure mode is one you can reason about — not three replicas diverging under a bad merge.
Neither of those is free. Object storage has higher per-op latency than local NVMe. Continuity is the reason Cursor can pay that cost without users feeling it, and the post is honest that this is still a beta behind paid plans — not a general-purpose replacement for git push against any host.
How to actually use it today
An honest install guide would start with a CLI and a git remote add command. The announcement doesn't ship either, so here's what is actually available as of the article:
- Origin is in beta.
- It's gated behind paid Cursor plans.
- The technical source of truth is Vicent Martí's post on Cursor's architecture.
What's missing, and would each individually turn this from "interesting engineering blog post" into "infrastructure people actually adopt":
- A public benchmark versus GitHub's stack or vanilla
git push. - A self-host path for teams that can't use Cursor's hosted Origin.
- A
git-remote-originshim or first-class CLI for migration. - Stated Git version, hardware, or platform requirements.
If you want to read the underlying design, the entry point is Martí's post. If you want to try it, the entry point is a Cursor subscription. That's the situation as of the article's date — and writing a worked-example install command I made up would be worse than admitting the docs aren't there yet.
[[CHART: relative cost shape — three live NVMe replicas (Spokes) vs single object store + index layer (Origin), conceptual only]]
What this doesn't change
Origin is a server-side rewrite. It does not change Git's wire protocol, its SHA-1 identity model, or its DAG semantics. Every tool in your stack — your CI, your code review UI, your editor, your agents — keeps working as long as it speaks plain Git over HTTPS. That's the entire point: Cursor is paying the engineering tax so you don't have to.
It also doesn't fix the upstream reason Git is hard to scale, which is that the protocol is twenty years old and assumes single-disk operations. Object storage hides that for the server. For everyone pushing tens of thousands of commits a day from a single repo, the limit isn't where their bytes live — it's what Git itself is willing to do in a single graph.
Comparing this to the obvious alternatives
The honest comparison is short, because the article doesn't include one:
- Git LFS substitutes pointer files for blobs. It doesn't change how the Git graph is stored, only what's in it. Origin is a different layer of the stack entirely.
- GitHub's Large Repository support is Spokes plus better caching. It's the design Cursor's principal engineer used to work on. Origin is an explicit bet that the Spokes shape was right, but the wrong material.
- Self-hosted Gitea, GitLab, SourceHut all run Git on local disks, the way Git has always run. They scale the same way Git has always scaled.
None of those is wrong. They're solving different problems at different layers. Origin's claim is that, at Cursor's size and Cursor's commit rate, the object-storage layer wins.
What this gets us
Two things, one obvious and one less so.
The obvious one: if Cursor's bet works, Git hosting gets cheaper to operate, more reliable under partial failure, and easier to back up. Every developer on the platform benefits, even if they never look at the data plane.
The less obvious one: the AI-coding stack now has somewhere to push its volume. Agents produce more code, more PRs, more CI runs — Martí's words, not mine — and that volume has been hitting a version-control layer that was sized for humans. Origin is Cursor making the underlying store fit the load the agents are about to put on it. Whether other platforms follow is the open question, and the answer depends on whether Martí's post gets treated as a blog or as a blueprint.
Where OTF fits
Cursor's move is the layer swapping out from under a stack that doesn't change. It happens to be the version-control layer this time; usually it's the model or the editor. Either way, the durable part is everything you wrote on top: the screens, the flows, the components that have to look and behave the same on web, iOS, and Android. That's the layer AI tooling churn can't touch, because it isn't the part anyone is rewriting.
Use Origin. Use the next thing after Origin. The interfaces that survive the swap are the ones you spent the most time getting right — the part that ships a consistent experience no matter what changes underneath.
Top comments (0)