Source control / An instrument for Git users

Scion,
explained through Git.

On October 13, 2026, Anthropic described Scion, the version control system it built to replace Git for its monorepo. Rather than read about it, operate it: change a file and record it in both systems, fetch that revision, send jobs through Scion’s cache tiers, and ask the repository a question with no checkout at all.

4 scenes · A closing · Sources and limits · Reading view

Documented What Anthropic’s post states, or Git’s own documented behavior, with where it says so.

Illustration Invented for this page: the repository, every id, the presets and every count on a stage. Counts are objects and requests, never bytes or time.

Git · Scion · ■ blob · ▬ tree · ● commit or job · ⬡ changeset · ⚑ ref · Reused an object a revision points at again

Edit / 01

Change one file. Follow the revision.

Edit a file in the fictional repository and record it. Git writes a blob, a new tree for every directory up the path, and a commit, all in the local repository; everything else is reused by id. Scion’s changeset, created on the shared service, lists only what changed relative to its first parent. Click any object to see what it references.

Documented

A Git commit points to a tree; trees point to trees and blobs, each named by a hash of its content. Post · Data structures, and Git documentation
A changeset stores the files that changed relative to its first parent, with content-addressed pointers to the compressed contents in blob storage. Post · Data structures
Changesets are created server-side, so there is nothing to push. Post · Data structures, and Principles
Moving a ref is a compare-and-swap on a single Spanner row, separate from creating changesets. Post · Data structures

Illustration

The repository, its file contents and the revision names r1, r2, and so on.
Every id: toy hashes of content, four characters shown. Git’s real ids are SHA-1 or SHA-256; the post does not describe Scion’s scheme.
Changeset labels S1, S2, and so on, and the compare-and-swap’s expected and new values.

Git, recording r3

Before r3: the store holds everything up to r2.
Git hashes each changed file into a blob: 1 new blob.
Every tree on a changed path gets a new id, bottom-up: api/ and the root. Untouched trees are reused by id.
The commit points at the new root tree and at its parent commit, 2fa7. Git writes all of this in the local repository.

Scion, recording r3

Before r3: the store holds everything up to r2.
Scion keeps each changed file’s compressed content in blob storage under a content-addressed pointer: 1 new blob.
The changeset lists only the changed path: api/handler.py. No directory is rewritten.
Changeset S3 records those paths and pointers relative to its first parent, S2. It is created on the shared service.

Git: 1 new blob, 2 new trees and 1 commit; 10 objects reused by id.

Scion: 1 new blob and changeset S3, listing 1 changed path.

Then, separately, the ref update

Git: In Git, the commit moved the local branch main in the same command. Sharing it is a separate push. Scion: Changeset created. The ref main still points where it did: creating a changeset moves no ref.
Git: Nothing further happens locally: main already names the new commit. Scion: Compare-and-swap on one Spanner row: set main to the new changeset only if it still names the expected one.
Git: Local main names the new commit. Scion: The row matched, so main moved. This is not a landing workflow, which the post does not describe.

Fetch / 02

Get this revision.

Another client now needs the revision you recorded. Git advertises refs, negotiates wants and haves, and answers with one pack. Scion’s client walks from a root tree and asks for each object it lacks by name. Change the scope, the client’s starting point or the Git configuration, and watch what travels.

Documented

Scion’s negotiation does not tell the server what the client already has; it operates only on the trees and blobs the client wants. Post · Scaling Scion
From a root tree, the client checks its local store for missing trees and requests them recursively, then does the same for blobs. Every request is for one object that never changes. Post · Scaling Scion
There is no single multi-gigabyte packfile response, and a sparse checkout needs no special support: the client does not ask for trees it does not want. Post · Scaling Scion
Git’s fetch advertises refs, negotiates wants and haves, and answers with a pack; a partial clone’s filter leaves blobs to be fetched later, on demand. Git documentation

Illustration

