Anthropic's Scion: How Anthropic Replaced Git With an Agent-Scale Version Control System

Anthropic announced that it built Scion, an in-house version control system, and fully migrated its monorepo off git in five months, because git's decentralized, offline-first design could no longer keep up with AI agents writing code. The company reports that merged code changes grew from roughly 2,500 per day in May 2026 to over 30,000 per day in September 2026, and that Scion's infrastructure footprint is 200x smaller than its previous git mirroring setup in CPU and memory terms.

The core problem: coding stopped being the bottleneck

At Anthropic, the bottleneck to building systems and doing research is no longer writing code — it is the developer infrastructure built for human scale: source control, builds, and CI. Claude can autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up, and the surrounding tooling has become the constraint.

The growth numbers Anthropic cites are steep. In May 2026, Anthropic averaged around 2,500 code changes merged per day. As of September 2026, it merged over 30,000 per day. Anthropic states it does not expect this rate of growth to slow down, describing the latent demand for merging code as "practically infinite" and noting that every bottleneck removed immediately leads to a further increase in the amount of code produced.

Alongside Scion, Anthropic 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 — all in the same five-month period.

Why git stopped fitting Anthropic's monorepo

Git is a decentralized system in which every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. Anthropic states plainly that for the vast majority of repositories this is the right design, and that it is a large part of why git became the standard. Anthropic's monorepo, however, increasingly falls outside that design space.

The concrete scale figures Anthropic gives:

The history of the main branch alone is almost 100 GB.
A compressed working copy is over 25 GB.
Anthropic performs 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.

Anthropic used every standard workaround available: shallow clones, sparse checkouts, promisor remotes, internal git mirrors, and repository snapshots (seeds) kept in blob storage. At its peak, Anthropic operated several hundred internal git mirrors to deal with the load. These bought time but became harder to operate as the merge rate increased — seeds fell further from the tip of main between refreshes, and keeping history-dependent operations like diff and blame working on partial clones required more and more care.

The key insight was that Anthropic, like most companies, was using git as a centralized system with one authoritative copy, while nearly all of its clients are agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining Anthropic's ability to scale as the repo grew.

Six principles behind Scion

Anthropic notes prior art for source control in huge monorepos, specifically Google's Piper and Meta's Sapling, and says it built Scion with those hard-won lessons in mind. The design rests on six principles:

1. Clients are always online

Git assumes clients work offline and need a complete copy of the repository. Because nearly all of Anthropic's clients are agents and jobs, Scion's client and protocols are designed around a server that is always reachable, with clients fetching data when they need it.

2. Client-server asymmetry

In git, every client is capable of being a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on. The client maintains a bounded local object cache, lays out working copy files on disk, monitors for filesystem changes, and provides an ergonomic way to work with the server. It can compute very little on its own but requires much less data locally.

3. A comprehensive source control service can power many novel applications

With git, a CI job or tool that needs to ask a question about the repository — who last changed a line, how two commits are related — has to maintain a local copy or rely on vendor-specific APIs. With Scion, all source control queries the client uses are also exposed via API, so in many cases jobs do not need a local repository at all. Anthropic says internal tools such as its automated bisect and revert pipelines would not be practical at scale without this cheap, programmatic access to source control.

4. Everything must be horizontally scalable

At peak, Anthropic ran several hundred git mirrors, which strained capacity and stopped scaling once the repo outgrew the mirrors' disks or memory limits. In Scion, repository data is distributed and every component is independently scalable. There is no fully materialized copy of the repo anywhere, even on the server. There is no equivalent of git's packfiles, so no repository maintenance is needed.

5. Commits must be cheap, incremental, and lock-free

In git, you commit locally and then push to share work. In Scion, every commit, rebase, or merge happens on the server, so there is nothing to push — but each of those operations must be fast. The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo. Scion's development lifecycle discourages refs (pointers to commits such as branches and tags), except for the main ref or release branches, because global state that every server must agree on is a looming scaling problem.

6. The working copy is optional, and sparse by design

