Scion, Anthropic's source control system: should you care?
Anthropic built Scion as 30,000 code changes a day outgrew Git, then said it is no general replacement. The numbers, and what to do.
Scion is the source control system Anthropic built in-house after its code changes outgrew Git. Anthropic's own verdict: "Scion is by no means a suitable replacement for git for general use." If you use Claude Code on your own projects, keep Git.
This site is independent and is not affiliated with Anthropic. What we say about Scion comes from Anthropic's engineering post, which we reopened on 2026-10-13. We did not run Scion, and nothing here is a hands-on test.
What Anthropic announced
The post is titled "Redesigning source control at Anthropic". It is written by Nick G. and the source control team. It covers two systems: Scion, the version control system, and Antique, a code review tool.
It opens with the problem: "As our merges per day grew more than tenfold, source control became our biggest development bottleneck."
Why Git stopped fitting
The trigger was volume, as the Anthropic engineering post lays out. In May 2026, Anthropic averaged around 2,500 code changes merged per day, and as of September it merged over 30,000 per day.
The post explains the cause in one sentence: "At Anthropic, coding is no longer the bottleneck to building systems or doing research." The rest of it is about the tool that stores and merges all that code.
Two size numbers come from the same post. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB.
Traffic adds to it. Anthropic says it runs on the order of 25 million code checkouts per day for CI, the automated test runs. That count comes before developer environments, agent sandboxes and research jobs.
The post adds: "Fetched naively, that would be over 600 PB of git traffic per day."
What Scion does differently
The post lists its design principles under the line "Our principles are:". Two are easy to grasp without an engineering background.
- Always online. The post puts it plainly: "Clients are always online."
- No classic merge queue. Anthropic says a proper merge queue "doesn't make much sense at agent scale", and it tests changes after merging instead.
On the second point the post is direct: "We haven't been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we've invested in post-merge and pre-deploy automated testing."
Two more principles are worth knowing by name. The post says "Commits must be cheap, incremental, and lock-free". It also says "The working copy is optional, and sparse by design."
The Claude moves worth stealing, by email
Workflows tested on real jobs, sent only when they are worth it. Free.
What Anthropic says it gained
These are Anthropic's own figures about its own system, from the engineering post:
- The post says "Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements."
- CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes).
- CI alone realized a 25% CPU capacity win.
- A team of seven people built both Scion and Antique, and the migration took five months.
We have not measured any of this. Treat it as a vendor describing its own work.
What it means if you use Claude Code
Keep Git. Anthropic says the Scion concepts "really only make sense for truly enormous monorepos", the kind with tens of thousands of engineers or swarms of agents writing code. A personal project, a small team or a client site is none of those.
Anthropic also says what it hopes to share: "We think the most impactful thing we can do is to share our thinking". The aim is that other developers can apply the useful parts of Scion to Git.
Our read, not Anthropic's: do not copy the test-after-merge habit. Anthropic chose it because it could not replicate a global lock at its volume. On a small repository, testing before you merge is still the safer default.
The small-scale version: one worktree per agent
There is still a lesson at your size. When several agents edit the same files, their changes can collide. The Claude Code docs describe the fix: "Running each Claude Code session in its own worktree gives it a separate copy of the files to edit, so one session can build a feature while a second fixes a bug."
The commands below come from the worktrees page of the Claude Code docs. We did not run them for this brief, so treat them as documentation, not as a test.
claude --worktree feature-auth
git worktree list
The first line creates an isolated worktree and starts Claude in it. By default, Claude Code creates worktrees under .claude/worktrees/ and branches them from your repository's default branch.
The second line lists your worktrees.
One link back to the main story: the docs say "Worktrees require a git repository; for other version control systems, configure hooks to replace the git logic". If you ever move away from Git, that is a setup step, not a default.
For the next step, see our guide to running parallel Claude Code agents, then agent teams vs subagents. New to all this? Start with Claude Code for non-developers.
Limits of this brief
- It rests on one source about the system itself: a company describing its own work.
- We did not run or inspect Scion, so we say nothing about how it behaves outside Anthropic.
- The post also covers Antique, which we only mention.
- No worked example is included. Nothing here was tested hands-on, and the worktree commands are quoted from the docs.
Questions
Is Anthropic replacing Git for everyone?
No. The post says "Scion is by no means a suitable replacement for git for general use." Nothing in it asks you to leave Git, including for projects you build with Claude Code.
Why did Anthropic's code outgrow Git?
Volume. Merged changes went from around 2,500 per day in May 2026 to over 30,000 per day by September, and the main branch history alone is almost 100 GB.
Do I need Scion or a merge queue for parallel Claude Code agents?
No. At small scale, give each agent its own worktree so edits do not collide. Our guide to running parallel Claude Code agents goes further.
