Anthropic replaced git with Scion. What it means for you

Anthropic replaced git with an in-house version control system called Scion after agent-written code pushed its monorepo from 2,500 merges a day in May 2026 to more than 30,000 in September. Seven engineers built it in five months. The takeaway for everyone else is not "build your own git" — it is that agent-written code breaks your delivery pipeline long before it breaks your product, and the pipeline is where most teams have invested the least.

What Scion is, and what it is not

Scion is a server-centric source control system built for a single monorepo at Anthropic. It inverts git's founding assumption. Git is offline-first and gives every client a complete copy of history; Scion assumes clients are always online, because most of its clients are CI jobs and coding agents, not laptops on airplanes.

The design choices, from Anthropic's engineering write-up:

• Server-authoritative history. Blame, path history, merges, and commits are answered by the server instead of being reconstructed from a local clone.
• API-first. Every source control query is exposed over an API, so tools never maintain a local repository at all.
• Sparse, virtualized checkouts. Clients fetch only the directories they ask for; files materialize on demand.
• Three cache tiers. A node-level daemon, a regional cache, and authoritative servers — each holding a cache hit rate above 99%.
• No merge queue. Changes land concurrently and conflicts are resolved after the fact.

What Scion is not: available to you. Anthropic says plainly that it "is by no means a suitable replacement for git for general use," and it will not be open-sourced. Their recommendation to the ecosystem is narrower and far more useful: git servers don't have to work like git clients. Forges can add server-side RPCs and better server architecture without asking anyone to abandon git.

The numbers that forced the rewrite

Shallow clones, sparse checkouts, and seed snapshots all helped, and all ran out. At peak, Anthropic was running several hundred internal git mirrors just to serve clones. The repository didn't get pathological because the product got complicated — it got pathological because the rate of change multiplied by twelve in four months.

The real bottleneck is review, CI, and merge

The most important line in the write-up isn't about storage. It's this: "A proper merge queue... doesn't make much sense at agent scale. What does CI even mean when hundreds or thousands of changes can merge while tests are running?"

That question has nothing to do with git, and everything to do with your pipeline. A merge queue is a global lock. It serializes integration so that every commit is tested against the exact state it will land on. That is a good trade when you merge 20 changes a day. At 200 it becomes the critical path, and at 2,000 it is simply impossible — the queue's throughput ceiling is your engineering throughput ceiling, no matter how fast your agents write code.

Anthropic's answer was to stop serializing: changes land concurrently, testing moves after the merge, and conflicts are repaired automatically. In their words, "concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them."

You do not have to agree with that trade-off. You do have to know where your own ceiling is, because agents will find it.

What to do if you are not Anthropic

You almost certainly should not build a version control system. You should do the unglamorous work that buys you the same headroom:

1. Instrument throughput, not output. Track merges per day, queue wait time, time from green CI to production, and revert rate. Lines of code written by an agent is a vanity metric; merged and surviving changes are the real one.
2. Find your global locks. A merge queue, a single staging environment, a manual release approval, one person who reviews everything. Each one is a serialization point that caps throughput regardless of how much code gets generated upstream.
3. Make CI selective and cached. Test impact analysis, remote build caching, and sparse checkouts are standard tooling now. The 25% CPU Anthropic reclaimed came from not doing redundant work, not from buying more machines.
4. Buy down the cost of being wrong. Fast, boring reverts, feature flags, and progressive rollouts matter more than pre-merge certainty once merge volume climbs. If a bad change is cheap to undo, you can afford to merge optimistically.
5. Spend human review on blast radius. Auth boundaries, data migrations, payment paths, anything touching customer data. Formatting, naming, and mechanical refactors are exactly what machines and linters should own.

That is the work we do when we take AI-built software to production: find the serialization points, harden the paths that can actually hurt you, and make the pipeline survive the volume. You can see how we scope it on our work.

The role that did not get automated

The part of Anthropic's post that deserves the most attention has nothing to do with source control. Every engineer on the Scion team would now rate Claude as better at writing code than them. Yet the humans still supplied the "understanding of high-level inter-system components and design-level tradeoffs," and their primary function, as the post puts it, became telling Claude "no" when a constraint was violated.

Note also what that team did not skip. On a five-month timeline, with seven people, they built hermetic simulations of every non-trivial source control and infrastructure interaction, plus fuzzing and sophisticated rate limiting. Speed came from testing rigor, not from skipping it. That is the opposite of how most AI-accelerated projects behave, and it is the whole reason this one landed.

Generation is abundant now; judgment is scarce — the same reallocation we mapped in who ships to production when prototyping is free, now visible in infrastructure. The scarce skill is knowing which constraint matters and being willing to enforce it — which is why we build products by building people rather than renting hours.

Git is also only the first settled idea to hit its expiry date in public. We took the wider version of that argument — what else we still treat as a law that has quietly become a preference — in settled ideas have expiry dates.

Key takeaways

• Anthropic built Scion, a server-centric replacement for git, because agent-generated code drove its monorepo from 2,500 to 30,000+ merges per day between May and September 2026.
• Scion is not open source and is not meant for general use; the portable idea is that git servers don't have to work like git clients.
• Version control was the symptom. The structural problem is that merge queues, CI, and human review are serialization points that cap throughput at agent scale.
• Anthropic expects teams at much smaller scale to hit these limits within six to twelve months.
• The highest-leverage human work on the project was design judgment and saying "no" — not writing code.

FAQ

What is Scion?

Scion is Anthropic's internal version control system, built to replace git in its main monorepo. It is server-centric: history, blame, and merges are served by an always-reachable API rather than reconstructed from a full local clone, and checkouts are sparse and virtualized.

Is Scion open source or available to use?

No. Anthropic stated it will not open-source Scion and that it "is by no means a suitable replacement for git for general use." Adopting it would require migrating an entire development lifecycle. Their suggestion is for git forges to adopt compatible server-side improvements instead.

Why did git stop working at Anthropic?

Volume, not complexity. Roughly 100 GB of main-branch history, a working copy over 25 GB, and about 25 million CI checkouts a day. Serving that naively would have meant more than 600 petabytes of daily traffic, and at peak Anthropic ran several hundred internal git mirrors to keep up.

Should my team replace git?

Almost certainly not. Below Anthropic's scale, the wins are in selective CI, build caching, sparse checkouts, smaller changes, and removing serialization points like a single global merge queue. Replacing version control is the last resort, not the first move.

What breaks first when agents write most of your code?

The merge queue and CI capacity, followed by human review bandwidth. All three are serialized processes sitting downstream of a generation step that just got much faster.

How much time do teams have?

Anthropic expects these scaling problems to become widespread within six to twelve months. The cheap preparation is measurement: know your current merges per day, queue wait, and revert rate before the volume arrives.