Because the monorepo is so large and code is checked out tens of millions of times a day for CI, Anthropic wanted to avoid checkouts wherever possible. A CI job that needs the diff between a commit and its merge base can ask the server for it. Many write workloads can also skip the checkout and function entirely via API. Scion's protocol is centered on sparse checkouts, which contain only the directories the client asks for, and virtualized checkouts, which materialize files on demand, so a job only pays for what it actually reads.

How Scion works: changesets and derived data

In Scion, the unit of work is a changeset, an entry in a write-ahead log. A changeset stores most of what a git commit stores, but where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere instantly.

This structure lets Scion accept changesets at very high throughput: there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Scion technically supports refs, but since neither creating nor fetching commits involves them, moving a ref is a compare-and-swap on a single Spanner row that happens separately from creating changesets.

Because a changeset records only what changed, it cannot on its own quickly answer questions like who last edited a line or which commits affected a file. Scion therefore builds additional data structures from the changesets — dedicated structures for file blame and path history, and skip lists for the commit graph. Anthropic calls everything that is not directly part of the changeset derived data, and computes all of it through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset's parents.

Anthropic cites three benefits of this mechanism: new types of derived data can be added easily when a new data structure would make an operation faster; each type can be computed eagerly or deferred so unneeded data is never materialized; and because the client never sees the internals of these structures, they can be optimized without changing the client. Anthropic says it has added new types of derived data many times as the system grew, including new indices for copy detection and path-based file search.

The serving architecture: daemon, cache, and server tiers

A small fleet of Scion servers provides source control APIs for any operation a client needs — getting changesets, computing diffs, finding merge bases, fetching blobs. All source control data is content-addressed, so a piece of data never changes once stored and any server can cache it without checking with the others. The servers are therefore horizontally scalable and require little coordination, acting essentially as large caches that can compute derived data on the fly and write results back to Spanner.

Scion's scn client deviates from git's fetch protocols in several important ways. Scion's negotiation does not tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific object that never changes, so any cache can answer it, and the architecture closely resembles traditional tiered caches. The process is efficient and resumable because there is no single multi-gigabyte packfile response. Sparse and even virtualized checkouts need no special support, because the client simply does not ask for trees it does not want.

The client talks over a socket to a daemon, scion-daemon, which stores objects for the whole node. Most nodes need access to the monorepo, and jobs on the same node reuse most of the same objects. Each daemon starts from a periodically refreshed snapshot, then talks only to the tree and blob cache servers in its region, called scion-cache. These cache servers stream objects directly from memory in the disk format the daemon will consume, so they do not spend time computing the client's missing objects or performing delta compression. When a cache is missing an object, it asks the authoritative scion-servers, which read from Spanner or cloud storage as needed.

The scion-daemon, scion-cache, and scion-server all respond to identical RPCs for this protocol, so the client does not need to know the cache topology. Any tier could theoretically talk to any other, but Anthropic strictly enforces the tiering to isolate failure domains — specifically to avoid a regional scion-cache failure overwhelming the upstream scion-servers and bringing down the entire system.

Measured results

Anthropic reports the following outcomes from the migration:

Each tier of the system maintains a cache hit rate of over 99% and does not require long-lived state, making it easy to scale up.
Scion's infrastructure footprint is 200x smaller than the previous git mirroring infrastructure in terms of CPU and memory requirements.
CI and research jobs check out code two orders of magnitude faster — in seconds rather than minutes — freeing up a sizable amount of capacity across the fleet.
CI alone realized a 25% CPU capacity win.
Neither clients nor caches need to perform repository maintenance, simplifying lifecycle management of jobs.

What Anthropic learned building Scion

Anthropic started building Scion around the same time as Claude Mythos Preview and Claude Tag became available internally. It says both releases simultaneously amplified the need for Scion and meaningfully accelerated how quickly the system could be built.

Claude rewrote the ingestion pipeline

Anthropic had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. After getting access to an early internal snapshot of Claude Mythos Preview, the team asked it to rewrite the whole thing. With no further instructions, Claude produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures.

Small teams can now do multi-year migrations in months

A team of seven people built both Scion and Antique, plus half a dozen related systems, and fully migrated to them in five months — all while the volume of code merged per day increased by 10x. Anthropic notes that developing and deploying a source control system like this would previously have taken a company years of iterative migration with many more engineers, and expects this kind of fast, nimble migration to become more common.

