Anthropic replaced git with its own source control for agents

Anthropic's engineering team explains why it stopped using git for its main monorepo and built a replacement called Scion. The pressure came from agents. Merges into the repo grew from about 2,500 code changes a day in May 2026 to more than 30,000 a day by September, and CI now performs roughly 25 million checkouts a day. With git, a naive fetch at that scale would mean over 600 petabytes of traffic daily, and the repo's history already runs close to 100 GB. The team had been patching around this with hundreds of internal git mirrors and blob-storage "seeds," but those kept drifting and getting harder to run.

The key observation is that git was designed for distributed clients that each keep a full offline copy, while Anthropic's clients are almost all always-online agents and jobs. So Scion flips the model: the server holds history, blame, commits, and merges, while clients keep only a small cache and fetch objects on demand. Commits happen on the server with no push, so their cost scales with the size of a change rather than the size of the repo, and checkouts can be sparse or skipped entirely through an API. Seven engineers built Scion and the surrounding tools and finished the migration in five months, while merge volume rose tenfold.

The results they report are concrete: each cache tier holds a hit rate above 99%, the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI gained 25% in capacity. One detail stands out. An early Claude model rewrote the git-to-Scion ingestion pipeline on its own and produced code that used 20 times less memory and ran 4 times faster than the hand-written prototype. Anthropic is clear that Scion is not a general git replacement and only makes sense for very large monorepos, but it wants to bring the ideas to GitHub, GitLab, and git itself.

Why it matters

If you run heavy agent workloads against a shared repo, the bottleneck Anthropic hit is coming for you too, and the usual mirror-and-cache patches have a ceiling. Their design points at what survives when most of your "developers" are online jobs: thin clients, server-side commits, and version control exposed as an API instead of a working copy on disk.