Anthropic's Scion: Redesigning Source Control for Agent-Scale Monorepos

Anthropic announced that it built Scion, an in-house version control system, and fully migrated its monorepo off git in five months, because developer infrastructure designed for human scale — source control, builds, and CI — had become the bottleneck now that Claude writes most of the company's code. The post is a technical case study of Scion's design, not a product release: Anthropic states plainly that Scion is not a suitable general-purpose replacement for git and that it has no plans to offer it broadly.

The problem: merge volume outgrew git

Anthropic's merge rate grew roughly 10x in four months, and the company does not expect that growth to slow. 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 describes the latent demand for merging code as "practically infinite," and notes that every bottleneck removed immediately leads to a further increase in the amount of code produced.

The monorepo's scale is the direct cause of the infrastructure strain. The history of the main branch alone is almost 100 GB, and 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.

Git's decentralized design — where every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline — is the right design for the vast majority of repositories, and Anthropic says so explicitly. It simply does not fit this workload. Anthropic used shallow clones, sparse checkouts, promisor remotes, internal git mirrors, and repository snapshots (seeds) in blob storage. At its peak, the company operated several hundred internal git mirrors to deal with the load. Those workarounds 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 observation that motivated Scion: Anthropic was using git as a centralized system with one authoritative copy, but 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 for agent-scale source control

Scion was designed around a different set of assumptions than git. Anthropic credits prior art in large-monorepo source control — Google's Piper and Meta's Sapling — as informing the design.

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 built around a server that is always reachable, and clients fetch data when they need it.

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, and performs merges and rebases. The client maintains a bounded local object cache, lays out working copy files on disk, monitors for filesystem changes, and provides an ergonomic interface to the server. It can compute very little on its own but requires much less data locally.

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, or how two commits are related — has to maintain a local copy of the repo or rely on vendor-specific APIs. With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs need no local repository at all. Anthropic states that many internal tools, such as its automated bisect and revert pipelines, would not be practical at scale without this cheap, programmatic access to source control.

Everything must be horizontally scalable. The several hundred git mirrors Anthropic ran at peak strained capacity and stopped scaling once the repo outgrew the mirrors' disks or memory limits. In Scion, the repository's 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 packfiles, so no repository maintenance is needed.

Commits must be cheap, incremental, and lock-free. In git, you commit locally and then push to share your work. In Scion, every commit, rebase, or merge happens on the server, so there is nothing to push, but each operation 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.

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 whenever 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

Scion's 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 compressed file contents in blob storage. Changesets are created server-side and are available everywhere instantly.

This structure allows Anthropic to accept changesets at very high throughput because 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 one 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, including 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 it all 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 some operation faster; each type can be computed eagerly or deferred, avoiding materialization of unneeded data; and because the client never sees the internals of these data structures, they can be optimized without changing the client. Anthropic has added new types of derived data many times as the system grew, including new indices for copy detection and path-based file search.

Scaling Scion: a tiered cache architecture

A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and 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 — essentially large caches that can also 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 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, that 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, avoiding a situation where a failure in a regional scion-cache overwhelms the upstream scion-servers and brings 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 the 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. The post states that both releases simultaneously amplified the need for Scion and meaningfully accelerated how quickly it could be built.

A concrete example: earlier in the year, 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, it 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.

Rapid development with a small team will become more common

A team of seven people built both Scion and Antique (Anthropic's code review tool), 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 them. But 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 will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place.

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, so skilled engineers had to steer Claude away from over-engineering parts of the system in response to hypothetical concerns. One such review was overly defensive about trusting another internal service, resulting in Claude adding excessive validation and complexity. Team members still review every change request for the system, but 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, Anthropic describes Scion as among the most well-tested and well-defended codebases it has ever worked on. Even on a 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. Claude also found significant optimizations — for example, an algorithmic optimization to ancestry queries that had missed one of the team's indexes — that Anthropic says would have taken an expert days or weeks of analysis and tuning, and then did it again the next day.

Groundwork for new forms of monorepo security

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

A new level of operational excellence is possible

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

Anthropic is rethinking its priors

The project prompted Anthropic to re-examine other workflows designed for human scale. A proper merge queue, for example, does not make much sense at agent scale, and the post 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 states that Claude can typically fix these conflicts faster than humans can even identify them.

Scion is not a git replacement, and Anthropic is not open-sourcing it

Anthropic is explicit that Scion is by no means a suitable replacement for git for general use. The concepts outlined 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 this 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; the company worries that a public version trying to please everyone would not actually be very useful.

Instead, Anthropic says the most impactful thing it can do is share its thinking so other developers can apply the most successful parts of Scion to git without departing from the overall model. Specific suggestions from the post:

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 like it does today, and git's various sparse and shallow features can be made to compose well.

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. The post closes by acknowledging that the git community has spent nearly two decades scaling the platform for millions of developers, and frames Anthropic's contribution as narrower: an early view into how agentic software development interacts with these systems, in order to partner with GitHub, GitLab, and the open source community.

Technical footnote

Scion stores changed files relative to the first parent of a merge. Anthropic describes this as a stylistic choice, noting that in practice people only care about history or blame for commits on the main line in trunk-based development in a monorepo.

The post was written by Nick G. and the source control team (S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P.), with thanks to Vilas J. and Sergiu D. for supporting the team and Amir O. for early contributions to Antique.