Anthropic Replaces Git With Scion as Merges Hit 30,000 a Day
Anthropic has replaced Git with a custom-built source control system called Scion, paired with a new code review system called Antique. The company detailed the project in an engineering post titled "Redesigning source control at Anthropic," published Oct. 13, 2026. Anthropic engineering post
Throughput forced the change. In May 2026 Anthropic averaged about 2,500 code changes merged per day. By September 2026 it merged over 30,000 per day. Anthropic stated that as merges per day grew more than tenfold, source control became its biggest development bottleneck.
Scale added strain. The history of its main branch alone is almost 100 GB. A compressed working copy is over 25 GB. At that weight, routine operations like clone, fetch, status and checkout stop acting like fast local file tasks and become expensive distributed systems problems.
CI, the automated testing that checks every change, made it worse. Anthropic performs on the order of 25 million code checkouts per day for CI, which fetched naively would be over 600 PB of Git traffic per day. Human developers can tolerate a slow clone. Fleets of short-lived CI workers cannot.
Seven people built the replacement. Migration from Git was completed in five months.
The broader context here is the clash between Git's design assumptions and machine-generated code velocity. Git assumes a relatively slow-moving directed acyclic graph, meaning an ordered history of human-written commits linked together, with full local copies on each machine. It optimizes for offline work and content-addressable integrity, meaning files verified by their contents. It does not optimize for tens of thousands of merges per day across a very large tree, with millions of automated checkouts demanding narrow, fast, partial views of state, like pulling one folder instead of the whole repository.
In my view, the pairing is the interesting choice. Scion and Antique separate but co-evolve version control and code review. Engineers who have lived through merge-queue contention, flaky rebase chains, and review tooling bolted onto a protocol never designed for it will recognize where Git-based workflows usually degrade first. Throughput is not only about storage or transfer. It is about contention on the main branch, deterministic ordering of merges, and keeping review latency flat while land rate climbs 12x in four months.
Looking at what this means for platform teams, the build decision is less contrarian than it appears. A seven-person team shipping a replacement in five months suggests narrow scope and tight control over client, server, and CI integration points. That is only possible when you own the entire development stack and can mandate client behavior. Most enterprises cannot. They run heterogeneous languages, build systems, IDEs, and compliance requirements that make Git compatibility non-negotiable, even when Git hurts.
Worth flagging for tool builders is the checkout figure. Twenty-five million checkouts per day reframes source control as a high-QPS read service, a system built to answer a huge number of quick read requests, not a file history tool. Fetch efficiency, virtualized working copies, and server-side filtering become core database problems. Inference latency, context window management, and agent-generated diffs will only push that read load higher as agents propose, test, and discard more revisions than humans ever would.
What this enables, if the approach holds, is development throughput decoupled from repository weight. The long arc of developer infrastructure has been toward removing local constraints, from remote builds to cloud workspaces to ephemeral test environments. Source control was overdue for the same treatment.