Engineers are no less valuable, but their work is changing

Anthropic states that all of the engineers who worked on this system would now rate Claude as better at writing code than they are. Those engineers still supplied the understanding of high-level inter-system components and design-level tradeoffs, making informed choices about which problems to solve and what scale to achieve. Anthropic describes the engineer's role as often being to tell Claude "no": agents sometimes violate core system constraints to satisfy a pattern that should never have been allowed. This was particularly common during the migration — for example, multiple systems tried to brute-force looking up when a change merged to main by linearly reading the commit log instead of asking the code review tool.

Anthropic also makes extensive use of adversarial review, which it calls incredibly effective but sometimes myopic. Skilled engineers had to steer Claude away from over-engineering in response to hypothetical concerns; one such review was overly defensive about trusting another internal service, which resulted in Claude adding excessive validation and complexity. Team members still review every change request for the system, but they now examine the intent of the change rather than reading every line of code.

Optimization and quality improved substantially

Because Claude can write immense amounts of code much faster than humans, Scion is among the most well-tested and well-defended codebases Anthropic has ever worked on. Even on the tight timeline, the team built hermetic simulations of every non-trivial infrastructure and source control interaction it had encountered, plus fuzzing and sophisticated rate limiting. Anthropic also reports that Claude casually found significant optimizations — for example, an algorithmic optimization to ancestry queries that had missed one of the team's indexes, work that would have taken an expert days or weeks of analysis and tuning — and then did it all again the next day.

New forms of monorepo security

Scion supports rich access control on repositories and the ability to apply permissions to individual directories, protecting the most sensitive code without losing the benefits of a monorepo. The code review tooling Anthropic built can express complex semantic constraints on approvals, letting the team differentiate simple changes such as comment-only edits from sensitive logical changes so human reviewers can focus on the most consequential ones.

"Superfans": Claude as a component-level monitor

The team uses Claude Tag heavily. It created Slack channels where Claude is tasked with being obsessively focused on the health of a single component — a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, and so on. These Claudes have access to telemetry and logs and act like an experienced engineer who has nothing better to do than refresh charts and look for anything strange. Anthropic still runs traditional alerts for all systems, but says the superfans detect subtle and novel issues that make those alerts seem one-dimensional by comparison.

Rethinking merge queues and CI

The project prompted Anthropic to re-examine other workflows designed for human scale. A proper merge queue does not make much sense at agent scale, and the company asks what CI even means when hundreds or thousands of changes can merge while tests are running. Anthropic has not been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead it invested in post-merge and pre-deploy automated testing. This means concurrent changes can conflict, but Anthropic says Claude can typically fix those conflicts faster than humans can even identify them.

Scion is not a git replacement for general use

Anthropic is explicit that Scion is by no means a suitable replacement for git for general use. The concepts it describes only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Anthropic also notes it is unique in that its ability to spend tokens for internal use far exceeds what any other business would realistically want to spend — it does so both to address its own software development needs and to test Claude's capabilities.

Practically, Anthropic says it would be difficult to offer Scion in a form broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI. Anthropic's internal versions of these components are highly bespoke and would be difficult for other organizations to adopt; it worries that a public version trying to please everyone would not actually be very useful.

What Anthropic suggests for the wider git ecosystem

Anthropic anticipates that this class of problems will become more commonplace over the next six to 12 months, and argues it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Its stated contribution is therefore to share its thinking so other developers can apply the most successful parts of Scion to git without departing from the overall model.

Specific directions Anthropic suggests for git:

A git server does not have to work the same way as a git client does; novel server architectures exist that provide significant scaling improvements.
Git platforms can provide comprehensive server-side RPCs like Scion, perhaps even in a standardized way across forges that the git client can learn to talk to.
The negotiation protocol does not have to look exactly as it does today.
The various sparse and shallow features in git can be made to compose well.

Anthropic closes by acknowledging that the git community has spent nearly two decades scaling the platform for millions of developers. It describes its own contribution as far narrower — sharing an early view into how agentic software development interacts with these systems — and says it wants to partner with GitHub, GitLab, and the OSS community to support the changing needs of developers as the software development lifecycle intersects with the AI exponential.