Why Anthropic Replaced Git With Scion, and What Teams Can Learn From It

This week, several outlets reported that Anthropic had replaced git.

For its own monorepo, that's true. Anthropic built Scion, a server-first version control system, and finished migrating off git in five months. Daily merges had grown from about 2,500 in May to over 30,000 in September.

But Anthropic's engineering post is more careful than the headlines. It says Scion is not a suitable replacement for git in general, and that it would be hard to offer to other companies. The more useful story is the assumption that broke.

The assumption

Git gives every clone the whole repository. Offline, you can read history, compute diffs and check out any revision. For almost every project, that's the right design.

Anthropic's clients are mostly agents and CI jobs. They are always online. For them, a full local copy isn't a feature. It's a cost paid on every checkout.

That cost adds up fast. Anthropic reports about 25 million CI checkouts a day, against a working copy over 25 GB compressed. Multiply those and you get over 600 PB of traffic a day if every checkout fetched naively.

The expensive number is checkouts times size, not repo size alone. Anthropic's main-branch history is almost 100 GB. Google reported an 86 TB repository back in 2015. The two aren't measured the same way, but the contrast makes the point: size by itself wasn't what hurt.

Google, Meta and Microsoft got here first

Anthropic says it built Scion with lessons from Google's Piper and Meta's Sapling in mind. Both companies hit this wall years ago.

Google ran one Perforce server on a single machine, with custom caching around it, for more than ten years before building Piper. Piper stores the repository on Spanner. Most developers never clone it. A filesystem called CitC shows them the whole tree and stores only the files they change.

In a 2016 paper, Google reported about 40,000 commits on a typical workday. Roughly 24,000 came from automated systems. The paper adds that humans dominated the commit rate until 2012, and that automated commits grew after Google moved to its custom system.

Meta's Sapling, open-sourced in 2022, follows a similar idea. A server called Mononoke and a virtual filesystem called EdenFS aim to make every operation scale with the files a developer actually uses, not with the size of the repo.

Microsoft took a third route. It kept git, built a virtual filesystem to move the Windows monorepo onto it, and then folded much of the lesson back into git itself. Scalar now switches on partial clone, sparse checkout and background maintenance with one command.

The designs differ. The direction is the same: stop making every client hold everything.

What's actually new

If this is an old story, what's new is the trigger.

Google's automation grew over years. Anthropic's merge rate grew about twelve-fold between May and September, and the team says it doesn't expect that to slow. The team says each bottleneck it removes leads straight to more code. When an agent can produce a change in minutes, the limit moves to everything behind it: merging, building, testing.

Scion's design follows from that. Three choices stand out.

The server does the work. Commits, merges and rebases happen on the server, so there is nothing to push. The client keeps a bounded cache and lays out files on disk.

Source control becomes an API. Questions like who last changed a line, or how two commits relate, can be asked of the server. Many jobs no longer need a local repo at all. Anthropic says its automated bisect and revert pipelines wouldn't be practical at scale without this. It's the idea most teams could borrow first.

Checkouts become cache lookups. The client asks only for the trees and files it wants. Every object is immutable, so ordinary caches can serve it.

flowchart LR
  A[scn client] --> B[scion-daemon<br/>one per node]
  B --> C[scion-cache<br/>regional]
  C --> D[scion-server<br/>authoritative]
  D --> E[(Spanner and<br/>cloud storage)]

Anthropic reports a cache hit rate above 99% at each tier. It says the footprint is about 200x smaller than the old mirror fleet, checkouts take seconds instead of minutes, and CI gained 25% CPU capacity.

Read the numbers with care

Those figures all come from Anthropic's own post. The coverage so far repeats them rather than testing them.

The 200x comparison is against Anthropic's own workaround, a fleet that had grown to several hundred git mirrors. It isn't a comparison against git in general.

The workload is unusual. Anthropic says its internal token spend is far beyond what other businesses would want to spend.

Leaving git also means rebuilding what sits around it. Scion needs its own code review, code search and CI.

And the team gave something up. It couldn't replicate a global lock on its merge queue, so it moved to testing after merge and before deploy. Concurrent changes can conflict. The plan is for Claude to fix them quickly. That bet depends on having agents you trust to do the repair.

What to do if you're not Anthropic

Most teams don't need a new version control system. A few steps are worth taking now.

1. Do the arithmetic. Multiply checkouts per day by working-copy size. If the number is large, CI is the first place to look.

2. Don't fetch what you won't use. GitHub describes blobless clones as the most widely used partial clone option, and treeless clones as a good fit for throwaway build environments. Microsoft notes that shallow clones typically suit build pipelines that don't look at history.

3. For a big monorepo, use sparse checkout. Scalar sets it up for you.

4. Ask the server before you clone. If a job only needs a diff or a blame, check whether your git host's API can answer it.

The question underneath

The most interesting question in Anthropic's post sits just outside version control. What does CI mean when hundreds or thousands of changes can merge while the tests are still running?

Nobody has a settled answer. Anthropic's is to test after merge and let agents repair the fallout. Whether that holds up outside one very unusual company is worth watching.

Sources: Redesigning source control at Anthropic (Anthropic Engineering, Oct 13, 2026); Why Google Stores Billions of Lines of Code in a Single Repository (CACM, 2016); Sapling; The Story of Scalar and Get up to speed with partial clone and shallow clone (GitHub Blog).