Git gives every client the whole repo. At 30,000 merges a day, Anthropic built Scion instead

What Scion is, and what it is not

Scion is the version control system Anthropic built for its own monorepo, the single repository that holds most of its code. Anthropic moved that repository off git onto Scion in five months during 2026. Alongside it the same team built Antique, a code review tool, plus code search, access control for source code and other pieces of the development workflow. The command-line client is called scn.

Scion is internal. Anthropic has not released it, and says that a public version would be hard to make useful: it differs from git enough that a company would have to move its whole workflow, including code review, code search and CI, to tools built around it. Anthropic also says plainly that Scion only makes sense for very large monorepos with tens of thousands of engineers or large numbers of agents writing code, and that it is not a general replacement for git.

So the interesting part is not the tool itself. It is the design argument behind it, which other teams can apply to git servers and to other parts of their infrastructure.

Why git strained at Anthropic's scale

Anthropic says it merged around 2,500 code changes a day in May 2026 and more than 30,000 a day by September. Its chart of daily merges shows a peak of 30,401 on 9 September, with most changes arriving as Antique change requests rather than pull requests from about July onwards.

The repository those changes land in is large:

• the history of the main branch alone is almost 100 GB
• a compressed working copy is over 25 GB
• CI checks the repository out on the order of 25 million times a day, before counting developer machines, agent sandboxes and research jobs

Anthropic's own estimate is that fetching all of those checkouts naively would mean over 600 PB of git traffic a day. That is roughly the 25 GB working copy multiplied by 25 million checkouts; it is a measure of the problem, not traffic that was actually sent.

Git already has tools for working with part of a repository: shallow clones (only recent history), sparse checkouts (only some directories), and partial clones with promisor remotes (objects fetched on demand). Large monorepos usually add internal git mirrors and seed snapshots: a periodically refreshed copy of the repository kept in blob storage, which a new machine starts from. Anthropic used all of these, with several hundred mirrors at its peak, arranged as a packfile cache in front of mirror replicas and mirror primaries in each cluster. They report that this bought time but got harder to run as the merge rate grew. Seeds drifted further from the tip of main between refreshes, and keeping history-based commands such as diff and blame working on partial clones took more and more care.

The assumption Scion changes: clients are always online

Git is decentralized. Every clone is a full repository that can compute diffs, show history and blame, and check out any revision with no network at all. For most repositories that is the right design, and Anthropic says so.

Anthropic's observation was that it used git as a centralized system with one authoritative copy, like most companies do, and that nearly all of its clients were agents and jobs that are online by definition. The properties that make git good at offline work were the ones making it hard to scale. Scion is built on a set of principles that follow from dropping that assumption:

• Clients are always online. The client and its protocols assume a server that is always reachable, and fetch data when it is needed.
• Client and server are not equals. In git any client can act as a server. In Scion the server answers history and blame questions, creates commits and performs merges and rebases. The client keeps a bounded local object cache, lays out the working copy, watches the filesystem for changes, and computes very little on its own.
• Every query is also an API. Anything the client can ask is exposed to other programs, so a CI job that needs to know who last changed a line, or how two commits are related, can ask instead of keeping a copy of the repository. Anthropic says its automated bisect and revert pipelines depend on this.
• Everything scales horizontally. There is no fully materialized copy of the repository anywhere, not even on the server, and no packfiles, so there is no repository maintenance to run.
• Commits are cheap, incremental and lock-free. Every commit, rebase and merge happens on the server, and its cost has to scale with the size of the change rather than the size of the repository. Refs such as branches and tags are discouraged except for main and release branches, because global state every server must agree on is a scaling problem.
• The working copy is optional. A job that needs the diff between a commit and its merge base asks for it. When files are needed, checkouts are sparse (only the directories asked for) or virtualized (files appear on disk when read).

How a commit is stored: changesets and derived data

The video skipped this part. In Scion the unit of work is a changeset, an entry in a write-ahead log. It carries what you would expect from a git commit: author, dates, message, parents and an optional signature. The difference is in how it describes the files. A git commit points at a tree that describes the whole repository. A Scion changeset lists only the files that changed relative to its first parent, each with a content-addressed pointer to its compressed contents in cloud storage. Metadata lives in Spanner, Google's distributed database.

Because accepting a changeset involves no packfile, no lock, no coordination between servers and no ref update, the server can accept them at very high throughput. Moving a ref, when one is used, is a compare-and-swap on a single Spanner row, done separately from creating changesets.

A list of changes cannot answer "who last edited this line" on its own. Scion builds extra structures from the changesets for that: blame data, path history, skip lists over the commit graph and, later, indexes for copy detection and path search. Anthropic calls all of it derived data. Each kind is defined recursively, so its value for a changeset is computed from its values for that changeset's parents. That gives three benefits Anthropic names: new kinds can be added when an operation needs to be faster, each kind can be computed eagerly or only when asked for, and the client never sees these structures, so they can change without touching it.

How a checkout fetches: asking for named objects

All source control data in Scion is content-addressed: every object is named by a hash of its contents. Git's own objects work this way too. What differs is the fetch.

In a git fetch, the client tells the server which objects it already has, and the server works out what is missing, compresses it against what the client holds and sends a single packfile. That work is specific to each client. Scion's client never says what it has. It starts from a root tree, checks its local store, asks for the trees it is missing, recurses, then does the same for file contents (blobs). Every request names one object that will never change, so any cache can answer it, and a fetch that stops halfway can resume. Sparse and virtualized checkouts need no special support: the client simply does not ask for trees it does not want.

The three cache tiers

