Anthropic moves its monorepo off git to in-house Scion in five months

Anthropic's engineering team describes why it dropped git for its monorepo and what it built instead. The starting claim: at Anthropic, coding is no longer the bottleneck. Claude can iterate on research loops, micro-optimize complex programs and build new services from scratch at a speed the company had not seen before. What now limits progress is developer infrastructure built for human scale: source control, builds and CI.

The numbers behind that claim: in May 2026 Anthropic averaged around 2,500 code changes merged per day; as of September it merged over 30,000 per day. The company says it does not expect that growth to slow soon, because the latent demand for merging code is practically infinite and every bottleneck removed leads to more code. To keep up, it built Scion, an in-house version control system, and fully migrated its monorepo from git in five months. In the same period it also built and shipped a code review surface called Antique, code search, a source control IAM system, and new ways of managing and landing large amounts of reviewed code.

Git's strain shows in the repository's size and in CI traffic. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. Anthropic does on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes and research jobs; fetched naively, that would be over 600 PB of git traffic per day. Git's own tools (shallow clones, sparse checkouts, promisor remotes) and the usual monorepo workarounds (internal mirrors, repository snapshots called seeds) were all tried. At peak Anthropic operated several hundred internal git mirrors. That bought time, but the mirrors became harder to operate as the merge rate rose, seeds drifted further from the tip of main between refreshes, and keeping history-dependent operations such as diff and blame working on partial clones took ever more care.

The team's key observation was that, like most companies, it used git as a centralized system with one authoritative copy, while nearly all of its clients were agents and jobs that are online by definition. Git's strengths for distributed, offline work were working against scale. So it asked what source control would look like if designed for always-online agents.

Scion's principles, as the post lists them: clients are always online and fetch data when needed; the client and server are asymmetric, with the server answering history and blame questions, creating commits, and performing merges and rebases, while the client keeps a bounded local object cache, lays out files on disk and watches for filesystem changes; every source control query the client uses is also exposed by API, so many jobs need no local repository (automated bisect and revert pipelines are cited as examples); everything is horizontally scalable, with no fully materialized copy of the repo anywhere, even on the server, and no equivalent of packfiles, so no repository maintenance; commits are cheap, incremental and lock-free, with every commit, rebase or merge happening on the server so there is nothing to push, and refs discouraged except for the main ref or release branches; and the working copy is optional and sparse by design, with sparse and virtualized checkouts that materialize files on demand. The post credits prior art for huge monorepos, notably Google's Piper and Meta's Sapling.

On the architecture: the unit of work is a changeset, an entry in a write-ahead log. Instead of a pointer to a tree, a changeset stores the list of files changed relative to its first parent, plus content-addressed pointers to compressed contents in blob storage. Changesets are created server-side and available everywhere instantly, with no packfiles to accept, no locking or cross-server coordination and no refs to move. Scion does technically support refs, but moving one is a compare-and-swap on a single Spanner row, separate from creating changesets.

Because a changeset records only what changed, answering questions like who last edited a line needs extra structures: dedicated ones for file blame and path history, and skip lists for the commit graph. Anthropic calls all of this derived data and computes it through one generic mechanism, defined recursively from the values for a changeset's parents. The post names three benefits: new types are easy to add, each type can be computed eagerly or deferred, and the structures can be optimized without changing the client. New types added over time include indices for copy detection and path-based file search.

A small fleet of Scion servers provides APIs for getting changesets, computing diffs, finding merge bases and fetching blobs. All data is content-addressed and immutable, so any server can cache it without checking with others; the servers are essentially large caches that can also compute derived data on the fly and write results back to Spanner. Early in the migration, before Anthropic had its own client, repo format or protocols, Scion only answered metadata queries such as ancestry and blame; file contents and working copies needed their own design.

That design is the scn client. Its negotiation does not tell the server what the client already has; it asks only for the trees and blobs it wants, starting from a root tree and requesting missing trees recursively, then blobs. Every request is for an immutable object, so any cache can answer, the setup resembles tiered caches, transfers are resumable, and there is no multi-gigabyte packfile response. The post says this requires significantly less CPU than git servers. On each node, the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node so jobs on the same machine reuse most objects; each daemon starts from a periodically refreshed snapshot.

Anthropic frames its workload as unusual, since it uses Claude to write software far more than almost any other company. It does not expect many organizations to hit these problems in the very near term, but suspects it won't be long before others using AI coding tools feel the same pressure. The post also notes the loop: Claude's ability to write code created the problem and was how the team built a scalable system quickly.

Key facts

Anthropic fully migrated its monorepo from git to its in-house version control system Scion in five months.
Merged code changes rose from an average of around 2,500 per day in May 2026 to over 30,000 per day as of September.
Git strain: main branch history almost 100 GB, a compressed working copy over 25 GB, about 25 million CI checkouts per day, and several hundred internal git mirrors at peak.
Scion is server-centric: commits, merges and rebases happen on the server, the repo is never fully materialized, and the scn client fetches only the trees and blobs it wants.
Anthropic suspects other organizations using AI coding tools will hit the same source control pressure points, though it does not expect many to in the very near term.

Why it matters

The post is a first-hand account of AI-written code overwhelming the infrastructure around it. Anthropic argues the bottleneck has moved from writing code to source control, builds and CI, and says merge volume grew from about 2,500 a day in May 2026 to over 30,000 a day by September. The response was not a tuning exercise but a replacement of git for the whole monorepo, within five months. Scion's design flips git's assumptions: instead of every client holding a full copy and acting as its own server, a central service does the work and clients fetch only what they need. Anthropic cites Google's Piper and Meta's Sapling as prior art for huge monorepos, so the idea is not new, but the driver here is agents that are always online.

Who it affects

Directly, Anthropic's own engineers, agents, CI jobs and research jobs, which now work against Scion. More broadly, any team whose volume of automated commits and checkouts is climbing. Anthropic says it does not expect many organizations to have these problems in the very near term, but suspects it won't be long before others who use AI coding tools run into the same pressure points. Teams building CI, build and code review tooling are the nearest audience, since the post says its lessons can apply to other stages of the software development lifecycle.

How to use it

The portion of the post we read does not say Scion or Antique is open-sourced or available to outsiders, so this is a design study rather than something to install. The practical takeaways are the patterns. Expose source control queries (history, blame, diffs, merge bases) by API so CI jobs and tools do not need a local clone. Make checkouts optional, sparse or virtualized. Keep fetches content-addressed and immutable so any cache can serve them. Compute indexes such as blame and path history as derived data that can be added or optimized without touching clients. Discourage refs beyond main and release branches, since global state every server must agree on is a scaling problem.

How solid is it

This is a first-party engineering post, and the claims are Anthropic's own: the merge rates, repository sizes, checkout counts and the five-month migration are self-reported and not independently verified. The 600 PB figure is a hypothetical for naive fetching, not a measured traffic number, and the 25 million checkouts are an order of magnitude. The portion of the post we read reports no benchmarks or latency figures for Scion itself; the claim that scn needs significantly less CPU than git servers is stated without numbers there. The original article continues beyond the part covered here.

Risks and caveats

Scion's design depends on an always-reachable server. Anthropic says this fits because nearly all its clients are agents and jobs that are online by definition, and the post itself notes that git's decentralized design is right for the vast majority of repositories. A server-centric system gives up offline work and local computation by design: the client can compute very little on its own. The post also stresses that Anthropic's workload is unusual, so its choices may not transfer to organizations with normal merge volumes. Building it took heavy use of Claude, and the post gives no team size or cost.

“The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.”

— Anthropic engineering post, Redesigning source control at Anthropic