Anthropic left git. The reason is the part worth keeping.

Anthropic has stopped using git for its main repository. The new system is called Scion, seven people built it in five months, and the write-up is clear that you almost certainly do not need it.

Read it anyway. Not for the tool, but for what forced it: the moment code got cheap to write, every system downstream of writing became the bottleneck, and source control was the first one to break.

What actually happened at Anthropic

The numbers are the argument, so here they are as published. Merges into the monorepo went from about 2,500 a day in May 2026 to over 30,000 a day by September. The main branch carries almost 100 GB of history; a compressed working copy is over 25 GB. CI checks the repository out around 25 million times a day, before counting developer machines, agent sandboxes and research jobs. Fetched naively, that would be more than 600 PB of git traffic a day.

Most of those clients are not people. They are agents and jobs, always online, each one wanting a fresh copy of a repository that changes every few seconds.

The team tried what everybody tries first: shallow clones, sparse checkouts, promisor remotes, internal mirrors (several hundred at the peak) and pre-built seeds in blob storage. Each helped for a while. The seeds drifted further behind main between refreshes, and the mirrors got harder to run with every rise in merge rate.

Why git broke and not something else

Git is decentralised by design. Every clone is a complete repository, which is exactly right for most projects and exactly wrong for this one. The observation in the write-up that does the most work is a modest one: they were already using git as a centralised system. Nearly every client was online all the time and talked to one server. They were paying for the decentralisation and using none of it.

So Scion inverts the arrangement. The server owns history, blame, commits, merges and rebases. The client keeps a bounded cache and fetches trees and blobs on demand. A commit is created on the server and exists immediately, so there is nothing to push. Many jobs never check anything out at all and ask the server for a diff over an API. No full copy of the repository exists anywhere, not even on the server.

The results they report: checkouts in seconds instead of minutes, a footprint 200 times smaller than the mirror fleet it replaced, and 25 percent of CI’s CPU capacity freed. Those are a vendor’s numbers about its own system, compared against infrastructure the same team had outgrown. The direction is not in doubt; the multipliers are theirs.

Is git too slow for AI agents?

Not at any size most teams will reach. DriveFlow, our platform for Swiss driving schools, has 515 commits on main and packs to under 9 MB. In the last month two of us pushed 124 commits to it, 38 of them on a single day, adding around 27,500 lines. That is a busy month by our standards, and a full clone is still over before you have switched windows. Nothing Scion solves exists there.

The authors are explicit about it themselves: Scion suits very large monorepos, on the scale of tens of thousands of engineers or swarms of agents, and adopting it means migrating code review, search and CI along with it, because every tool around it at Anthropic is bespoke. They also note that their internal token spend is unusually high, which is a polite way of saying few companies run agents at this density.

What they predict is that the same pressure reaches everybody else within six to twelve months. That is plausible in direction and impossible to check in timing. What it means in practice is that the cheap features git already has are worth turning on before you need them.

What a small team can use in git today

Each of Scion’s principles has a weaker version that git, GitHub and GitLab already ship. None of them is free.

The one Scion idea a small team should not copy is dropping the merge queue. Anthropic replaced a globally locked queue with post-merge and pre-deploy testing, because a lock does not survive 30,000 merges a day, and conflicts are usually fixed by Claude before a human would notice them. At ten merges a day a merge queue costs you nothing and catches the change that passes on its branch and breaks on main. Keep it.

We learned the small version of this on DriveFlow in September. CI is the only way it deploys, and the verify job cancelled any run that a newer push had overtaken, on main as well as on pull requests. The deploy job depends on verify, so a cancelled run did not delay its deploy, it skipped it. With one person pushing, that never came up. With two, the day after a 38-commit day, four of the last five pushes to main had shipped nothing, and nothing had gone red: a cancelled run and a skipped job do not look like failures. The fix was a few lines in the workflow: cancel overtaken runs on pull requests only, and let pushes to main queue. That is a merge queue in its smallest form, and it was what was missing, not a faster checkout.

The part that transfers at any size

The most useful section of the write-up is not about storage. It is about what the seven engineers did all day.

They did not write most of the code. A Claude model rewrote the hand-written git-to-Scion ingestion pipeline with no further instructions and came out 20 times leaner on memory and four times faster, keeping the ordering invariants intact. What the engineers kept was the design trade-offs, and saying no. Agents brute-forced reads of the commit log. They added validation nobody needed. Adversarial review sometimes turned myopic. The team now reviews intent rather than every line.

Two mechanisms make that safe rather than just fast. Scion supports per-directory permissions, and the review tool can express semantic approval rules: a change that only touches comments does not need the sign-off a change to authorisation logic does. And they built hermetic simulations and fuzzing, with Claude’s help, so that “reviewed for intent” sits on top of something that actually ran.

That is the same distinction that runs through what we check before a real business uses something we built: a green light only counts if you know what produced it.

What to do with this

Measure where your time goes between “the change is written” and “the change is live”. If writing is still the longest step, nothing here applies yet. If the CI checkout, the review or the wait for main has become the long step, turn on the git features in the table above before reaching for anything else, and spend the time you get back on the review, which is the one step no tool has made cheaper.

And if you are deciding how to bring agents into a team’s workflow at all, that is the question we start with in product development: not how fast the code arrives, but what the team does with it once it has.