Three answers now exist for the same question: what should code infrastructure look like when software agents, not just people, do most of the pushing? Plain git is the default. Anthropic's Scion abandons git's model for a server-centric one. Cursor's Origin keeps git but rebuilds the hosting underneath it. They are often lumped together, but they change different layers of the stack, and that is the key to choosing between them.
Sources: Anthropic's engineering post for Scion, and Cursor's own write-up of Origin as covered in our Origin architecture post. All figures are vendor-reported and not independently verified. For the two-way view, see Scion vs git.
TL;DR: the three at a glance
| Git | Scion | Cursor Origin | |
|---|---|---|---|
| Layer changed | None, it is the baseline | The version control system itself | The hosting and storage layer |
| Still git? | Yes | No | Yes |
| Source of truth | Any full clone, usually a host | Server, with changesets in a write-ahead log | Write-ahead log in S3 |
| Client model | Full or partial clone, offline capable | Always online, sparse, bounded cache | Standard git clients |
| Built for | Everyone | A huge monorepo with mostly agent clients | Many small agent repos and a few huge ones |
| Who can use it | Anyone | Anthropic only | Cursor users, in beta as of launch |
| Biggest trade-off | Strain at extreme scale | Gives up offline and ecosystem | New vendor and data questions |
Layer one: the version control model
This is where Scion lives. Anthropic says git is decentralized, so every clone can compute diffs, read history and check out any revision offline. Anthropic was using it as a centralized system with one authoritative copy, while nearly all clients were agents and jobs that are online by definition. Scion drops the offline assumption. The server answers history and blame, creates commits, merges and rebases, and the client keeps a bounded cache and a sparse working copy.
Origin does not change this layer. Developers and agents still talk to a git remote and use ordinary git commands. That is its advantage and its limit: nothing about workflows or tools has to change, and nothing about the model's scaling limits changes either, beyond what hosting can hide.
Layer two: hosting and storage
This is where Origin lives. Cursor says GitHub's Spokes design, introduced in 2013, stores real repositories on local disks, replicates them to a small number of servers and keeps them in sync with three-phase commit. Cursor argues that has two limits now: consensus latency prevents scaling past a handful of replicas, and every repository needs the same minimum number of replicas, however idle. Agents create huge numbers of small, often disposable repositories, so the floor is too high, while a few massive monorepos need more replicas than the model handles well.
Its answer, a system called Continuity, makes a write-ahead log in S3-compatible storage the source of truth. A push is acknowledged only once it is in the log. A local copy on fast disk still exists for git operations, but it is a cache that can be rebuilt from the log at any time. Routing uses rendezvous hashing, and replicas verify against S3 before serving reads. Cursor reports linear read scaling tested to 100 replicas and about 300 pushes a second on S3 Express One Zone in synthetic tests.
Scion also uses a write-ahead log for changesets, but it applies the idea to the version control model itself, not only to hosting.
Scale claims, side by side
| Claim | Source | What it measures |
|---|---|---|
| 2,500 merges a day in May to over 30,000 in September | Anthropic | Real production monorepo |
| 200x smaller infrastructure than the git mirror fleet | Anthropic | CPU and memory |
| Checkouts two orders of magnitude faster | Anthropic | CI and research job checkouts |
| Linear read scaling to 100 replicas | Cursor | Synthetic stress tests |
| About 300 pushes a second | Cursor | Synthetic, on S3 Express One Zone |
The rows are not comparable. One set is production traffic at one company, and the other is lab testing of a hosting system. Treat both as signals about direction, not as a ranking.
What each choice costs you
Git. You stay in the ecosystem, and you keep every tool, host and habit. The cost shows up only at extreme scale, as mirrors, seeds and workarounds. Anthropic ran several hundred internal mirrors at its peak.
Scion. You get an API for repository questions, so many CI jobs need no local repository, plus sparse checkouts and no repository maintenance. You give up offline work, easy portability and the git ecosystem. It is also not available outside Anthropic.
Cursor Origin. You keep git and potentially get cheaper, more elastic hosting for agent-created repositories. You add another vendor to your stack. Reporting says mirrored GitHub repositories stay in sync with GitHub remaining the system of record, so adopting Origin may mean running two systems. Review data retention, training use and export terms before moving private code, since we have not seen detailed Origin-specific terms.
Decision guide by team type
| Your situation | Likely best fit | Why |
|---|---|---|
| Small team, normal repositories | Git | No scale problem to solve |
| Heavy agent use, moderate repositories, slow CI clones | Git with partial and sparse clones, plus a merge queue | Cheapest fix first |
| Many small, short-lived agent repositories, Cursor already in use | Try Origin | Matches the workload Cursor describes |
| Huge monorepo, tens of millions of daily checkouts, mostly automated clients | Scion-style architecture | Matches the workload Anthropic describes, but you would have to build it |
| Need offline work or open-source collaboration | Git | Scion's model rules it out |
How to decide in four steps
- Measure first. Record clone time, bytes fetched per CI job, merge queue wait and replica load. Without numbers, you are guessing at the bottleneck.
- Use git's own tools. Partial clone, sparse checkout, shallow CI clones and a merge queue are free and reversible.
- Pilot a hosting layer if the workload fits. If agents create many throwaway repositories, an Origin-style hosting layer is a contained experiment because clients stay on git.
- Borrow Scion's ideas before its architecture. Expose repository questions such as blame, history and merge base as a service, and stop having every job clone everything. That idea works without a new version control system.
A worked scenario: three teams, three answers
Team A runs a 40-person product company on git with a few agents. Their pain is occasional slow CI clones. A shallow clone for CI and a merge queue fix it in an afternoon. Neither Scion nor Origin is relevant.
Team B builds an agent product that spins up a repository for every user task. Thousands of small repositories appear and are abandoned each day, and a few shared repositories are heavily read. Per Cursor's argument, replica minimums for idle repositories and consensus limits on busy ones are exactly their cost drivers. A hosting-layer change that keeps git on the client side is a contained experiment, so Origin-style hosting is worth a pilot, after measuring what a throwaway repository actually costs them today.
Team C operates a single giant monorepo where most commits come from automation. Their clients are online by definition, checkouts number in the millions, and mirrors are multiplying. This is the workload Anthropic describes. They would first apply git's large-repository tools and a repository query service. Only if those fail would a server-centric design come into play, and they would be building it, since Scion is not available.
The pattern: the right answer follows the shape of your load, not the novelty of the tool.
Questions to ask each vendor
- Anthropic: Will Scion or its code review system be released, and if so under what terms?
- Cursor: What are the data retention, training and export terms for code hosted on Origin, and how does GitHub sync behave during an outage?
- Both: What independent benchmark exists on a workload like mine, and what fails first under load?
What none of them solve
Better storage does not fix review. Anthropic is explicit that its engineers still steer, that agents sometimes violate core constraints, and that reviewers now examine intent instead of reading every line. It also says concurrent changes can conflict because Claude can usually fix conflicts faster than people can find them. Cursor's pitch for agent-first review makes a similar point from the hosting side. Whatever you choose, plan how humans and agents split review, as covered in our Claude Code vs Cursor vs GitHub Copilot comparison.
Caveats
- Scion and Origin figures are vendor-reported.
- Scion is internal, and Origin access and terms may have changed since launch.
- The three systems answer different questions, so a single winner would be misleading.
- We have not run any of them.
Bottom line
Git remains the right answer for almost everyone. Origin is the option to watch if you already use Cursor and your agents create lots of small repositories, because it changes the hosting layer and leaves your git workflow intact. Scion is the clearest description of where a single enormous, agent-written monorepo ends up, and the part most teams can use today is the idea, not the product. For a framework you can apply to your own repository, read our decision guide to server-centric versus distributed version control.
Related reading
- Anthropic Replaced Git With Scion
- Scion vs Git
- Cursor Origin: how its git hosting works
- Cursor Origin launches as GitHub goes down
- Cursor Origin announcement and the agent-first review idea
- What are monorepos?
Scion details are from Anthropic's October 13, 2026 post. Origin details are from Cursor's engineering write-up and launch coverage. This post will be updated as either company publishes more.