Anthropic Replaced Git for Its Monorepo. The Reason Matters More Than Scion.

Anthropic just published how it moved its main repository off git and onto an in-house system called Scion. The headlines say "Anthropic replaces git." The post says something narrower and more useful: git did exactly what it was designed to do, and that design stopped matching how the code was being used.

This article follows the post: what broke, what Scion changes, and what a team that is not Anthropic can take from it.

How to read it: every claim about Scion comes from Anthropic's engineering post "Redesigning source control at Anthropic", published October 13, 2026, which I read on October 14. I have not used Scion and have no inside knowledge. The arithmetic sections are mine and are labeled. Where the post was silent, I say so.

The numbers behind it

The post gives these figures for Anthropic's monorepo:

• Merges went from around 2,500 code changes per day in May 2026 to over 30,000 per day in September.
• The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB.
• CI performs on the order of 25 million code checkouts per day, before developer environments, agent sandboxes and research jobs.
• Fetched naively, that would be over 600 PB of git traffic per day.

The post's first line says that as merges per day grew more than tenfold, source control became the biggest development bottleneck.

My arithmetic on those figures: 30,000 merges a day is about one every 2.9 seconds, around the clock. 25 million checkouts a day is about 290 per second. And 600 PB divided by 25 million is about 24 GB per checkout, which lines up with the 25 GB working copy. So the 600 PB figure is just "every checkout downloads the whole repo."

Why git broke

The post's core diagnosis is a mismatch. Git is built for distributed, offline work: every machine holds the history and can work alone. Anthropic was using it as a centralized system with one authoritative copy, whose clients are nearly always online agents and jobs. The post says the properties that make git excellent for distributed, offline work were actively undermining that use.

The team had piled up the standard workarounds: shallow clones, sparse checkouts, promisor remotes, internal git mirrors and blob-storage seeds. At its peak Anthropic ran several hundred internal git mirrors. Three things gave out:

• Seeds drifted further from the tip of main between refreshes.
• Diff and blame on partial clones got harder to keep working as the merge rate rose.
• Mirrors stopped scaling once the repo outgrew their disks or memory, and became harder to operate as the merge rate increased.

None of this means git is slow. It means a design for a thousand offline laptops met thirty thousand merges a day from machines that are always connected.

What Scion does differently

The post lists six design principles:

1. Clients are always online. A client talks to a reachable server and fetches data when it needs it.
2. Client-server asymmetry. The server handles history, blame, commits, merges and rebases. The client keeps a bounded local cache and lays out the working copy.
3. Source control as a service. Queries are exposed through an API, so many jobs need no local repository. Automated bisect and revert pipelines depend on this.
4. Horizontal scalability. No full copy of the repo exists anywhere, even on the server, and there are no packfiles or repo maintenance.
5. Cheap, lock-free commits. Commits, rebases and merges happen on the server, so there is nothing to push. Refs are discouraged except for main and release branches.
6. Optional, sparse working copies. CI can ask the server for diffs, and many writes skip checkout entirely.

The data model is a changeset, an entry in a write-ahead log, created on the server. It lists changed files relative to its first parent, with content-addressed pointers to compressed blobs. Refs are a compare-and-swap on a single Spanner row. Blame, path history and commit-graph skip lists are derived data, computed from parent values, so the internals can change without client changes.

A small fleet of servers answers all the APIs. Because everything is content-addressed, any server can cache it without coordination. The client fetches only the trees and blobs it wants, starting at a root tree and recursing, so there is no multi-gigabyte packfile and transfers are resumable.

Delivery is tiered: a scion-daemon on each node, a regional scion-cache, and the authoritative scion-server that reads from Spanner or cloud storage on a miss. The post says tiering is strictly enforced so a failing regional cache cannot overwhelm upstream servers.

What Anthropic reports

All figures below are the post's own claims, not independent measurements:

• The Scion infrastructure footprint is 200x smaller than the previous git mirroring infrastructure, in CPU and memory.
• CI and research jobs check out code two orders of magnitude faster, in seconds rather than minutes.
• CI alone realized a 25% CPU capacity win.
• Each tier keeps a cache hit rate of over 99%.
• A team of seven people built Scion and the code review tool Antique and migrated to both in five months.
• Claude Mythos Preview rewrote the git-to-Scion ingestion pipeline, producing a version that used 20x less memory and ran 4x faster.

The post does not describe the cutover plan or downtime, so I can say nothing about how the migration was done.

The part most people skip

Two paragraphs in the post are about people and process, not storage.

Human-scale practices stopped fitting. The post says Anthropic has not been able to effectively replicate the industry standard of a global repository lock on the merge queue. It has invested in post-merge and pre-deploy automated testing instead, and says Claude can typically fix conflicts faster than humans can even identify them. Reviewers now examine the intent of a change instead of reading every line, and the code review tool can express complex semantic constraints on approvals.

The engineer's job moved toward saying no. The post says the role of the engineers was to tell Claude "no," and gives two examples: multiple systems that tried to brute-force looking up when a change merged to main, and one review that was overly defensive about trusting another internal service.

Who should not copy this

The post is direct about the limits. Scion is "by no means a suitable replacement for git for general use," and it fits an organization with either tens of thousands of engineers or swarms of agents prolifically writing code. The post says Anthropic's ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. And because Scion diverges from git, adopting it means replacing code review, code search and CI too, which are highly bespoke inside Anthropic.

The post does not announce a release. It says it is difficult to offer Scion in a form that would be broadly useful, and that the most impactful thing Anthropic can do is share its thinking. It names three directions for the wider ecosystem: git servers that do not mirror client behavior, server-side RPCs on git platforms, and a redesigned negotiation protocol where sparse and shallow features compose well.

What a smaller team can take from it

This section is my opinion, not the post's.

1. Count your own checkouts. Most teams have never added up how many times per day CI, agents and sandboxes fetch the repo. At agent scale that number, not developer headcount, is what breaks things.
2. Treat source control as an API for machines. If a job only needs to know what changed, asking a server beats cloning.
3. Look for human-scale locks. Merge queues, serialized deploys and manual review gates all assume a human pace. Anthropic's own post says it could not make a global merge-queue lock work at its volume.
4. Do not rebuild git. Anthropic needed this at 30,000 merges a day with a seven-person team and its own models doing the work. Try the sparse and shallow tools git already has first.

What I could not verify

I read one primary source and did not test Scion or run any of the numbers. Every performance figure is Anthropic's claim. The post does not describe the cutover plan, downtime, or whether the 600 PB figure was ever actually transferred rather than being a calculation. Several news write-ups say Anthropic will not open-source Scion or give a different reading of the post. I used only the post's own wording. Details may change.

Source, accessed October 14, 2026: Anthropic Engineering, "Redesigning source control at Anthropic" (anthropic.com/engineering/redesigning-source-control).

If your agents started merging ten times more code next quarter, which part of your pipeline would break first?

#AI #Git #SoftwareEngineering #AIAgents

---

Work with me: I take 1:1 calls on mobile architecture reviews, mobile and AI questions, and startup tech consults. Book a slot on Topmate: topmate.io/sairamkotha