Anthropic Dropped Git for 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.” To be exact about my headline: it was their monorepo that moved, and 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.” It’s a good read, and a dangerous one for a small team.

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 figure is their hypothetical estimate, and it explains why at peak they were running several hundred git mirrors just to keep up.

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, which tells you what company this is joining.

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

They do make a forward-looking claim, and it is the strongest argument against my take. They say others who use AI coding tools will “experience these same pressure points,” and they put a window on it: 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.

Scale is where I part ways. 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 roughly 23 commits a day on plain git and GitHub. Commits and merges are not the same unit, so treat any comparison as order of magnitude only. With that caveat, Anthropic was at about 2,500 merges a day in May, before the tenfold jump, which is roughly 100 times my rate. Even at ten times my output, I’d be about a tenth of where they were in May. And their pain came as much from a 100 GB history and 25 million CI checkouts a day as from merge count.

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.

So when the forecast reaches a team of a few people and a handful of agents, it is about a future you may or may not reach. The takeaway I keep seeing, that you should get ahead of it by swapping your source control, is where I get off. Anthropic doesn’t say that either.

Signal to noise on a small team

A large company publishes how it solved its problem, and smaller companies read it as a to-do list. The tool is the output of a pain you haven’t had. Anthropic needed a server that does merges and rebases because the mirrors strained under its load. You don’t have the mirrors, so you don’t have the pain.

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 is why I care about signal to noise more than almost anything else on a small team. A meeting about whether to follow Anthropic off git is noise. The signal is in your own repo: what your agents shipped this week and whether anyone checked it.

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 reading them. Anthropic says the same about its own team: they “still review every change request,” and 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 says it wants to apply these ideas to git, so waiting may cost you nothing.

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.