What is Scion version control? Anthropic's agent-scale VCS, derived data and where it sits next to Git
Scion is Anthropic's in-house version control system: a server that stores small changesets and computes blame, history and trees from them, plus a client called scn that fetches files on demand. Anthropic described it on 13 October 2026, after moving its monorepo off Git in five months while merged changes went from an average of about 2,500 a day in May to "over 30,000 per day" in September. Nobody outside Anthropic can run it.
What is Scion version control?
Scion is a version control system Anthropic built for its own monorepo, where Claude agents and CI jobs make most of the requests. A team of seven built Scion and Antique, Anthropic's code review tool, in five months. The client is scn; behind it sit a per-node scion-daemon, a regional scion-cache and an authoritative scion-server, with metadata in Spanner and file contents in cloud storage (Anthropic).
The problem was Git at agent volume. Anthropic gives the main branch history as "almost 100 GB", the compressed working copy as "over 25 GB", and CI as "on the order of 25 million code checkouts per day", before counting developer machines and agent sandboxes. It had used shallow clones, sparse checkouts, promisor remotes and "several hundred internal git mirrors". Every number in the post is self-reported, with no method beyond the chart titles.
Dividing those two numbers gives the twelvefold jump some outlets reported, but it compares an average with a peak: May's 2,500 is a monthly average, while Anthropic's chart labels the September peak, on the 9th, at 30,401. Anthropic's own text says the volume merged per day grew 10x.
Scion stores small changesets and derives everything else on the server
A Scion changeset is an entry in a write-ahead log that lists only the files changed against its first parent, each with a content hash pointing at compressed file contents in blob storage. A Git commit points at a full tree instead. Scion's server builds the root tree and subtrees when they are needed and never stores them in the changeset.
Figure "Shape of a Scion changeset" from Redesigning source control at Anthropic by Anthropic, 2026.
Anthropic calls everything that is not part of the changeset derived data: "dedicated structures for file blame and path history and skip lists for the commit graph". Each type is defined recursively, so its value for a changeset comes from its values for the parents, and each can be computed eagerly or on first request.
A CI job that needs the diff between a commit and its merge base asks the server for it instead of cloning, and a blame request is answered from the blame structure rather than by walking history on the client. Anthropic's command chart gives medians for agent environments: a new worktree went from 7.1 minutes with Git to 5.1 seconds with scn, and total source control time per change request from 34 minutes to 3.7.
Scion's derived data follows Meta's Mononoke
Derived data in version control is anything the server can recompute from the commits and file contents, such as blame, file history or directory manifests, and builds after a commit is accepted instead of during it. Meta's Mononoke, the server behind Sapling, is built on it. Its docs say derived data "can be computed asynchronously after a commit has been accepted".
That split is what keeps commits fast: only the core data is written before the next commit can proceed. Mononoke's types include fsnodes (a tree with sizes and hashes), unodes (a tree linked to file history), Blame V2 and fastlog, pre-computed history that avoids walking the graph.
The first version of Anthropic's post credited "Google's Piper and Meta's Sapling" and did not name Mononoke. On 14 October Rain, who led the team effort behind Mononoke's Bonsai changeset model in 2018 by Rain's own account, set the two descriptions side by side and wrote that the omission "borders on plagiarism". On 15 October Anthropic added a footnote: "Specifically, the server component of Sapling, Mononoke. It pioneered many of the techniques we use in Scion, in particular the Bonsai data model." Rain replied that the attribution is now sufficient. Rain's second post also claims private confirmation that the copying was deliberate; that source is unnamed and I could not check it.
Does Scion replace Git?
Scion replaced Git in Anthropic's monorepo, the only migration the post describes. The scn client "deviates from git's fetch protocols in several important ways", and the post describes no Git-protocol endpoint, so a Git client cannot talk to Scion. Anthropic's own verdict: Scion "is by no means a suitable replacement for git for general use", and its ideas "only make sense for truly enormous monorepos".
The recommendation for everyone else is to keep Git and change the server. Anthropic suggests forges could offer "comprehensive server-side RPCs like Scion", answering history, blame and merge-base questions without a full local clone, and says it wants to partner with GitHub, GitLab and the open source community. Nothing concrete has been published yet.
Scion's clients are always online by design. Nick G., the post's author, wrote on Hacker News that offline commits would mean teaching the client everything the server does, and that it "would still never be able to answer more complex 'full-graph' questions, like history, blame, or merge base ancestry".
Scion, Mononoke, Sapling, Jujutsu and Cursor Origin fill different slots
Scion replaces the client, the server and the wire protocol at once, which is part of why it stays inside one company. The open alternatives each change one layer and keep Git somewhere in the path. Jujutsu and Sapling replace the client, Mononoke replaces the server, and Cursor Origin is a hosted Git forge with its own storage engine.
| Scion | Mononoke | Sapling (sl) |
Jujutsu (jj) |
Cursor Origin | |
|---|---|---|---|---|---|
| Slot | Client, server and protocol | Server | Client | Client | Hosted forge and storage |
| Speaks the Git protocol | No | Yes, Git smart HTTP | Yes, clones Git repos | Yes, Git backend | Yes |
| Available | Inside Anthropic only | Source on GitHub, some parts left out | Open source since 15 November 2022 | Open source, v0.46.0 on 7 October 2026 | Early beta since 17 August 2026, paid plans |
| Licence | Not released | GPL-2.0 | GPL-2.0 | Apache-2.0 | Proprietary |
| Works offline | No | Not applicable | Yes | Yes | Yes, through Git |
Sources: Mononoke README, Sapling launch post, Jujutsu repository, Cursor changelog, read on 17 October 2026.
The Mononoke README warns that the GitHub version "omits some functions", so it builds but is not a turnkey server. Cursor Origin keeps Git on the wire and stores pushes in a write-ahead log on object storage, which Cursor describes in Git at any scale. East River Source Control takes the same path, a Git bridge over its own storage engine, and is not generally available.
Nothing of Scion has shipped outside Anthropic
Scion runs in production at Anthropic and has no public code, repository, waitlist or price. Anthropic says "it's difficult to offer Scion in a form that would be broadly useful to other organizations". The Register reported there will be no open source release; that is a stronger line than anything in Anthropic's text.
Where each part stands:
- Shipped, internal only: Scion,
scn, Antique, code search and directory-level permissions, per the post. - Suggested, not built: standard server-side RPCs across forges and a different Git fetch negotiation.
- Unofficial: OpenScion, a GPL-3.0 repository created about five hours after the post that follows the design. It is not affiliated with Anthropic, and its benchmarks use synthetic repositories of 1,000 and 10,000 small files.
Several write-ups say more than the source. "Anthropic cancels Git" headlines describe one repository. The Scion post gives no share of changes written by Claude. The 80% some outlets repeat comes from Anthropic's 14 September CI article, which says Claude authors 80% of the code Anthropic engineers ship, not 80% of monorepo merges. The "600 PB of git traffic per day" some outlets repeat is Anthropic's estimate of what fetching naively would cost, not measured traffic.
Agent commit volume moves version control work to the server
Agent commit volume changes version control in three ways Anthropic describes. Clients are mostly agents and jobs that need one answer, not a full history. Merges arrive faster than a serial merge queue can test them. And humans stop reading every line. Each of these pushes work from the developer's clone onto a server that answers questions.
On merge queues, Anthropic writes that "a proper merge queue, for example, doesn't make much sense at agent scale", and that it tests after the merge and before deploy instead. Nick G. added that textual conflicts are never allowed, while semantic conflicts are "an unavoidable fact of very large repos" at that rate.
On review, the post says team members "now examine the intent of the change as opposed to reading every line of code". The Claude Code team's own review post from 15 October covers that layer; Claude Code lives in its own repository, separate from the monorepo the Scion post describes. The CI side of the same growth, with Anthropic's 25 times rise in CI jobs, is in the CI bottleneck numbers.
Who needs an agent-scale version control server
An agent-scale version control server pays off when one repository serves thousands of agents and jobs a day, each needing history, blame or a fresh checkout. Anthropic's threshold is "tens of thousands of engineers or swarms of agents prolifically writing code". Below that, Git with partial clone, sparse checkout and Scalar is the tool, and the cost of a custom server is not worth paying.
Signs you are getting close, taken from the problems Anthropic lists: you run your own Git mirrors or seed snapshots for CI, agents clone the whole repository to answer one history question, and blame or diff misbehaves on partial clones.
On Stackness, 4 public profiles list Git as of 17 October 2026, all four next to Claude Code, and none list Jujutsu or Sapling yet (data sources). The sample is small. Git sits with the rest of the DevOps and infrastructure tools developers list.
Where to start with Scion's ideas
Read Anthropic's post for the design and Mononoke's derived data doc for the mechanism it borrowed. Then measure checkout time per CI job and per agent worktree in your own repository. If either is minutes, try partial clone and sparse checkout before anything else.
If you want a different client while keeping your Git host, Jujutsu runs on top of any Git remote. Git itself is changing too: the SHA-256 compatibility post covers the next default that will touch every repository.
New posts by email
About one email a week with what we published. No account needed.
One email to confirm first. Every email has a one-click unsubscribe.
Which of these do you use?
Nobody on Stackness runs Scion yet. Tick what you use and be the first.
