In May 2026 Anthropic merged about 2,500 changes a day into its monorepo; by September it was over 30,000. According to their engineering post of 13 October 2026, source control became the biggest bottleneck, and they answered with Scion, an in-house system they migrated to from git in five months. It is an extreme case, but it shows what breaks first when your clients stop being people.
What changes
Their diagnosis: they were running git as a centralized system (one authoritative copy) while nearly all clients are agents and CI jobs that are online by definition. The properties that make git great for distributed, offline work became a drag. Their numbers: main-branch history is around 100 GB, a compressed working copy exceeds 25 GB, and CI alone performs on the order of 25 million checkouts a day. At peak they ran several hundred internal git mirrors.
Scion's principles, per the post:
- Clients are always online. The server answers history, blame, commits, merges and rebases; the client keeps a bounded object cache and lays out files on disk.
- Cheap, lock-free commits. Every commit, rebase or merge happens server-side. The unit is the changeset, a write-ahead-log entry with the changed file list and content-addressed pointers. No packfiles, and no refs to move per commit; moving a ref is a compare-and-swap on a single Spanner row.
- Optional, sparse working copy. A CI job that needs the diff against the merge base asks the server over an API, no clone required. When files are needed, the protocol is built around sparse or virtualized checkouts.
- Derived data. Blame, path history and commit-graph skip lists are computed by one generic recursive mechanism over a changeset's parents, eagerly or lazily.
Checkouts go through three cache tiers (scion-daemon on the node, regional scion-cache, authoritative scion-server on Spanner and cloud storage). Since everything is immutable and content-addressed, any tier can cache without coordination, and each tier holds a hit rate above 99%.
Reported results: Scion's infrastructure is 200x smaller (CPU and memory) than the git mirror fleet, CI and research checkouts are two orders of magnitude faster (seconds instead of minutes), and CI alone gained 25% CPU capacity.
Why it matters in production
Almost nobody merges 30,000 times a day, and the post says as much. The useful part is the pattern: once agents and jobs consume the repository, cost is dominated by checkouts and history queries, not by a person's git push. If you already maintain mirrors, seeds in blob storage, or partial clones with slow blame, you are on the same trajectory at a smaller scale.
There are process lessons too. A team of seven built Scion and the Antique review tool while code volume grew tenfold. The team says their job was often telling Claude "no": several systems tried to find when a change landed by reading the commit log linearly instead of asking the review tool, and adversarial reviews pushed toward over-defensive engineering. They still review every change request, but for intent rather than line by line.
A caveat from me: this is Anthropic's own account of an internal system, with no public code or reproducible benchmarks. You cannot adopt Scion; you can reason from it.
What I would do
- Measure how many full checkouts your CI does per day and how long each takes. That is your baseline.
- Move jobs that only need a subtree to shallow or sparse clones (
--filter=blob:none, sparse checkout). - Replace clones with forge API calls when a job only asks for a diff, a merge base or an author.
- Find tools that answer history questions by scanning the full log and move them to an index.
- Give each critical dev-platform component a dedicated agent or alert, like the "superfans" they describe.
Sources
- Redesigning source control at Anthropic, Anthropic Engineering, 13 October 2026.
- Simon Willison's commentary, 13 October 2026.