In May 2026, Anthropic merged about 2,500 code changes a day, and by September it merged over 30,000. AI agents drove that growth, and Git, the tool most of the world's programmers use to store code, could not keep up. Seven engineers built a replacement called Scion in five months, and Anthropic described the design in its engineering post.

This article explains what Scion is and how it works, starting from zero.

First, the basics

Version control is the history feature of Google Docs, built for code. Each time a programmer finishes a meaningful piece of work, the system records a snapshot called a commit, along with a short message describing it. The list of all commits is the history, and the folder that holds the code and its history is a repository. When a change is ready, it gets merged into the main version that the whole team shares.

Git is the standard tool, and it is decentralized. Every programmer keeps a full copy of the repository, history included, on their own laptop. That lets them read history, compare versions, and save work with no internet at all, on a train for example. This design is the reason Git won.

Large companies often keep all their code in one enormous repository called a monorepo. Anthropic keeps all of its code in one.

Where Git broke

Git assumes the programmer is a human with a laptop who goes offline sometimes. Anthropic's programmers are increasingly AI agents, which are programs that run on cloud machines, write code all day, and stay connected to the network the whole time.

Every time an agent or an automated test job starts work, it needs a copy of the code. Getting that copy is called a checkout. CI (continuous integration), the robot system that tests every change automatically, performs about 25 million checkouts a day at Anthropic.

The repository is huge. The history of the main branch is almost 100 GB, and a compressed copy of the code is over 25 GB. Multiply 25 million checkouts by 25 GB and the total passes 600 PB of data movement per day, if every checkout downloads everything. One petabyte is a million GB.

Git has tricks for this: partial copies, snapshots, and mirrors, which are extra servers that hold copies of the repository so the main server is not overloaded. Anthropic used all of them and at peak ran several hundred mirrors. The mirrors fell behind the main version, and keeping hundreds of them healthy got harder as merges increased.

Then Anthropic noticed something. Git lets every client work alone, but nearly every Anthropic client was online all the time. The company was paying for offline support and never using it.

Picture a video streaming service. Git's approach downloads the entire catalog to every device before anyone presses play, so everything works offline. When 25 million devices join every day, the service ends up running hundreds of extra servers just to keep those copies current. Scion's approach streams only the part each viewer asks for.

How Scion works

Four ideas make it run.

1. A smart server and a thin client

In Scion the server does the thinking. It answers questions about history, runs blame (a feature that shows who last edited each line), creates commits, and performs merges. The client on the programmer's machine keeps a small cache of files, arranges them on disk, and watches for edits. It computes very little and stores very little.

Every question the client can ask is also available as an API, which is a way for programs to ask the server directly. A test job that wants to know who changed a line sends a request and gets an answer, with no copy of the repository on its machine. Anthropic's automated bisect (finding which change broke something) and revert (undoing a bad change) pipelines depend on this cheap access.

2. Changesets in an append-only log

In Git, a commit points to a full snapshot of the project's folders. In Scion, the basic unit is a changeset, which lists only the files that changed, plus pointers to where their new contents sit in storage.

Changesets go into a write-ahead log, which works like a notebook where new entries are added at the end and old entries are never edited. The server creates each changeset itself, so nothing has to be uploaded, and no locks make writers wait for each other. Many agents write at the same time without queueing.

Git also has branches, which are named pointers to commits. Scion discourages them beyond the main branch and release branches, because every server must agree on where each pointer points, and that agreement gets expensive at scale. Moving the main pointer is a single update on one row of Spanner, Google's distributed database, using a compare-and-swap, which means the update succeeds only if nobody else changed the row first.

3. Derived data

A changeset lists only changes, so questions like "who last edited this line?" or "which commits touched this file?" need extra lookup tables. Scion builds them as derived data, much like the index at the back of a textbook.

Each table is computed from the entries for earlier changesets. It can be built immediately or only when someone asks. Clients never see these tables, so engineers can add or improve them without breaking anyone. Copy detection and file search were added this way as the system grew.

4. Fingerprinted files and three layers of caches

Every file and folder is stored under a name made from its own contents, a fingerprint. Identical content gets the same name, and changed content gets a new one. Stored data therefore never changes, and a copy kept anywhere is always valid. No cache has to ask whether its copy is still current.

A checkout works from the top down. The client asks for the root folder listing, then for the subfolders it lacks, then for the files. A job that needs only one directory skips the rest. Every request is small and resumable if the network drops. Git sends one huge compressed bundle called a packfile, and Scion has no equivalent.

Think of a neighborhood store, a regional distributor, and a factory. Three layers of servers work the same way:

  • scion-daemon runs on every machine and acts as the neighborhood store, shared by all jobs on that machine.

  • scion-cache servers sit in each region as the distributor, hold objects in memory, and send them in exactly the format the machine saves.

  • scion-server is the factory and the final authority. It reads from Spanner and cloud storage.

agent / CI job
      │
scion-daemon     on every machine
      │
scion-cache      regional, serves from memory
      │
scion-server     authoritative
      │
Spanner + cloud storage

All three layers answer the same requests, so the client never needs to know how they are arranged. Anthropic enforces the order anyway. If a regional cache fails, it cannot flood the main servers. Each layer answers over 99% of requests on its own.

The results

Scion's infrastructure needs 200 times less CPU and memory than the old mirror fleet. Checkouts for CI and research jobs run two orders of magnitude faster, down from minutes to seconds. CI alone gained 25% CPU capacity.

The people side

Seven engineers built Scion, the Antique code review tool, and about half a dozen related systems in five months. Merge volume grew tenfold during that time.

Claude wrote much of the code, and every engineer on the team rates it better at writing code than themselves. Their work shifted to design decisions and to saying no. Agents sometimes broke core rules to satisfy a familiar pattern. Several systems, for example, found out when a change had merged by scanning the commit log line by line, while the review tool already held that answer. Reviewers now read the intent of each change request, and reading every line has ended.

One result stands out. The first version of the pipeline that imports Git history into Scion was written by hand. An early snapshot of Claude Mythos Preview rewrote it with no extra instructions, and the new version used 20 times less memory and ran 4 times faster, with all ordering rules intact.

The team also tested heavily. It built simulations of every tricky infrastructure interaction it had seen, and added fuzzing (feeding random input to find bugs) and rate limiting.

The merge queue

A merge queue is a line where changes wait their turn so tests can run on each one before it joins the main version. At 30,000 changes a day, with hundreds landing while tests are still running, a single global lock on that line does not work. Anthropic moved its testing to after the merge and before deployment. Changes can now conflict with each other, and Claude fixes most conflicts faster than a human can spot them.

Can you use Scion?

No. Anthropic has not released it and says Scion is not a suitable replacement for Git in general use. It fits enormous monorepos with tens of thousands of engineers or swarms of agents, and it depends on Anthropic's own code review, code search, and CI. Anthropic also notes that its internal spending on tokens is far beyond what other companies would choose to spend.

The company hopes GitHub, GitLab, and the open source community will bring Scion's server-side ideas into Git. Google and Meta built similar centralized systems earlier: Piper at Google, and Sapling with its Mononoke server at Meta. Anthropic credits both.

Git remains the tool to learn. The lesson to carry out of this story is how Anthropic reached its design. The team asked who its users were, found they never go offline, and rebuilt around that fact.

A design lasts exactly as long as its assumptions about the user hold.