Anthropic's Scion: What Happens When Writing Code Outruns Moving It?

Imagine asking an agent for a small change, then watching the job spend longer preparing its workspace than doing useful work. Now imagine launching more agents to make things faster. (The checkout step would like a word.)

That hypothetical is my starting question for Scion: what are we paying to prepare each unit of work? Before getting excited about a new source control system, I want to know which part of the waiting it actually removes. This is a reading of public engineering material, with no hands-on Scion benchmark behind it.

What Anthropic actually built

In its October 13, 2026 announcement, Anthropic describes Scion as an internal version control system, with its monorepo migration completed in five months. It reports daily merges growing from roughly 2,500 in May to over 30,000 in September. Anthropic's engineering account

The design assumes online clients. Servers handle commits, merges, rebases, and history queries; clients cache objects and materialize files. A changeset records changed files relative to its first parent, while derived structures support history queries. Immutable objects flow through layered caches, and clients request the objects they need. Architecture details

Anthropic reports a 200-fold reduction in CPU and memory requirements against its previous Git mirroring infrastructure. That comparison concerns its infrastructure and workload. The company explicitly says Scion is unsuitable as a general Git replacement and describes broader adoption as difficult. Results and limitations

The comparison needs a fair starting point

Git already offers several ways to reduce what a checkout needs. Its clone documentation distinguishes shallow history through --depth, partial object transfer through --filter, and an initially sparse working directory through --sparse. In particular, --filter=blob:none defers file contents until Git needs them. Git clone reference

Sparse checkout selects which tracked paths appear in the working directory. In cone mode, selecting a directory also includes files immediately inside its ancestor directories. It is therefore more precise to say “a selected working tree” than “exactly this one folder and nothing else.” Git sparse-checkout reference

That distinction matters when designing an experiment: history depth, transferred objects, and visible files are separate variables. I would measure them separately before declaring the storage system guilty. (My first diagnosis is not entitled to diplomatic immunity.)

The experiment I would run first

Consider a hypothetical job that checks one package in a monorepo. I would give that job a fixed revision and a representative test command, then record:

1. Time spent waiting for a runner.
2. Time and bytes spent fetching repository data.
3. Time spent preparing files and dependencies.
4. Time spent running the actual check.

Next, I would repeat the same workload with a smaller checkout, recording cold and warm runs separately. The result I want is time to a correct answer, including any later fetches. A quick setup followed by a slow test has merely moved the queue.

Correctness needs its own check: does the reduced workspace still contain the shared configuration and fixtures that the task requires? I would deliberately make a relevant fixture fail and confirm the job catches it before trusting a green result. Otherwise, a faster check might just be doing less checking.

Only after that would I consider a larger infrastructure change. Adding cooks is an expensive way to discover that the kitchen has one cutting board.

The question worth taking back to your pipeline

For me, Scion makes the location of repository work worth examining: which operations belong on each worker, and which could be shared? My interpretation of Anthropic's design

I would start with one slow job and write down what it actually needs: files, history, or a small answer about a revision. Then test the smallest change that removes unnecessary preparation.

If your agents are spending their time waiting, which step owns that wait? That is the graph I would like to see before the migration proposal.