Anthropic moved its monorepo off Git: what agent-scale merging asks of yours

Most discussion of AI coding agents asks how much code they write. Anthropic's engineering team has published a case study about the next problem: what happens to the systems that store and merge that code. In a post of 13 October 2026, it describes replacing Git in its monorepo with an in-house system called Scion, after daily merged changes grew more than tenfold in four months. Very few organisations have that problem today. The reasons behind the design are still useful to anyone whose CI and repositories were sized for people rather than agents.

What Anthropic reported

According to Anthropic's post, the company averaged around 2,500 merged changes a day in May 2026 and more than 30,000 a day by September. It says writing code is no longer what limits it. The limit is the developer infrastructure built for human scale: source control, builds and CI.

The numbers it gives for the repository are large. The history of the main branch is almost 100 GB, a compressed working copy is over 25 GB, and the company performs on the order of 25 million checkouts a day for CI alone. Fetched naively, it says, that would be over 600 PB of Git traffic a day. At its peak it ran several hundred internal Git mirrors to cope.

A team of seven built Scion, along with a code review tool and several related systems, and migrated the monorepo in five months. The post reports an infrastructure footprint 200 times smaller than the Git mirroring it replaced, in CPU and memory, checkouts two orders of magnitude faster, and a 25% CPU capacity gain in CI. These are Anthropic's own figures about its own systems.

The design, in plain terms

The core observation is that Git's model and Anthropic's workload had drifted apart. Git is decentralised: every clone is a complete repository that works offline. Anthropic notes that, like most companies, it used Git as a centralised system with one authoritative copy, and that nearly all of its clients were agents and jobs that are online by definition.

So Scion assumes the client is always online. The server answers questions such as history, blame and merge bases, and creates commits, merges and rebases. The client keeps a bounded local cache and fetches what it needs. Every source control query the client uses is also an API, so many CI jobs don't need a working copy at all. Checkouts are sparse or virtualised by design. Commits are cheap and lock-free, and branches and tags are discouraged except for the main line and releases, because global state that every server must agree on is a scaling problem.

Fetching works through tiers: a daemon on each machine shares objects between jobs, regional caches serve objects from memory, and only misses reach the central servers. The post says each tier keeps a cache hit rate above 99%. Anthropic credits prior art, in particular Google's Piper and the server component of Meta's Sapling.

What is specific to Anthropic, by its own account

The post is careful about this, and it is worth taking at its word.

• The workload is unusual. Anthropic says it uses its own models to write software more than almost any other company, and that it can spend far more on tokens internally than other businesses would want to.
• Scion is not a Git replacement for general use. The post says the ideas only make sense for enormous monorepos, with tens of thousands of engineers or large numbers of agents, and that Scion would be hard for others to adopt because it needs its own review, search and CI.
• The timeline is a forecast. Anthropic expects this class of problem to become common within six to 12 months. That is a prediction, not a measurement of anyone else's repositories.

Lessons that apply to teams on Git

The parts that transfer are about where the load goes, not about leaving Git.

Agents are always-online clients. Git already supports working on part of a repository. Partial clone lets a client skip objects it doesn't need and fetch them on demand from a promisor remote, at the cost of needing that remote to be reachable. Sparse checkout limits the working tree to a subset of files. Both assume the online access agents and CI jobs have anyway. Anthropic says it used all of these, along with shallow clones, internal mirrors and repository snapshots (seeds) kept in blob storage. They bought time, but became harder to operate as its merge rate increased: seeds fell further behind the tip of main, and keeping history-dependent operations such as diff and blame working on partial clones took more and more care. Meta's Sapling documentation makes a related point: its large-repository scaling depends on a server and virtual filesystem that it says are not yet publicly available.

Ask the server instead of cloning. A lot of CI work clones a repository to answer a narrow question: what changed between two commits, who last touched a file. Anthropic made those questions an API. Teams on Git can audit which jobs clone only to ask such questions, and whether their forge's API can answer them instead.

Share objects per machine. Jobs on the same machine fetch mostly the same objects. A shared local cache is the simplest version of Scion's tiering, and it doesn't require new source control.

Merge queues and CI change shape at high volume. Anthropic says it could not make the industry-standard global repository lock on the merge queue work at its scale, so it invested in post-merge and pre-deploy automated testing instead, accepting that concurrent changes can conflict. That is a real trade-off. It moves some failures from before merge to after it, and depends on fast automated repair.

What it says about review

Two passages matter for anyone setting review policy for agent-written code. Anthropic says its engineers' role was often "to tell Claude 'no'", because agents sometimes broke core system constraints to follow a pattern that should not have been allowed. It also says the Scion team's members still review every change request for the system, meaning Scion itself, but now "examine the intent of the change as opposed to reading every line of code." That describes one team's practice on one project, not a company-wide policy.

That second point deserves caution outside Anthropic. Reviewing intent works when the system around it catches what a line-by-line read would have: extensive tests, simulations, fuzzing and monitoring, all of which the post describes. Without that, it is simply less review. We discussed the same tension in review as the limit on software output. The post also describes directory-level permissions and approval rules that can distinguish comment-only changes from sensitive logic, which is a more transferable idea than skipping lines.

What it means for engineering and security leaders

• Track merge volume as a capacity metric. If agent use is growing, daily merges, CI checkouts and clone traffic are the leading indicators that infrastructure will strain.
• Budget for infrastructure, not only for tokens. Anthropic names its bottleneck as "source control, builds, and CI"; tiered caches were part of its fix. More agent output lands on those systems first.
• Keep review rules tied to risk. Approval rules that separate sensitive paths and logic from routine changes scale better than uniform line-by-line review or uniform intent review.
• Treat vendor case studies as direction, not benchmarks. The figures describe one very unusual company.

Practical takeaways

• Measure your merged changes per day and CI checkouts per day over the last six months, and plot the trend.
• Find CI jobs that do a full clone, and test partial clone or sparse checkout for each.
• List jobs that clone only to compute a diff, a merge base or blame, and check whether an API call could replace the clone.
• Add a shared object cache or reference repository on CI machines that run many jobs.
• Review your approval rules: which paths and kinds of change need human review regardless of who or what wrote them.