Anthropic Replaced Git With Scion. The Interesting Part Is What Happens When a Bad Merge Lands First and Tests Run After.

In May 2026, Anthropic’s engineers were merging about 2,500 changes a day into their main repository. By September, that number was 30,000 — a 12x jump in four months. Git, run the normal way, was not built for that. So a seven-person team spent five months building a replacement called Scion, and on October 13 Anthropic published a long post explaining why and how. The throughput numbers are genuinely striking. The part the post doesn’t talk about — what happens when a merge is wrong — is the part a tech lead should actually worry about.

The problem wasn’t Git being slow. It was Git’s core assumption.

Anthropic’s own framing of the root cause is specific: “Git assumes that clients work offline and need a complete copy of the repository. Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable.” That’s the whole thesis in one sentence. Git was designed in 2005 for humans who commit on laptops and sometimes lose network access. Anthropic’s actual clients in 2026 are Claude instances and CI jobs running inside a data center with guaranteed connectivity, cloning and syncing constantly, never going offline. Offline support is a tax every one of those clients pays for a scenario that never happens to them.

The scale makes the mismatch concrete. Main branch history sits around 100 GB; a compressed working copy is over 25 GB. CI alone was doing roughly 25 million checkouts a day — naively over Git, that’s 600+ petabytes of daily traffic. At peak, Anthropic was running several hundred internal Git mirrors just to keep up. That’s not a performance tuning problem. That’s an architecture that has hit its design ceiling.

What Scion actually is

Scion is not a faster Git. It’s a different model entirely, closer in spirit to Google’s internal Piper or Meta’s Sapling/Mononoke than to anything distributed. The core unit isn’t a commit object — it’s a “changeset,” created server-side and available everywhere the instant it exists, storing file changes relative to its first parent with content-addressed pointers into blob storage. There are no packfiles and no repository maintenance, because no client ever holds a full copy to maintain.

The read path is a three-tier cache: a node-level scion-daemon, a regional in-memory scion-cache, and the authoritative scion-server backed by Spanner and blob storage. All three answer identical RPCs, so a client never needs to know or care which tier actually served the request — it just asks, and something upstream has the answer, with a cache hit rate above 99% at every tier. Even refs are lightweight: just a compare-and-swap on a single Spanner row, since nothing in the system depends on a local ref cache to find or create data.

The results Anthropic reports: CI checkouts went from minutes to seconds — “two orders of magnitude faster” — freeing up roughly 25% of CI’s CPU capacity. The new infrastructure uses roughly 200x less CPU and memory than the old Git-mirroring setup it replaced. And in a detail that says something about where this is all heading, Claude itself (internally nicknamed “Mythos”) rewrote the Git-to-Scion ingestion pipeline to use 20x less memory and run 4x faster than the version humans had originally written.

The merge queue is gone, on purpose

This is the design decision that should get a tech lead’s full attention. Anthropic didn’t just make merging faster — they removed the gate. Their own explanation: “A proper merge queue doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running?” And elsewhere: “Claude can typically fix these conflicts faster than humans can even identify them.”

In plain terms: changes merge to main first, and testing happens after, not before. That’s a real, defensible trade at 30,000 merges a day — a traditional serialized merge queue would be a throughput wall long before you got there. But it inverts a safety property that most engineering orgs treat as non-negotiable: main is supposed to be the branch you can always build from. Anthropic’s post never shows what happens when a post-merge test run catches something bad. How many bad merges land on main between merge and test completion, at that volume? How do they get identified, bisected, and unwound? Is there an automated revert path, or does a human have to notice? The line about Claude fixing conflicts faster than humans can identify them is about textual merge conflicts — two changes touching the same lines. It says nothing about a merge that’s textually clean but introduces a logic regression, which is the failure mode that actually matters once you remove pre-merge gating.

What Anthropic is honest about — and what’s just absent

Credit where it’s due: Anthropic is unusually direct about the limits of their own announcement. Their own words: “Scion is by no means a suitable replacement for git for general use.” And: “it’s difficult to offer Scion in a form that would be broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle” — code review, code search, CI, identity and access management, all built bespoke around Scion and non-portable. There’s no public code and no plan to open-source it. Anthropic also flags that their own token-spending economics as an AI company are not representative of any other organization’s situation, which undercuts the temptation to read this as a general blueprint.

What’s simply missing, rather than caveated, is any Git-compatibility story: whether any team internally still works in Git day to day, whether external collaborators or open-source dependencies can interoperate with a Scion repository at all, and what a rollback looks like in practice. None of that is addressed as solved or explicitly ruled out — it’s just not in the post.

Scion fits a pattern other companies have already walked: Google moved off Perforce to Piper, Meta moved off Mercurial to Sapling, both for similar reasons at similar scale. Anthropic joining that list is a genuine signal that client-server, always-connected version control is the right shape once your main client population is machines, not humans with laptops. But if your organization is nowhere near 30,000 merges a day, the actionable lesson isn’t “build your own VCS.” It’s narrower: as agentic coding volume grows, look at where your CI and version control assumes a human cadence — nightly builds, serialized merge queues, local developer checkouts — and start asking which of those assumptions breaks first. For most teams, that will show up as CI capacity and merge-queue throughput long before it shows up as a reason to replace Git itself.