Message granularity: each arrow is one message in a simplified model of each protocol, and only the two Git configurations it models faithfully are offered.
The Scion trees: the post does not say how a checkout’s root tree is built from changesets, so these trees are a teaching representation.
Every count. They count objects and requests, never bytes or time, and they are not a score between the systems.

A fresh client, whole tree, full clone: Git

Ref advertisement: the server lists its refs, and main names 2754.
The client wants 2754 and has nothing.
One pack: 22 objects (3 commits, 9 trees, 10 blobs), everything reachable from the want that the haves do not already reach.

A fresh client, whole tree, full clone: Scion

The client asks for the root tree of this revision: one request, naming one object. How that root tree is built from changesets is not in the post.
1 object delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.
The client checks its local store and requests 3 missing trees, each by its own id.
3 objects delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.
The client checks its local store and requests 1 missing tree, each by its own id.
1 object delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.
The client checks its local store and requests 8 missing blobs, each by its own id.
8 objects delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.

Git (full clone, sparse checkout): 22 objects delivered in 3 messages.

Scion: 13 requests, 13 objects delivered.

A client holding r2, api/ only, blobless partial clone: Git

Ref advertisement: the server lists its refs, and main names 2754.
The client wants 2754 and says it has 2fa7, with the filter blob:none.
One pack: 3 objects (1 commit, 2 trees), everything reachable from the want that the haves do not already reach, with blobs filtered out.
Checking out api/ only needs 1 blob the client lacks, so Git fetches it on demand.
A second pack delivers 1 blob. History-dependent work on a partial clone, like diff and blame, “took more and more care,” the post says.

A client holding r2, api/ only, blobless partial clone: Scion

The client asks for the root tree of this revision: one request, naming one object. How that root tree is built from changesets is not in the post.
1 object delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.
The client checks its local store and requests 1 missing tree, each by its own id.
1 object delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.
Trees, level 2: all held. Nothing travels.
The client checks its local store and requests 1 missing blob, each by its own id. 2 objects already held, walked locally.
1 object delivered, each exactly the object named. Any cache could have answered, because none of them ever changes.

Git (blobless partial clone, sparse checkout): 4 objects delivered in 5 messages.

Scion: 3 requests, 3 objects delivered.

Fleet / 03

Send another job.

In Anthropic’s fleet a job’s client asks its node’s scion-daemon, which asks its region’s scion-cache, which asks scion-server. Click a node to send a job. Then go back to scene 1, record another revision, and send the same jobs again: old objects stay useful, and only new ones travel.

Documented

A job’s client talks over a socket to scion-daemon, which stores objects for the whole node and starts from a periodically refreshed snapshot. Post · Scaling Scion
The daemon talks only to scion-cache in its region, which streams objects from memory in the format the daemon consumes. A cache miss goes to the authoritative scion-server, which reads Spanner or cloud storage. Post · Scaling Scion
All three tiers answer identical RPCs, and the tiering is strictly enforced to isolate failure domains. Post · Scaling Scion
Before Scion: several hundred internal Git mirrors at the peak, and seeds that fell further from the tip of main between refreshes. Post · Growing our monorepo

Illustration

Two regions of two nodes, the node and cache presets, and how old a fresh node’s snapshot is. What a snapshot holds is not in the post.
Every count on the fleet board. The hit rate Anthropic measured is in the closing; this model does not produce it.

Each level of each job’s walk

