Anthropic went from 2,500 to 30,000 merged changes a day. Git's assumptions broke before Git did
Anthropic replaced Git internally with Scion after coding agents multiplied its merge rate. Most companies will never need Scion; the assumptions it dropped are worth checking anyway.
Listen to this article · 5 min
AI-generated narration of the full article.
In May 2026, about 2,500 changes a day merged into Anthropic’s main repository. By September, more than 30,000 did. The history of main was approaching 100 GB, a compressed working copy exceeded 25 GB, and CI ran about 25 million checkouts a day, not counting developer environments, agent sandboxes and research jobs. Fetched the ordinary way, Anthropic estimates that load would have exceeded 600 PB of Git traffic per day.
Anthropic’s engineering post, published on October 13, describes what it did next: it moved its monorepo off Git to an internal system called Scion, built by a team of seven in about five months, alongside a code review tool called Antique. The post is unusually candid about the limits of its own lesson. Anthropic says its use of Claude for coding, and its internal token spending, are far beyond typical business budgets, and that Scion is not a general Git replacement. Its advice to everyone else is to bring the useful ideas to Git.
That advice is the reason to read it. The interesting part is not that Git broke. It is which of Git’s assumptions stopped being true.
| Built for people | At agent scale, per Anthropic | |
|---|---|---|
| Clients | Developers who sometimes work offline with a full copy | Almost every client is an always-online agent or job |
| Commits | Made locally, then pushed | Made on the server; nothing to push |
| Checkouts | The whole working tree | Only the files a job reads, or no checkout at all |
| Merge order | A queue that serializes merges | Post-merge and pre-deploy testing; a global lock is impractical |
| Review | A person reads every line | Semantic approval rules separate trivial changes from sensitive ones |
Decentralization stopped paying
Git was designed so that every developer holds the full history and can work disconnected. At Anthropic, nearly every client was an agent or a CI job that is always online and needs a few directories. Carrying full history to each of them was pure cost. Scion’s client fetches content on demand from a server, keeps a bounded cache, and lets many jobs skip a checkout entirely by querying source control through APIs. Anthropic reports checkouts about two orders of magnitude faster, from minutes to seconds, a gain of about 25% in CI CPU capacity, and a footprint about 200 times smaller than its previous Git mirror infrastructure.
Most enterprises will not hit these volumes. Many will hit the smaller version: agent sandboxes and CI runners that each clone a large repository, mirrors that lag behind main, and build minutes that grow faster than the team. Sparse checkouts, shallow clones and server-side operations already exist in Git, and they are the first things to try.
The bottleneck moves to review and merge
The more transferable lessons are in the last two rows. At tens of thousands of merges a day, a merge queue that serializes changes cannot keep up, so Anthropic relies on post-merge and pre-deploy testing, and says Claude usually resolves conflicts between concurrent merges faster than people notice them. And review changes shape: Antique supports semantic approval rules, so a comment-only change is not treated like a sensitive one, and reviewers focus on the intent of a change instead of reading every line.
For an enterprise, both are governance decisions disguised as tooling. Moving tests after the merge means accepting that main can be briefly broken and investing in fast detection and rollback. Letting rules decide which changes need a human means writing down, in advance, which paths and change types are sensitive. That is the same exercise we recommended for treating agents as authors of production changes: change classes, with the approval each one needs, decided before the volume arrives.
Where to look before volume arrives
Agent output does not need to grow twelvefold to stress your delivery system. A team that doubles its pull requests with coding agents will find the limit first in the reviewers, then in CI capacity, then in the merge queue, and only much later in source control itself. Google’s overnight agent run made the same point at small scale: of six proposed changes, engineers kept two, and the review was the work.
Three numbers are worth tracking monthly as coding agents spread: merged changes per day, median time a change waits for review, and CI minutes per merged change. When the first grows and the other two grow faster, your Git is fine. Your process is what has reached Anthropic’s problem, just earlier on the curve.