What happened
On 13 October 2026, Anthropic published an engineering post explaining that it had moved its main code repository (its "monorepo") off Git and onto Scion, a version control system it built itself [1]. The whole migration took five months. Alongside Scion it also built a code review tool called Antique, code search, permissions for source control, and new ways to land large volumes of reviewed code.
The reason is simple to say: writing code stopped being the slow part. Claude now writes so much code that the tools built around human speed — source control, builds and CI — became the bottleneck. In Anthropic's words, those properties "that make git excellent for distributed, offline work were actively undermining our ability to scale" [3].
The numbers that broke Git
- May 2026: about 2,500 merged changes per day. September: over 30,000 per day.
- History of the main branch alone: almost 100 GB. A compressed working copy: over 25 GB.
- About 25 million checkouts per day just for CI — before developer machines, agent sandboxes and research jobs.
- Fetched naively, that would be over 600 PB of Git traffic per day; at peak they ran several hundred Git mirrors.
Independent coverage notes that the 30,000 figure is a peak day on Anthropic's chart, with the seven-day average still below 20,000 [2]. Even the average is roughly an 8x increase — far beyond what a hand-tuned Git setup was built for.
How Git is designed
Git was created in 2005 for Linux kernel development: thousands of humans, spread across the world, often offline. Its core idea is that every clone is a complete repository. You get every file and every commit in history. Commit, branch, merge, diff and log all run locally, without a server.
- Content-addressed objects: files, trees and commits are stored by hash, making history tamper-evident.
- Distributed: no copy is special; the "central" remote is just a convention.
- Offline-first: you can work for days on a plane and sync later.
- Client does the work: merges and history walks happen on your machine.
For humans this is brilliant. Big companies with giant monorepos (Google, Meta, Microsoft) already hit its limits years ago, which is why tools like partial clone, sparse checkout, VFS for Git and Meta's Sapling exist.
Why Git's strengths became weaknesses
| Git strength | Why it helps humans | Why it hurt at agent scale |
|---|---|---|
| Full history in every clone | Work anywhere, fast local log | 100 GB × millions of checkouts = massive bandwidth and storage |
| Offline-first | Planes, bad Wi-Fi | Agents and CI are always online anyway — the feature was unused cost |
| Client-side merge | No server load | Thousands of agents racing to merge into one branch, each with stale local state |
| Mirrors scale reads | Easy to replicate | Hundreds of mirrors to babysit, each lagging behind main |
One Scion engineer summed it up on Hacker News: since Claude is by far the heaviest user and "is necessarily online", offline support "just wasn't important to do" [4]. Once the main user is a machine in a data centre, the design priorities flip.
How Scion is designed
1. Always online, client-server
Scion assumes clients are connected. Commits, merges and history queries happen on the server; clients are lightweight and fetch data on demand [5]. Simon Willison compared it to a modern reinvention of centralized systems like Subversion.
2. API-first for agents
Agents can work with the repository through an API without cloning it at all. An agent that needs to change three files doesn't download 25 GB first.
3. No full copy anywhere
Reportedly, no complete repository copy exists anywhere in the architecture — not even on a single server. Data is spread out and assembled as needed.
4. Layered regional caches
Reads go through regional cache tiers, each with over a 99% hit rate. This is the same idea as a CDN: keep hot data near the reader so the origin barely gets touched.
Git vs Scion side by side
| Dimension | Git | Scion |
|---|---|---|
| Model | Distributed, peer copies | Centralized client-server |
| Connectivity | Offline-first | Always online |
| What a client holds | Full history + working tree | Only what it fetches on demand |
| Where merges run | On the client | On the server |
| Primary user | Humans | AI agents and CI (plus humans) |
| Interface | CLI over local files | API-first |
| Scaling reads | Clones and mirrors | Regional caches (99%+ hit rate) |
| Availability | Open source, everywhere | Internal to Anthropic only |
Built with the tool that caused it
The twist: the same AI that created the load helped build the fix. Seven engineers built and migrated to Scion in five months. One example from the post: Claude rewrote a prototype Git ingestion pipeline to run 4x faster using 20x less memory. Anthropic also leaned on adversarial review — having models look for flaws in each other's work — to keep quality high at that speed.
Lessons for system design
- Re-check your assumptions when the user changes. Git assumed humans and offline work. Agents broke both assumptions.
- The bottleneck moves. Speed up one stage (writing code) and the next one (merging, CI) becomes the limit — see Little's Law.
- Push work to where the data is. Server-side merges avoid shipping 100 GB to every worker.
- Caching beats replication. Several hundred mirrors were replaced by cache tiers with near-perfect hit rates.
- Don't copy this blindly. If your team merges a few hundred changes a day, Git (plus sparse checkout or partial clone) is still the answer. See how code flows to production.