Node A1, r3, the root tree: 0 hits at the daemon and 1 answered by the regional cache.
Node A1, r3, trees on level 1: 2 hits at the daemon and 1 answered by the regional cache.
Node A1, r3, trees on level 2: 1 hit at the daemon.
Node A1, r3, the blobs: 7 hits at the daemon and 1 answered by the regional cache.
Node B1, r3, the root tree: 0 hits at the daemon and 1 fetched from scion-server through the regional cache.
Node B1, r3, trees on level 1: 1 hit at the daemon and 2 fetched from scion-server through the regional cache.
Node B1, r3, trees on level 2: 1 hit at the daemon.
Node B1, r3, the blobs: 6 hits at the daemon and 2 fetched from scion-server through the regional cache.
Node A1, r4, the root tree: 0 hits at the daemon and 1 fetched from scion-server through the regional cache.
Node A1, r4, trees on level 1: 1 hit at the daemon and 2 fetched from scion-server through the regional cache.
Node A1, r4, trees on level 2: 1 hit at the daemon.
Node A1, r4, the blobs: 6 hits at the daemon and 2 fetched from scion-server through the regional cache.

Per job

Node A1 (Region A) checked out r3: 13 lookups at its daemon, 10 hits; 3 answered by the Region A cache; 0 fetched from scion-server through that cache.
Node B1 (Region B) checked out r3: 13 lookups at its daemon, 8 hits; 0 answered by the Region B cache; 5 fetched from scion-server through that cache.
Node A1 (Region A) checked out r4: 13 lookups at its daemon, 8 hits; 0 answered by the Region A cache; 5 fetched from scion-server through that cache.

Documented The Git side, before Scion. Anthropic ran Git’s standard workarounds: several hundred internal Git mirrors at the peak, and repository snapshots (seeds) kept in blob storage. Seeds fell further from the tip of main between refreshes. Post · Growing our monorepo

Not simulated: the post gives no figures for mirror load or seed age, so this strip is a diagram, not a model.

Query / 04

Ask a question without a checkout.

Many jobs only need an answer: a diff, or a file’s history. Ask one, and see where each system does the work. Under Scion the job’s working copy stays empty and the service answers; under Git the working copy can stay empty too, but the job must already hold the repository’s objects.

Documented

A CI job that needs the diff between a commit and its merge base can ask the server for it, with no checkout. Post · Principles
With Git, a job that asks the repository a question keeps a local copy of it, or relies on vendor-specific APIs. Post · Principles
Path history and blame are derived data, each defined recursively from a changeset’s parents. Each type can be computed eagerly or deferred. Post · Data structures
Servers can compute derived data on the fly and write the results back to Spanner. Post · Scaling Scion

Illustration

The branch graph, with its merge base given rather than computed.
Which policy a type of derived data uses: the post says each type can be eager or deferred, not which path history uses. The tiles are labeled boxes; their structure is not described.

A diff against the given merge base: Git

To diff T2 against r1, the job’s local repository must already hold 3 commits, 8 trees and 6 blobs.
Git compares the two root trees locally and skips every subtree whose id matches.
3 changed paths: api/handler.py, docs/setup.md, and web/app.js.

A diff against the given merge base: Scion

The job asks the service for the diff between T2 and its merge base, r1 (given here, not computed).
The service reads the changed-path lists of T1 and T2 and the content they point at.
3 changed paths come back. The working copy never filled.

File history, computed on first request, asked twice: Git

To list the history of api/handler.py, the local repository must hold 3 commits and 5 trees on its path.
Git walks every commit and compares the path’s tree entries.
2 revisions changed it: r1 and r3.

File history, computed on first request, asked twice: Scion

The job asks for the history of api/handler.py.
No path-history data yet: the service computes it for 3 changesets, each from its parents’ values, and writes it back.
2 revisions changed it: r1 and r3. The working copy never filled.
Asked again: the job asks for the history of api/handler.py.
The service reads path-history data that is already computed.
2 revisions changed it: r1 and r3. The working copy never filled.

File history, computed ahead: Git

To list the history of api/handler.py, the local repository must hold 3 commits and 5 trees on its path.
Git walks every commit and compares the path’s tree entries.
2 revisions changed it: r1 and r3.

File history, computed ahead: Scion

The job asks for the history of api/handler.py.
The service reads path-history data that is already computed.
2 revisions changed it: r1 and r3. The working copy never filled.

