Anthropic moves its monorepo from git to Scion

Why git stopped keeping up at Anthropic

Scion is the version control system Anthropic wrote for its own monorepo, the single repository that holds all of the company's code (Anthropic's engineering post). The trigger was merge volume: as Claude took over more of the coding work, the number of changes landing in that repository every day grew by more than an order of magnitude.

Anthropic's framing is blunt. Writing code is no longer what slows the company down. The slow parts are the systems built for human-paced development: source control, builds and CI. Scion is its answer to the first of those.

Changes merged per day into Anthropic's monorepo

Period	Merges per day
May 2026	about 2,500 (average)
September 2026	over 30,000

Daily merges rose from about 2,500 to over 30,000

Anthropic's monorepo took in roughly 2,500 merged changes a day in May 2026; by September the daily count was above 30,000. The company does not expect that curve to flatten. In its view, demand for merging code has no practical ceiling, and each bottleneck it clears simply lets more code through.

Anthropic also notes that it runs more Claude-written code than almost any other company, so it tends to be the first to find where human-scale tools give out. It expects other teams using AI coding tools to reach the same point before long.

About 25 million CI checkouts a day strained git mirrors

At Anthropic, CI checked out the monorepo on the order of 25 million times a day, and pulling it the default way would have meant more than 600 PB of git traffic daily. That count leaves out developer machines, agent sandboxes and research jobs entirely.

The repository itself is heavy: close to 100 GB of history on main, and a compressed working copy above 25 GB. Anthropic tried the usual tricks: shallow clones, sparse checkouts, promisor remotes, internal mirrors and snapshot "seeds" kept in blob storage. At the peak it ran several hundred git mirrors.

Those workarounds bought time but got harder to run as merges climbed. Seeds fell behind the tip of main between refreshes, and history-dependent commands like diff and blame took more effort to keep working on partial clones.

How Scion works differently from git

Git assumes every clone is a full, self-sufficient repository that can work offline. Anthropic realized it was not using git that way at all: like most companies it treated one copy as the source of truth, and nearly every client was an agent or job that is online by definition. So Scion drops the offline assumption and builds around a server that is always reachable.

The team borrowed lessons from two earlier systems built for very large monorepos, Google's Piper and Meta's Sapling. The table below sums up how responsibilities shift.

Who does the work: git versus Scion

Task	git	Scion
Working assumption	Clients may be offline	Clients are always online
Full repository copy	Every clone has one	None exists, not even on the server
Commits and merges	Made locally, then pushed	Made on the server; no push step
History and blame	Computed from the local clone	Answered by the server
Checkout	Whole repo by default	Only the paths a job asks for

The server handles commits, merges and history

In Scion, the heavy lifting that git spreads across every client happens on the server instead. The server answers history and blame questions, creates commits, and runs merges and rebases. The client keeps a size-capped local cache, writes out the working files and watches them for edits.

Changes are recorded as changesets. A changeset is Scion's equivalent of a commit: an entry in a write-ahead log that lists the files changed relative to the first parent, with pointers to their compressed contents in blob storage. Because the server creates changesets and they are visible everywhere immediately, there is nothing to push.

Creating a commit costs time proportional to the size of the change rather than the size of the repository, which keeps the server ahead of the merge rate. Every query the client can make is also exposed as an API, so many jobs never hold a local copy at all. Anthropic's automated bisect and revert pipelines depend on that cheap programmatic access.

Clients fetch only the files they read

Checkouts in Scion are sparse by design: a job gets only the directories it requests, or files that appear on disk the moment they are read. If a CI job just wants to compare a commit with its merge base, the server returns that diff and no files are written locally.

Data flows through tiers. Each machine runs a scion-daemon that shares objects across the jobs on that node; misses go to a regional scion-cache, and from there to the authoritative scion-servers backed by Spanner and cloud storage. Since stored objects never change, any tier can answer a request without checking with the others.