• scion-daemon runs on every machine in the fleet. Jobs on the same machine talk to it over a socket and share its object store, because most of them need the same objects. It starts from a periodic snapshot.
• scion-cache runs in each region. It streams objects from memory in the format the daemon stores them in, so it does not compute missing objects or compress deltas.
• scion-server is the authoritative tier. It reads from Spanner and cloud storage, computes derived data on the fly and writes it back.

All three answer the same RPCs, so a client does not need to know the topology. Anthropic still enforces the tiering strictly so that a failure in one regional cache cannot overwhelm the servers. Each tier keeps a cache hit rate above 99%.

What the numbers count

Anthropic reports that Scion's infrastructure needs 200 times less CPU and memory than the git mirroring setup it replaced. CI and research jobs check out code about two orders of magnitude faster, in seconds rather than minutes, and CI alone freed 25% of its CPU capacity.

The per-command figures are medians from Anthropic's chart, git against scn on the monorepo. dev is a developer environment, agent an agent environment, CI a CI job and job a compute job; per change is the total source control time for one change request.

dev   pull latest     87 s → 3.5 s
dev   checkout        15 s → 1.1 s
dev   status         3.9 s → 19 ms
agent new worktree 7.1 min → 5.1 s
agent pull latest  3.0 min → 9.0 s
agent commit          18 s → 761 ms
agent per change    34 min → 3.7 min
CI    checkout        31 s → 3.5 s
job   checkout       175 s → 22 s

Anthropic's chart attaches about 11,000 agent hours a day to the per-change-request figure, about 195,000 machine hours a day to CI checkouts and about 85,000 to compute job checkouts. The chart does not say in words whether those are hours saved, though that is the natural reading. The commit figure in developer environments barely moved (1.4 s to 1.1 s), which is worth noticing: a commit is already local and small in git, and Scion's advantage is in moving and querying data.

How seven people built it in five months

A team of seven built Scion, Antique and about half a dozen related systems and migrated the monorepo in five months, while daily merges grew tenfold. Anthropic attributes the pace to Claude, and gives a few specifics:

• The first git-to-Scion ingestion pipeline was mostly written by hand. Asked to rewrite it, an early internal snapshot of Claude Mythos Preview produced a version using 20 times less memory and running 4 times faster, keeping the ordering rules the original relied on.
• Every engineer on the team rates Claude as a better coder than themselves, but the engineers supplied the system design and the trade-offs. Anthropic says their job was often to tell Claude no, for example when migrated systems tried to find when a change merged by scanning the commit log rather than asking the code review tool.
• Adversarial review by agents caught a lot but could also push toward over-engineering, such as excessive validation against a trusted internal service. Engineers review the intent of every change rather than every line.
• The codebase has hermetic simulations of the infrastructure and source control interactions the team has seen, plus fuzzing and rate limiting.
• The team runs Claude agents in Slack through Claude Tag, each focused on the health of one component (a scion-daemon one, a scion-cache one, one for the merge queue) with access to telemetry and logs. Anthropic calls them superfans and says they catch subtle problems that ordinary alerts miss.

What else changed: the merge queue and CI

Anthropic says a conventional merge queue, which locks the repository while each change is tested in order, does not work when hundreds or thousands of changes can merge while one test run is going. Rather than a global lock, it invested in testing after merge and before deploy. That means concurrent changes can conflict, and Anthropic says Claude usually fixes those conflicts faster than a person could find them.

Prior art: Piper, Sapling and Mononoke

Anthropic names Google's Piper and Meta's Sapling as prior art for source control at monorepo scale. On 14 October Rain, who helped build Mononoke, the open-source server behind Sapling, published a post arguing that Scion's derived data closely follows Mononoke's design, and that Mononoke should have been credited by name. That is Rain's account; Anthropic's post does not mention Mononoke. Either way, Sapling's documentation and Mononoke's source are useful companions to Anthropic's post for anyone interested in the design.

What Anthropic suggests for git

Anthropic expects this class of problem to reach other companies within six to twelve months, and argues that most of the benefit can come to git without leaving it: a git server does not have to work like a git client, git hosts could offer server-side RPCs for history and blame the way Scion does, the fetch negotiation could change, and git's sparse and shallow features could be made to work well together. It names GitHub, GitLab and the open-source community as the partners it wants to work with.

Terms

Monorepo

One repository holding most or all of a company's code, rather than one repository per project.

Decentralized version control

A design, git's, where every clone is a complete repository that can do everything offline.

Working copy

The files checked out on disk for editing or building. In Scion it is optional.

Sparse checkout

A checkout that contains only the directories you ask for.

Virtualized checkout

A checkout whose files appear on disk only when something reads them.

Promisor remote

In git, a remote that a partial clone can fetch missing objects from later, on demand.

Packfile

Git's compressed bundle of objects, used for storage and for sending fetches.

Content-addressed storage

Storage where each object is named by a hash of its contents, so a name always means the same bytes and an object never changes.

Changeset

Scion's commit: a write-ahead log entry listing the files changed since its first parent, with pointers to their contents.

Derived data

Structures Scion computes from changesets, such as blame and path history, so those queries are fast.

Merge base

The most recent commit two branches share; a diff against it shows what a change actually adds.

scion-daemon, scion-cache, scion-server

Scion's three cache tiers: per machine, per region, and authoritative.

Spanner

Google Cloud's distributed database, where Scion keeps changesets and other metadata.

Antique

Anthropic's internal code review tool, built by the same team.

Questions

// further reading

• Redesigning source control at Anthropic ↗: Anthropic's full post, with the figures used here
• Anthropic's Scion is heavily inspired by Mononoke ↗: Rain's comparison with Mononoke's derived data
• Sapling ↗: Meta's open-source source control system, whose server is Mononoke
• Partial clone in git ↗: git's documentation for promisor remotes and on-demand objects