Contents
The number that broke the git assumption: 2,500 to 30,000 merges a day
Anthropic says its merged code changes rose from about 2,500 per day in May 2026 to more than 30,000 per day in September 2026, a roughly twelvefold increase that made source control its biggest development bottleneck. Anthropic describes that as “more than tenfold”; by our arithmetic (30,000 ÷ 2,500) it is roughly twelvefold (Anthropic).
The scale problem was also a read problem. Anthropic reports main-branch history of about 100 GB and a compressed working copy larger than 25 GB. Its CI system performs about 25 million code checkouts per day, before counting developer environments, agent sandboxes, and research jobs. Anthropic estimates that naive fetching for those checkouts would mean over 600 PB of git traffic per day. These are Anthropic’s own figures, not a workload forecast for other organizations.
What Scion actually is: a write-ahead log, not a commit graph
Scion’s unit of work is a changeset: a write-ahead log entry that lists the files changed relative to its first parent, with content-addressed pointers to compressed blobs. A git commit instead points to a tree (Anthropic).
That distinction changes where work happens. Scion creates changesets on the server, and commits, merges, and rebases are server operations. Anthropic describes those operations as cheap, incremental, and lock-free. The client keeps a bounded object cache and a working copy, while the service owns the shared history and the write path.
Six principles, with client-server asymmetry doing the heavy lifting
Anthropic lists six design principles for Scion. The one with the widest architectural consequence is client-server asymmetry: the server answers history and blame queries and performs commits, merges, and rebases, while the client keeps a bounded cache and working copy (Anthropic).
The other principles follow from that split. Clients are always online. Source control is exposed through an API, so CI jobs often need no local repository. The system scales horizontally without packfiles or a fully materialized repository copy anywhere. Commits are cheap, incremental, and lock-free, with refs discouraged. The working copy is optional and sparse by design.
| Dimension | git | Scion |
|---|---|---|
| Offline model | Clients hold full history and work offline (Anthropic) | Clients are always online; the server answers history and blame queries (Anthropic) |
| Client role | Clients create commits, merges, and rebases locally (Anthropic) | The server creates commits, merges, and rebases; the client is a cache with an optional sparse working copy (Anthropic) |
| Checkout cost | Naive fetching at Anthropic’s scale is estimated at over 600 PB per day; CI alone makes about 25 million checkouts per day (Anthropic) | Source control is exposed through an API, so many CI jobs need no local repository (Anthropic) |
| Negotiation | The client tells the server what it already has; at peak, several hundred internal mirrors strained capacity (Anthropic) | Requests start from a root tree and ask only for missing objects, so any cache can answer (Anthropic) |
| Refs and writes | Commits point to a tree; branches and tags are refs (Anthropic) | Refs are discouraged except main and release branches; moving one is a compare-and-swap on a single Spanner row (Anthropic) |
| Merge queue | Anthropic could not replicate the industry-standard global repository lock (Anthropic) | No global lock; relies on post-merge and pre-deploy automated testing (Anthropic) |
For production teams, the transferable question is not whether every client should be online. It is whether clients really need to own every repository operation. Moving history queries and CI-facing source access behind server APIs can reduce local state without adopting Scion’s full model.
Why the mirror model stopped scaling
At peak, Anthropic operated several hundred internal git mirrors. Those mirrors “significantly strained capacity,” and they “no longer scaled once the repo outgrew the mirrors’ disks or memory limits.” Seeds fell further behind main between refreshes, and diff and blame became harder to run on partial clones (Anthropic).
Scion’s answer is to make large reads decomposable. Clients request missing trees and blobs individually, and because each object is immutable, any cache tier can serve it. The response can resume, and no single multi-gigabyte packfile is required. The design lesson is that when clients repeatedly consume immutable objects, smaller addressable requests improve cache reuse and failure recovery.
Derived data: blame and path history as computed structures
Scion stores changesets and blobs as canonical data. Blame, path history, and commit-graph skip lists are derived data, computed recursively from each changeset’s parents. Each derived type can be computed eagerly or deferred (Anthropic).
This separates the history from the query products built on top of it. Those views can be scaled and cached independently, but the server’s derived-data strategy then becomes part of the service’s capacity and availability design.
The tiered serving stack
Scion’s read path has three tiers: a per-node scion-daemon, a regional scion-cache that streams objects, and scion-server, which reads from Spanner or cloud storage. Anthropic enforces strict tiering so that a failure in one tier cannot overwhelm the tiers above it (Anthropic).
The useful test for other systems is whether a cache outage, a backend issue, or a client-node problem stays contained within its layer. A horizontally scalable service still needs explicit boundaries that stop one tier’s failure from becoming a system-wide dependency.
Refs become a compare-and-swap, and that narrows concurrency
Scion supports refs, but creating and fetching commits does not involve them. Moving a ref is a compare-and-swap on a single Spanner row, separate from creating changesets (Anthropic).
This removes ref movement from the routine commit path. The result is reduced coordination around ordinary writes, not the elimination of contention. A highly contended branch pointer should not gate every write unless the product’s semantics require it.
Where the bottleneck moves: the merge queue
Scion does not remove contention. Anthropic chose not to put a global repository lock on the merge queue, relying instead on post-merge and pre-deploy automated testing, and it accepts that concurrent changes can conflict (Anthropic).
Anthropic says Claude can typically fix those conflicts faster than humans can identify them. That is Anthropic’s claim and has not been independently reproduced. The design trades serialization for detection and repair after concurrent changes land.
Removing the lock increases concurrency, and it moves the bet toward testing and repair. Teams that cut checkout and write-path costs should expect merge-queue throughput and CI fan-out to become the next constraint.
What does not transfer to git, and what might
Anthropic says Scion is “by no means a suitable replacement for git for general use.” It suggests that its concepts make sense for truly enormous monorepos, with tens of thousands of engineers or swarms of agents (Anthropic).
The data model is the real boundary. Scion’s changesets and server-side writes change how history is represented and created, so they cannot be bolted onto git without that change. Anthropic’s nearer-term suggestions are narrower: git platforms could offer comprehensive server-side RPCs, servers need not behave like full git clients, and sparse and shallow features could compose better (Anthropic).
Results Anthropic reports, and the caveats
Anthropic reports that its Scion infrastructure footprint is 200x smaller than its previous git mirroring infrastructure in CPU and memory, that the system maintains a cache hit rate over 99%, that CI and research jobs check out code about two orders of magnitude faster, and that CI alone realized a 25% CPU capacity win (Anthropic).
None of these results has been independently reproduced. They come from one company with an unusually high write volume, and the 2,500-to-30,000 merge growth should not be generalized.
Cursor’s Origin: hosting, not a new version-control model
Cursor began rolling out Origin, its code hosting product, in early beta on all paid plans. The beta covers repositories, pull requests, code browsing, and GitHub sync. For Origin-hosted repositories, Origin is the source of truth and GitHub is not in the push path (Cursor Origin Code Hosting).
For repositories synced from GitHub, GitHub remains the source of truth and Origin mirrors it. Enterprise organizations whose administrators opt out are excluded. Origin does not replace git for its users. Repositories are cloned and pushed with the Origin CLI (Cursor Origin Code Hosting).
Cursor’s October 13 marketplace update lists over 20 integrations, including Cloudflare, Linear, Sentry, and Socket Security. Apps authenticate with an app JWT and installation access tokens, receive webhook events, and can write back check runs, pull-request comments, and reviews (Cursor Origin App Marketplace). Nothing in the changelog describes a change to Origin’s data model.
Prior art
Anthropic connects Scion to Google’s Piper and Meta’s Sapling, specifically Sapling’s Mononoke server and its Bonsai data model, which pioneered several of the techniques Scion uses (Anthropic). Anthropic also reports that it migrated its monorepo off git in five months and shipped code review, code search, and source-control IAM in the same period.
FAQ
Is Scion something my team could adopt instead of git?
Anthropic says Scion is “by no means a suitable replacement for git for general use.” It also says that an external offering would be difficult, because adopters would need to migrate the full lifecycle, including code review, code search, and CI (Anthropic).
Did Anthropic keep git underneath, as a wrapper or proxy?
No. Anthropic says it fully migrated its monorepo off git in five months. Scion’s changesets store changed-file lists and content-addressed blob pointers, so it replaces the source-control model rather than wrapping git (Anthropic).
Is Cursor’s Origin replacing git for its users?
No. Origin repositories are cloned and pushed with the CLI. Origin-hosted repositories use Origin as the source of truth, while GitHub-synced repositories keep GitHub as the authority with Origin mirroring it (Cursor Origin Code Hosting).
The Bottom Line
Scion shows that at Anthropic’s reported write volume, the source-control contract itself can become the bottleneck. When clients no longer have to own history, commits, merges, and negotiation, a scalable server can absorb that load (Anthropic).
Most teams should not copy the whole design. The transferable pieces are server-side RPCs, servers that need not behave like git clients, and composable sparse and shallow checkouts. The bottleneck also moves: with no global merge lock, the system depends on automated testing and conflict repair.
How This Guide Was Built
This review is based on Anthropic’s engineering post, Cursor’s changelogs, and the cited primary sources — we did not run Scion or Origin hands-on. (Anthropic; Cursor Origin Code Hosting; Cursor Origin App Marketplace) The Anthropic post, “Redesigning source control at Anthropic,” was published October 13, 2026 and updated October 15, 2026. Cursor’s Origin Code Hosting changelog is dated August 17, 2026, and the Origin App Marketplace changelog is dated October 13, 2026.
📖 Related Reads
- ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
- NoCode Insider — AI workflow automation with no-code tools, agents, and APIs
Cross-links automatically generated from CodeIntel Log.