What the switch changed in numbers

Scion's infrastructure needs 200x less CPU and memory than the git mirroring setup it replaced. Every cache tier serves more than 99% of requests from cache. The headline figures:

Scion after the migration (Anthropic's own figures)

Measure	Result
CPU and memory footprint	200x smaller than the git mirror fleet
CI and research checkouts	Seconds instead of minutes (about two orders of magnitude)
CI CPU capacity	25% freed up
Cache hit rate per tier	Over 99%

Checkouts went from minutes to seconds

Since the move to Scion, CI and research jobs check out code in seconds where they used to take minutes. That speedup returned a good deal of compute to the fleet; CI alone got back a quarter of its CPU capacity.

There is also less to babysit. Neither clients nor caches need repository maintenance anymore, which makes the lifecycle of each job simpler to manage.

Seven people, five months, and Claude writing the code

At Anthropic, a team of seven built Scion, the Antique code review tool and about half a dozen related systems, then finished the migration, all within five months. Over the same stretch, the amount of code merged each day went up tenfold. Work began around the time Claude Mythos Preview and Claude Tag were opened up inside the company.

The ingestion pipeline is the clearest case. Its first git-to-Scion version was mostly hand-written as a prototype. Given an early internal build of Claude Mythos Preview (for its current status, see Claude Mythos 5 Returns for Critical Infra), the team asked for a full rewrite with no other guidance and got back a version that used 20x less memory and ran 4x faster.

Every engineer on the project now rates Claude as the stronger coder. Their own job shifted toward system-level design, trade-offs and frequently overruling Claude. Agents sometimes broke core constraints, especially during the migration: several systems tried to find when a change hit main by scanning the commit log line by line instead of asking the code review tool.

For operations, the team uses Claude Tag in Slack (Claude Tag: Anthropic's AI teammate for Slack). Each component gets its own channel and a Claude that watches only that component's health, which Anthropic calls a "superfan".

Can other teams use Scion?

Not in any practical sense: Anthropic says Scion is not a reasonable git replacement for general use. Its design only pays off for truly enormous monorepos worked on by tens of thousands of engineers or large swarms of agents. Anthropic also has far more budget for internal token use than a typical company would spend.

Where Scion fits, according to Anthropic

Question	Anthropic's answer
Who it suits	Huge monorepos with tens of thousands of engineers or many agents
Cost of adopting	Replacing review, code search and CI along with source control
Public release	Hard to package in a broadly useful form
What comes next	Share the ideas and work with GitHub, GitLab and the OSS community

Adopting it means replacing review, search and CI

Because Scion departs so far from git, an outside company would have to migrate its whole development lifecycle to use it. That includes its own code review, code search and CI, not just the version control layer.

Anthropic's internal versions of those pieces are heavily customized for its own setup. The company says a public edition that tries to suit everyone would probably not be very useful.

Anthropic wants git hosts to borrow the ideas

Anthropic expects this class of scaling problem to reach many more companies within the next 6 to 12 months. Rather than every git user hitting the wall alone, it wants to spread the parts of Scion that worked so teams can apply them without leaving the git model.

Its main suggestion is that a git server does not have to behave like a git client. Git platforms could offer server-side RPCs similar to Scion's, ideally standardized across forges so the git client can talk to them. Anthropic says it wants to partner with GitHub, GitLab and the open-source community on that.

Summary

AI-assisted coding pushed Anthropic past 30,000 merges a day, and a seven-person team answered by replacing git with Scion in five months, cutting the infrastructure's CPU and memory needs 200x. Scion keeps the work on the server and lets clients fetch only what they read, which turned minute-long checkouts into second-long ones.

For most teams this is not a reason to leave git. Anthropic itself says Scion is built for an unusual scale. The thing to watch over the 6 to 12 months it mentions is whether GitHub, GitLab and other git hosts start offering the server-side features Anthropic is asking for.