Why Git Wasn't Enough: Anthropic's Scion, Monorepos and AI Agents

If the code changes merged each day grew more than twelvefold in five months, where would your development infrastructure break first? Anthropic says it went from about 2,500 merges a day in May 2026 to more than 30,000 a day in September. Its answer was to drop Git and build its own version control system, Scion.

This post is based on Anthropic's engineering blog post, Simon Willison's write-up, and the reactions I checked. I only state facts I could confirm in the original, and I've marked my own interpretation separately.

Why did Git become a problem?

Git is a distributed system. When you clone, the whole repository lands on your machine, so you can run diff, history, blame and checkout without a network. For most repositories that's the right answer, and it's a big reason Git became the standard.

The problem is scale. Here are the numbers Anthropic shared.

• The main branch history alone is nearly 100GB
• A compressed working copy is over 25GB
• CI checks out code about 25 million times a day (not counting developer environments, agent sandboxes or research work)
• Pulled straight through Git, that's more than 600PB of traffic a day

AI · DEV · SCALEIf you pull it all through GitA problem created by monorepo scaleTHE ROVER

100GBmain historyWorking copy 25GB+

25MCI checkouts/day

600PB+daily trafficWith plain Git clones

The limits of the usual workarounds

Git has tools for large repositories: shallow clones, sparse checkouts and promisor remotes. Running an internal Git mirror, or keeping repository snapshots (seeds) in blob storage, is also common.

Anthropic tried all of it, and at peak it ran hundreds of internal Git mirrors. That bought time, but the faster merges came in, the harder it got to operate. Seeds drifted further from the latest point on main between refreshes, and keeping history-dependent operations like diff and blame working in partial clones took more and more effort.

Changing the question

Here's the part I found interesting. Anthropic stepped back and noticed that, like most companies, it was running Git as a centralized system with one authoritative copy. Nearly all of its clients were agents and jobs, and those are online by definition. The properties Git is optimized for, offline work and distribution, were now holding back scale.

So the question changed: "What would source control look like if we designed it from scratch, assuming agents are always online?"

Scion's design principles

The original lists six principles. Here's a table comparing them with Git. The comparison column is my condensed version of the original's explanations.

Let me unpack a few of these.

A smart server and a light client

In Git, every client can be a full server. Scion goes the other way. The server answers file history and blame questions, creates commits, and does merges and rebases. The client keeps a limited local object cache, places files on disk and watches for filesystem changes. It can compute almost nothing on its own, but in exchange it needs far less data locally.

Source control as an API

In Git, if a CI job wants to ask "who last changed this line?", it has to download the repository or lean on a hosting vendor's API. Scion exposes every query the client uses as an API too, so in many cases a job works without a local repository. The original says internal tools like automated bisect and revert pipelines wouldn't have been practical at scale without access this cheap and easy to program.

Fewer branches, no locks

The Scion workflow discourages refs (commit pointers like branches and tags) other than main or release branches. Global state that every server has to agree on creates scaling problems. The principle is that a commit's cost should scale with the size of the change, not the size of the repository, and that there should be no locks.

How does Scion work?

Changesets and derived data

Scion's unit of work is the "changeset," an entry in a write-ahead log. Where a Git commit stores a pointer to a tree, a changeset stores the list of files that changed relative to the first parent, plus content-addressed pointers to compressed file contents in blob storage. The server creates it, and it's usable anywhere the moment it exists.

This structure lets Scion take in changesets at high throughput with no packfiles, no locks, no coordination between servers and no refs to move. Refs are technically supported, but moving one is a compare-and-swap on a single Spanner row, and it happens separately from changeset creation.

Because a changeset records only "what changed," it can't directly answer questions like "who last modified this line?" So Scion builds extra data structures from changesets: file blame, path history, skip lists for the commit graph and so on. The original calls everything that isn't the changeset itself "derived data." Each kind is defined recursively, so the value for one changeset is computed from the values of its parents.

The original names three advantages.

1. If you need a new data structure, you can add a new kind of derived data easily.
2. For each kind, you can choose whether to precompute it or defer it.
3. Clients never see the internal structure, so you can optimize without changing clients.

Checkout architecture

A Scion server is a small fleet that serves the source control API. All data is content-addressed, so once stored it never changes, and any server can cache it without checking with another. That makes the server something like "a big cache that computes derived data on the fly and writes it back to Spanner."

The scn client doesn't behave like Git's fetch protocol. In the negotiation step it doesn't tell the server what it already has. It just requests the trees and blobs it wants. Starting from the root tree, it recursively requests any trees it's missing, then gets blobs the same way. Every request is for a specific immutable object, so any cache can answer it, and the result looks a lot like a tiered cache. With no giant packfile responses, resuming is easy too. Sparse and virtualized checkouts need no special support, because the client simply doesn't request the trees it doesn't want.

