Anthropic Ditched Git: Scion, a Source Control System Built for the Agent Era
When daily merges went from 2,500 to over 30,000 in five months, git couldn't keep up. So Anthropic wrote its own source control system, Scion, for its monorepo. Seven people, five months and plenty of Claude. Here's a quick look at why git wasn't enough and what Scion does differently.

The number of merges into Anthropic's monorepo per day was around 2,500 in May 2026. By September it had passed 30,000.
Most of that code is now written by Claude. Once code generation got this fast, the bottleneck moved somewhere else. In Anthropic's words:
"The bottleneck is now the entire developer infrastructure built for human scale."
The first piece of that infrastructure to start cracking was git. So Anthropic went and wrote its own source control system for its monorepo. It's called Scion.
Why wasn't git enough?
The numbers speak for themselves:
- The main branch's history is about 100 GB, and a compressed working copy is over 25 GB.
- There are roughly 25 million CI checkouts a day. Pulling those with plain git would mean more than 600 petabytes of traffic per day.
They got by for a while with shallow clones, sparse checkouts, seeds and hundreds of git mirrors. But as the merge rate climbed, keeping those patches alive became a job in its own right.
The real problem, though, was more fundamental. Git was designed for people who can work offline and carry a full copy of the repository. At Anthropic, almost all the clients are agents and CI jobs that are always online. So the team asked: What would source control look like if we designed it for them from the ground up?
What does Scion do differently?
In short: all the heavy lifting moves to the server.
- 🌐 The client is always online: No copy of the repo is kept. Whatever file is needed gets fetched the moment it's needed.
- 🖥️ Commits happen on the server: Commit, merge, rebase and blame all run on the server. In other words, there's no such thing as a push.
- ⚡ Cheap commits: The cost of a commit depends on the size of the change, not the size of the repo.
- 🔌 Everything is an API: Lots of jobs run straight through the API without ever doing a checkout. The automated bisect and revert pipelines are built on this.
- 📂 Checkout is optional: If needed, only the files that are actually read land on disk.

The architecture has three layers:
- scion-server: The center. Data lives in Spanner and cloud storage.
- scion-cache: A cache in every region.
- scion-daemon: Runs on every machine. All jobs on the same machine share the same objects.
The hit rate at every cache layer is above 99%. There are no giant git-style "packfile" loads either. Every request is for a single immutable object, so an interrupted download can pick up right where it left off.
The results in numbers

The two numbers that caught my eye the most:
- It uses 200x less CPU and memory than the old git mirror infrastructure.
- Checkouts went from minutes to seconds.
The really interesting part: with Claude, for Claude
Scion, the code review tool Antique and the entire migration were done by a team of just seven people in five months. And during that time, daily merges grew more than 10x. A migration like this used to take years and big teams.
What made it possible, to a large extent, was Claude. For example, Claude rewrote the pipeline that moves data from git to Scion: 20x less memory, 4x faster.
The most honest sentence in the post, if you ask me, is this one:
"Much of the time, we found the engineers' job was to say 'no' to Claude."
Agents sometimes break the system's rules. For instance, instead of asking the code review tool, they'll scan the entire commit history from start to finish. The engineer's job is no longer to read every line one by one. It's to judge the intent of a change and to hit the brakes when needed.
So, will we get to use it too?
No, at least not for now. Scion is not open source and isn't offered as a product. According to Anthropic, the system has diverged a lot from git. Since it requires its own code review, search and CI, it's too specialized to be adapted for other companies.
Instead, they're sharing the design ideas and working with platforms like GitHub and GitLab. Their prediction is a bold one, too: this scaling problem will come knocking on other teams' doors within 6–12 months.
Don't mix up the names: Google also has an open-source agent orchestration tool called Scion. The Scion in this post is Anthropic's internal source control system. They're two different projects.
My takeaway
For years we thought "the developer is the bottleneck." Writing code was slow, and everything else could wait. Now that agents write the code, it's the turn of the infrastructure carrying them: git, CI, merge queues, code review.
Today it looks like Anthropic's problem, but tomorrow it'll be everyone's. And it seems the next big shift won't happen in the models, but in the tools around them.
🔗 Original post: Redesigning source control at Anthropic
What was the first thing to crack on your team because of agents: CI, code review, or git? Let's talk in the comments. Happy coding!
Muhammed Emin Özdemir
Senior full-stack developer at VakıfBank. Focused on enterprise systems, clean code and LLM-based tools.
More about me →
Comments
Be the first to comment