Anthropic Moved Its Monorepo to Scion. You Shouldn't.

On October 13, Anthropic published Redesigning source control at Anthropic, about Scion, an in-house version control system. They say they “fully migrated our monorepo from git in five months.” The post doesn’t say every repository at Anthropic left git. One disclosure before the opinion: I use Claude Code every day, so I’m an Anthropic customer.

You should not copy this, and Anthropic says Scion is “by no means a suitable replacement for git for general use.”

Is Scion open source?

No. Scion is internal to Anthropic. The post says it would be “difficult to offer Scion in a form that would be broadly useful to other organizations.” What they share instead is the design. They suggest applying the most successful parts of Scion to git itself and say they want to partner with GitHub, GitLab and the open source community. Anthropic hasn’t released Scion, so there is nothing from them to install.

Be careful with the Scion clones

That gap is already filling. Within two days of the post, at least two public reimplementations showed up on GitHub. CarterT27/scion was created on October 14 and calls itself an “Implementation of Anthropic’s version control system.” Its README says it “is not Anthropic’s implementation and is not affiliated with Anthropic.” tinyhumansai/openscion was created on October 13, is GPL-3.0, and describes itself as “Based on Anthropic’s Scion.”

I’d keep both at arm’s length for real work. Both are builds inferred from a blog post. The post describes a design and leaves out the internals that took a team five months to get right. Your source control holds the full history of everything you’ve built, so it is the last place I’d run a project that is a few days old. If something in the merge or storage path is wrong, you find out when history is already damaged. Read the license before either one touches a commercial codebase, and treat installing a fresh package from a fresh repo as a supply chain decision.

If the design interests you, read the clones the way you’d read the original post. Don’t move your repo onto one.

What problem they actually have

Here are the numbers from the post. In May 2026, Anthropic averaged around 2,500 code changes merged per day. By September it was over 30,000 per day. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. CI does on the order of 25 million checkouts a day.

They estimate that fetching all of that naively would be over 600 PB of git traffic per day. That’s their estimate for a naive setup, not traffic they served. What they actually ran, at peak, was several hundred git mirrors to handle the load.

The part I found most interesting is the design reason. Git assumes clients that are offline some of the time. Anthropic says nearly all of its clients are agents and jobs that are online by definition. So Scion keeps an always-reachable server, hands out virtualized checkouts that materialize files on demand, and has the server do blame, history, commits, merges and rebases. They report an infrastructure footprint 200x smaller than the mirroring setup, checkouts in seconds instead of minutes, and a 25% CPU capacity win in CI.

A team of seven people built Scion and Antique, their code review tool, and the whole effort, building and migrating, took five months. They name Google’s Piper and Meta’s Sapling as prior art.

What they say about everyone else

The authors are plain about who this is for. The concepts “really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code.” They also write that it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Their answer for everyone else is to bring the ideas into git, not to leave it.

The six-to-12-month forecast

Anthropic does expect this to spread. They write that they “don’t expect many organizations to have these problems in the very near term,” but suspect “it won’t be too long” before others using AI coding tools hit the same pressure points. They expect this class of problems to “become more commonplace over the next six to 12 months.”

I think that is true in kind. Agents raise the volume of changes, and tooling that was built around humans typing does creak.

The difference is scale. I made 4,154 commits to a single repo in about the first six months of 2026, almost entirely agent-driven, and the project went from zero to production in sixty days. That’s about 23 commits a day on plain git and GitHub. Commits aren’t merges, so this is rough. Anthropic was merging about 2,500 changes a day in May, before the tenfold jump, which is around 100 times my rate. Merge count was also only part of their problem. The rest was a 100 GB history and 25 million CI checkouts a day.

At 23 a day my bottleneck was review. Reading what the agents wrote and deciding whether it was right took far more of my time than any clone, fetch or push. More and more of that review is now done or assisted by AI.

For a team of a few people and a handful of agents, that forecast describes a future you may or may not reach. Swapping your source control to get ahead of it is the part I’d skip. Anthropic doesn’t recommend it either.

What copying costs a small team

When a big company publishes how it solved a problem, smaller teams tend to read it as a to-do list. Anthropic built a server that does merges and rebases because several hundred git mirrors couldn’t keep up with its load. If you aren’t running mirrors, you don’t have that problem.

The cost of copying is mostly attention. A migration, even to a boring tool, eats weeks of a small team’s focus and leaves a new thing to maintain. Anthropic had seven people on it for five months. When your whole engineering team is four people, how you spend their time matters more than any tool choice, and you can’t spare weeks of it.

That’s why I watch the signal-to-noise ratio on a small team so closely. I’d rather spend an hour on what the agents shipped this week, and whether anyone checked it, than on a meeting about following Anthropic off git.

Where I’d spend that attention

None of this involves leaving git. Start with review that keeps up with agent output. If agents write the diffs, the human job is review. Anthropic’s team still reviews “every change request,” though they now “examine the intent of the change as opposed to reading every line of code.” What that looks like for me is in the 4,154 commits post: adversarial review agents first, then a human pass on the lines where the business context is subtle.

Then check the prose around the code. Teams build gates for the diff and let the pull request description through unchecked. I wrote about that in We Gated the Code and Left the Prose Wide Open. A wrong description frames how the reviewer reads the diff, so it is worth a cheap check.

And keep enough people to absorb the output. More agent throughput means more to review and decide on. I argued in AI Won’t Shrink Your Team that this is where the real cost shows up.

What I’d watch for instead

If you hit a real wall, such as clones taking minutes or CI spending more time fetching than testing, then you have a problem worth solving. The first move is to check whether git, GitHub or GitLab already ships the fix. Anthropic published the design so others can apply the parts that work to git, and says it wants to partner with GitHub and GitLab. Some of the fix may come to you without a migration.

Until you can point at that wall with a stopwatch, put your time into what your agents ship and how you review it. If you want a second pair of eyes on your own agent and review setup, that’s the kind of thing I do on my consulting page.