Closing

What it bought, and what it costs.

The stages above are illustrations. These are the measurements Anthropic reported, each with the scope the post gives it.

200×

smaller infrastructure footprint than the previous Git mirroring infrastructure, in CPU and memory

Post · Scaling Scion

two orders of magnitude

faster checkouts for CI and research jobs: seconds rather than minutes

Post · Scaling Scion

25%

CPU capacity win realized by CI alone

Post · Scaling Scion

over 99%

cache hit rate maintained by each tier of the checkout architecture

Post · Scaling Scion

7 people · 5 months

a team of seven built Scion and Antique and fully migrated to them in five months

Post · What we learned building Scion

10×

growth in code merged per day over those same five months

Post · What we learned building Scion

Documented Merges: ≈ 2,500 code changes merged per day, averaged, in May 2026; over 30,000 merged per day as of September 2026. Post · Introduction

Two caveats, in the post’s words

“Scion is by no means a suitable replacement for git for general use.”

In practice, “it’s difficult to offer Scion in a form that would be broadly useful” to other organizations.

What the post asks of Git

A Git server does not have to work the way a Git client does: server architectures can scale further without changing the client.
Git platforms can offer comprehensive server-side RPCs, perhaps standardized across forges, that the Git client learns to talk to.
The negotiation protocol need not stay as it is, and Git’s sparse and shallow features can be made to compose well.

Post · Contributing to the wider ecosystem

Calculation Not a measurement, and not part of the fleet model

Naive transfer: every checkout fetches a whole working copy

Checkouts a day, millions Compressed working copy, GB 625 PB a day

Decimal units: a petabyte is a million gigabytes. The defaults are rounded from the post’s own qualified figures, and the product, 625 PB, is consistent with its naive estimate:

on the order of 25 million: code checkouts per day for CI alone, before developer environments, agent sandboxes, and research jobs. Post · Growing our monorepo
over 25 GB: one compressed working copy. Post · Growing our monorepo
over 600 PB: Git traffic per day if those checkouts were fetched naively: an estimate, not a measurement of traffic that occurred. Post · Growing our monorepo
almost 100 GB: the history of the main branch alone. Post · Growing our monorepo

Merges a day and checkouts a day are different quantities, and no control here sets one from the other.

Sources and limits

Source

“Redesigning source control at Anthropic” , Anthropic Engineering, October 13, 2026. Every statement about Scion, and every figure, comes from this post.

Quoted, reported, paraphrased, and invented

Quoted: the two caveats in the closing, and the phrase “took more and more care” in scene 2.
Reported: every figure in the closing, with the scope the post gives it. over 600 PB is the post’s naive-fetch estimate, not observed traffic.
Paraphrased: every Documented statement in a scene’s badges, each with the post section it comes from.
Git background: how Git shares trees and blobs between commits, negotiates a fetch, and filters a partial clone is Git’s documented behavior, given as the baseline the post contrasts with.
Invented for this page: the fictional repository (README.md, api/config.py, api/handler.py, api/routes/users.py, docs/faq.md, docs/setup.md, web/app.js, web/index.html), its revisions and every object id, which are toy hashes; the Scion trees a checkout walks, a teaching representation; the fleet of two regions with two nodes each, its presets and every count; the branch graph with its given merge base; and the derived-data policy switch.

Left unspecified by the post, and so not modeled here

How a checkout’s root trees are constructed from changesets.
The review-and-landing workflow, including when main moves and what moves it.
scn command syntax, and the names of Scion’s APIs.
How edited file contents reach the service when a changeset is made.
Scion’s hashing scheme.
What a daemon’s snapshot contains, and how often it is refreshed.
Which derived-data types are computed ahead and which on first request.

The fleet’s figures

Anthropic reports a cache hit rate of over 99% for each tier. The fleet board in scene 3 does not produce that number and is not evidence for it; its counts come from its presets.