What is Scion version control? Anthropic's agent-scale VCS, derived data and where it sits next to Git

Anthropic detailed Scion, its in-house version control system built for its monorepo, on 13 October 2026, after moving the repository off Git in five months with a team of seven that also built its code review tool Antique. Anthropic reported merged changes rising from an average of about 2,500 per day in May to a September peak of 30,401 on the 9th, and said a new worktree dropped from 7.1 minutes with Git to 5.1 seconds with Scion's `scn` client, with total source control time per change request falling from 34 minutes to 3.7. Scion stores only small changesets in a write-ahead log and derives blame, path history and trees server-side, an approach modeled on Meta's Mononoke, and nobody outside Anthropic can run it.

What is Scion version control? Anthropic's agent-scale VCS, derived data and where it sits next to Git Scion https://stackness.dev/tools/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 https://www.anthropic.com/engineering/redesigning-source-control , 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 https://cloud.google.com/spanner and file contents in cloud storage Anthropic https://www.anthropic.com/engineering/redesigning-source-control . 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 https://www.anthropic.com/engineering/redesigning-source-control 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 https://stackness.dev/tools/mononoke , the server behind Sapling https://stackness.dev/tools/sapling , is built on it. Its docs https://github.com/facebook/sapling/blob/main/eden/mononoke/docs/2.3-derived-data.md 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 https://sunshowers.io/posts/anthropic-mononoke/ 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 https://news.ycombinator.com/item?id=50108855 that the attribution is now sufficient. Rain's second post https://sunshowers.io/posts/anthropic-mononoke-2/ 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 https://stackness.dev/tools/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 https://stackness.dev/tools/github , GitLab https://stackness.dev/tools/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 https://news.ycombinator.com/item?id=50079495 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 https://stackness.dev/tools/jujutsu and Sapling replace the client, Mononoke replaces the server, and Cursor Origin https://stackness.dev/tools/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 https://github.com/facebook/sapling/blob/main/eden/mononoke/README.md , Sapling launch post https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ , Jujutsu repository https://github.com/jj-vcs/jj , Cursor changelog https://cursor.com/changelog/origin-code-hosting , 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 https://cursor.com/blog/git-at-any-scale . East River Source Control https://stackness.dev/tools/east-river-source-control takes the same path, a Git bridge over its own storage engine, and is not generally available https://ersc.io/blog/what-comes-after-git . 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 https://github.com/tinyhumansai/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 https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic , 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 https://news.ycombinator.com/item?id=50082255 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 https://claude.dev/blog/solving-code-review-at-anthropic/ 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 https://stackness.dev/blog/ci-bottleneck-ai-generated-pull-requests-september-2026-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 https://git-scm.com/docs/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 https://stackness.dev/tools/claude-code , and none list Jujutsu or Sapling yet data sources https://stackness.dev/about/data-sources . The sample is small. Git sits with the rest of the DevOps and infrastructure tools developers list https://stackness.dev/categories/devops-infrastructure . Where to start with Scion's ideas Read Anthropic's post https://www.anthropic.com/engineering/redesigning-source-control for the design and Mononoke's derived data doc https://github.com/facebook/sapling/blob/main/eden/mononoke/docs/2.3-derived-data.md 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 https://stackness.dev/blog/git-sha-256-repository-compatibility-test-your-stack-before-git-3-0-makes-it-the-default 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. Which of these do you use? Nobody on Stackness runs Scion yet. Tick what you use and be the first. Play Lonny Eagle Amateur Skater 4A pixel art skateboarding game. Signing up opens it straight away.Sign up to play https://stackness.dev/games/lonny-eagle