Anthropic Scion is the source control system Anthropic built because Git could not keep up with its own AI coding agents. According to Anthropic’s engineering post published on October 13, 2026, the company went from about 2,500 merged changes a day in May to more than 30,000 a day by September, and seven engineers replaced Git in the monorepo in five months.
That is the headline everyone is sharing. The more useful part is buried further down: Anthropic says it expects “this class of problems will become more commonplace over the next six to 12 months.” If your team is pushing agents hard, you are on the same curve, just further back on it.
I read the full post twice. Here is what actually broke, how Scion is built, and the parts you can copy with plain Git today.
What Is Anthropic Scion?
Scion is a centralised, always-online version control system that replaced Git in Anthropic’s monorepo. It is not a fork of Git and it does not speak the Git protocol to its clients.
The design flips Git’s core assumption. Git expects every machine to hold a full copy of history and to work offline. Scion expects an authoritative server and clients that ask for exactly what they need, when they need it.
Anthropic lists six principles in the post:
- Clients are always online. Data is fetched on demand.
- The server does the heavy work. History, blame, commits, merges and rebases happen server-side. The client keeps a bounded object cache, lays out files and watches the filesystem.
- API-first. Every source control query is an API call, so many jobs never need a local repository at all.
- No full copy anywhere. Not even the server materialises the whole repo. There are no packfiles, so there is no repository maintenance.
- Cheap, lock-free commits. Cost scales with the size of the change, not the size of the repo.
- Optional, sparse working copies. Checkouts can be sparse or virtual, with files materialised on first read.
Anthropic is blunt that this is not for everyone. The post says Scion “diverges significantly from git” and the internal components are “highly bespoke.” Moving to it meant replacing code review, code search and CI with internal versions too.
So you cannot install Scion, and you should not want to. What you can do is study why it exists.
Why Git Broke for AI Coding Agents at Anthropic
Git did not fail because of code volume alone. It failed because nearly every client became an always-online machine that wanted a fresh checkout.
These are the numbers from Anthropic’s post, and they are worth reading slowly:
| Metric | Value |
|---|---|
| Daily merges, May 2026 | ~2,500 |
| Daily merges, September 2026 | 30,000+ |
| Main branch history | ~100 GB |
| Compressed working copy | 25 GB+ |
| CI checkouts per day | ~25 million |
| Naive Git traffic per day | 600+ PB |
(Source: Anthropic, Redesigning source control at Anthropic, Oct 13, 2026)
The 25 million checkouts are for CI alone, before developer environments, agent sandboxes and research jobs. That is the line that changed my mental model of this problem.
Human developers clone a repo once and fetch small deltas for months. An agent sandbox is born, clones, works for twenty minutes and dies. Multiply that by thousands of parallel sessions and Git’s “everyone gets everything” model turns into a bandwidth bill measured in petabytes.
Anthropic’s workarounds will sound familiar to anyone who has run a large monorepo. At peak it ran several hundred internal Git mirrors. Seed snapshots drifted from the tip of main. Diff and blame on partial clones got harder to keep working.
None of these are exotic failures. They are the normal pain of a big repo, compressed into four months instead of four years.
- September 2026 30,000
- May 2026 2,500
Source: Anthropic, Redesigning source control at Anthropic (Oct 13, 2026)
The conclusion for everyone else: agent workloads are checkout-heavy and fetch-heavy in a way human teams never were, and that is where Git strains first.
How Scion Works: Changesets, Spanner and Three Cache Tiers
The architecture is more conventional than the hype suggests, which I mean as a compliment.
The unit of work is a changeset, an entry in a write-ahead log. Each changeset lists the files changed relative to its first parent and points to compressed, content-addressed blobs in cloud storage. Refs, the pointers like main, are updated with a compare-and-swap on a single Spanner row. Anthropic discourages refs for anything but main and release branches.
Derived data such as blame, path history, commit-graph skip lists and copy detection is computed incrementally from parent values. Each type can be computed eagerly or lazily, and the client never needs to know which.
Serving runs in three strictly separated tiers:
- scion-daemon, one per node, shared by every job on that machine
- scion-cache, regional and in-memory
- scion-server, the authoritative layer reading from Spanner or cloud storage
Anthropic reports a cache hit rate above 99% at every tier. Because content is addressed by hash, any server can cache any object without coordination.
The fetch protocol is where it really departs from Git. Git negotiates by telling the server what you already have. Scion’s client starts from a root tree and asks only for the trees and blobs it wants, in small resumable objects instead of one big packfile. Sparse and virtual checkouts fall out of that design for free.
The most opinionated choice is the merge queue. Anthropic did not build a global serialised queue, because a global lock does not survive 30,000 merges a day. It relies on post-merge and pre-deploy testing instead, and accepts that concurrent changes will sometimes conflict. The post’s justification is that Claude usually fixes those conflicts faster than a human would notice them.
That is a real tradeoff, not a free lunch. It works when you have strong automated bisect and revert pipelines, which Anthropic says it does. Without those, dropping a strict merge queue just means a broken main branch more often.
Scion Results: 200x Smaller, Seconds Instead of Minutes
The results section is short and very specific:
- About 200x less CPU and memory than the previous Git mirroring setup
- CI and research checkouts went from minutes to seconds, which Anthropic describes as two orders of magnitude
- A 25% CPU capacity win for CI alone
- Merge volume grew more than tenfold during the migration itself
One detail stood out to me. Claude Mythos Preview rewrote the handwritten Git-to-Scion ingestion pipeline with no further instructions, and the new version used 20x less memory and ran 4x faster while keeping the ordering guarantees intact. Anthropic also credits Claude with finding an optimisation to ancestry queries that an expert “might have taken days or weeks” to spot.
The team also built Antique, a code review tool, in the same five months. Antique supports semantic approval rules that separate comment-only edits from sensitive logic changes. It runs the merge queue, and that queue is watched by a dedicated Claude agent that Anthropic calls a “superfan”.
These are vendor-reported numbers about a vendor’s own infrastructure, with no outside audit. I still find them believable, because the post is unusually open about what went wrong and what Scion cannot do.
What Anthropic Learned About Engineers and AI Agents
The lessons section reads more like a management memo than an infrastructure write-up, and it is the part I expect to age best.
Anthropic says its engineers rated Claude as better at writing code than they were. Their value moved to architecture and tradeoffs, and a lot of their job was telling Claude “no” when a change violated a system constraint. The example given is Claude writing systems that linearly scanned the commit log instead of querying the code review tool.
They also found that adversarial AI review has limits. It can be myopic and pile on unnecessary validation. Engineers now review the intent of a change rather than every line.
If you are working out which skills still carry a premium, this is the same shift covered in our AI developer salary breakdown: system design and judgement pay, typing speed does not.
The takeaway: at agent scale, the bottleneck moves from writing code to deciding which code should exist.
Should Your Team Replace Git? Scion vs Git Scale Features
For almost every team, the answer is no. Anthropic needed Scion at 30,000 merges a day, a 100 GB history and 25 million daily CI checkouts. You are probably several orders of magnitude away from that.
What you should do is use the parts of Git built for exactly this pressure. Here is how Anthropic’s approach maps to tools you already have:
| Scion idea | What you can use today |
|---|---|
| Fetch on demand | Partial clone via scalar clone (commits and trees only) |
| Sparse working copy | git sparse-checkout, on by default with Scalar |
| No manual maintenance | Scalar background maintenance (commit-graph, prefetch) |
| API-first diffs for CI | Hosted Git APIs for diffs instead of full clones |
| No global merge lock | GitHub merge queue with grouping and 1 to 100 concurrent builds |
| Server-side scale | Meta’s Sapling, built for always-online monorepos |
(Sources: Git scalar docs, GitHub merge queue docs, Sapling docs)
The cheapest win is Scalar, which ships with Git. According to the Git documentation, scalar clone fetches only commit and tree objects, turns on sparse checkout, and registers the repo for background maintenance:
scalar clone https://github.com/your-org/monorepo.git
cd monorepo/src
git sparse-checkout set services/api packages/sharedFor agent sandboxes, that one change can turn a full clone into a few directories plus history metadata. Pair it with a shallow or blobless clone in CI and most mid-sized teams will not feel Git’s limits for a long time.
The second win is a merge queue. GitHub’s queue validates each pull request against the latest base branch plus the PRs ahead of it, and lets you set build concurrency anywhere from 1 to 100. If your agents open dozens of PRs a day, this is where conflicts get caught before main breaks. Pair it with the review gates in our AI code review automation blueprint.
Sapling is the interesting middle ground. Meta says it was built to scale its monorepo and is most polished in “always-online, single-master, rebase-instead-of-merge, monorepo environments”, which is almost word for word Scion’s assumptions. The catch is that its virtual filesystem is still not publicly available, so outside Meta you get the client experience without the full scaling story.
What Scion Means for Claude Code and Codex Users
If you run Claude Code or Codex cloud sessions, every task starts with a clone in a fresh container. That is the same pattern that broke Git at Anthropic, at a smaller scale. Our Codex Cloud vs Claude Code on the web comparison covers how each product handles environments and setup scripts, and that is the right place to look if checkout time is eating your session budget.
The bigger signal is the partnership line. Anthropic says it wants to work with GitHub, GitLab and the open source community on server-side RPCs, new server architectures and composable sparse and shallow features. If that happens, the fixes will land in the Git hosting you already use.
My read is that Scion matters less as a product than as an early warning. As covered in our agentic coding guide, agents multiply output. Anthropic is telling everyone where that output hits infrastructure first.
Start measuring clone time, CI checkout volume and merge conflict rate now. Those three numbers will tell you how far along the curve you are.
On the model side this week, Meta launched a frontier model priced exactly like Claude Opus 5.5; I compared the two in the Muse Wonder vs Claude Opus 5.5 breakdown.