On a node, scion-daemon stores objects for the whole node and talks only to the regional scion-cache. If the cache doesn't have an object, it asks the authoritative scion-server, which reads from Spanner or cloud storage as needed. The three tiers answer the same RPCs but strictly enforce the hierarchy, which isolates failure domains so a regional cache outage doesn't spread to the servers above it.

AI · DEV · CHECKOUTThree checkout tiersIf it's missing, ask one tier upTHE ROVER

Nodescion-daemon

Regionscion-cache

Originscion-server

Cache hit rate over 99% per tier

Results

These are the numbers from the original.

• Cache hit rate of over 99% at every tier
• Scion infrastructure needs 200 times less CPU and memory than the old Git mirroring infrastructure
• Checkouts for CI and research jobs got more than ten times faster (from minutes to seconds)
• CI alone saved 25% of CPU capacity

Five months, seven people, and Claude

What caught my eye more was how it was built. According to the original, seven people built Scion, the code review tool Antique and about six related systems, and finished the migration in five months. Over that period, daily merge volume grew tenfold. Anthropic says this would have taken far more people and years of gradual migration in the past.

The human job is saying "no"

This is the most realistic part of the original. All the engineers involved rate Claude as a better coder than themselves, but it was people who judged the structure across systems and the design trade-offs. And often, the human's job was telling Claude "no."

For example, several systems tried to find "when something was merged to main" by reading the commit log linearly instead of asking the code review tool. That's a case of an agent breaking a key constraint to fit a pattern.

Adversarial review is similar. It's very effective, but it can be shortsighted, so experienced engineers had to steer it so the system didn't get more complex from overreacting to hypothetical concerns. One example in the original: an overly defensive review about trusting another internal service led Claude to add piles of unnecessary validation. Simon Willison also wrote that he had the same experience when he had models review each other's work on his own projects.

Team members still review every change request, but they say they now look at the intent of a change rather than reading every line.

Quality and operations

Because Claude can write a lot of code quickly, the original says Scion became "the best-tested and best-defended codebase." In a short timeline, the team added isolated simulations that reproduce the infrastructure and source control interactions people had run into, fuzzing, and sophisticated rate limiting. Claude also found a missed index while improving the algorithm for ancestry queries, something that would have taken an expert days to weeks.

For operations, they put "superfans" in Slack channels: Claude instances obsessed with the health of a single component. There's a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan and so on. Each one watches telemetry and logs like a veteran engineer refreshing charts and looking for oddities. Traditional alerts exist too, but the superfans reportedly catch subtle, new anomalies.

When merge queues lose their meaning

I found this part the most thought-provoking. The original says "merge queues don't fit at agent scale." If hundreds or thousands of changes can merge while tests are running, it asks what CI even means. The team couldn't effectively reproduce the global repository lock that the industry-standard merge queue relies on. So they invested in automated testing after merge and before deploy instead.

The original admits this approach allows conflicts between concurrent changes. It adds that Claude usually fixes them before a human notices. That doesn't mean it's a strategy for every organization. The same post cautions that Anthropic's internal token budget is far beyond what other companies would realistically want to spend.

Prior art and the debate

Scion didn't come from nothing. The original cites Google's Piper and Meta's Sapling as earlier examples of large monorepo source control. In an October 15 edit, it added a footnote saying that Mononoke, Sapling's server component, pioneered many of the techniques Scion uses, the Bonsai data model in particular.

There's a reason for that edit. sunshowers, who worked on Mononoke, pointed out in a blog post that the "derived data" concept closely resembles how Mononoke is described, and criticized the omission of Mononoke from the first version as bordering on plagiarism. At the same time, they said reusing a design isn't a problem in itself, and argued that as LLMs help with design, it becomes easier to lean on existing designs in their training data, so naming sources matters more. That's one individual's assessment, not Anthropic's position, so it helps to read the two separately.

Personally, I think there's one technical takeaway from this debate. A design an agent produces may look new and still be a rediscovery of a known one. It's worth adding "find prior art" to your prompts and review process.

What it means for our team

The first thing Anthropic itself stresses: Scion is not a general replacement for Git. For the idea to make sense you need a truly huge monorepo, with tens of thousands of engineers or swarms of agents pouring in code, and Scion needs its own code review, search and CI, which makes it hard for other organizations to adopt. So "let's drop Git too" is not the conclusion.

What the original suggests instead is more practical. A Git server doesn't have to behave exactly like a Git client, and there may be a new, more scalable server architecture. Forge platforms could offer comprehensive server-side RPCs like Scion's, change the negotiation protocol, and make sparse and shallow features compose well. Anthropic also says it wants to work with GitHub, GitLab and the open source community.

Here's a checklist of the practical lessons I took away. It's my interpretation of the original's claims, applied to an ordinary team.

One last thing. The sentence that stayed with me longest wasn't a number but the first paragraph's point that coding is no longer the bottleneck. As the speed of writing code goes up, the bottleneck moves to infrastructure sized for humans, like source control, builds and CI. I think just sketching where your own team's bottleneck is right now makes this post worth reading.