How Anthropic Redesigned Source Control for Agent-Scale Development

Anthropic reports that coding is no longer the primary bottleneck in building systems and conducting research. Claude can autonomously iterate through research loops, optimize complex programs, and build services from the ground up. The limiting factors have instead shifted toward developer infrastructure designed for human-scale workloads, including source control, builds, and continuous integration.

In May 2026, Anthropic averaged about 2,500 merged code changes per day. By September, that figure had exceeded 30,000. The company expects demand for merging code to continue increasing as infrastructure bottlenecks are removed.

To support this growth, Anthropic built Scion, an in-house version control system, and migrated its monorepo from Git in five months. During the same period, it also developed Antique, a code review system, along with code search, a source control identity and access management system, and new methods for reviewing and landing large volumes of code. This article focuses on Scion and the way Claude contributed both to the need for the system and to its implementation.

Growing the monorepo

Anthropic’s workload is unusual because it uses Claude to write software at a scale that few organizations currently match. As a result, the company often encounters limitations in tools designed around human development patterns. Anthropic expects organizations using AI coding tools to encounter similar constraints over time.

Git is decentralized: each clone is a complete repository that can compute diffs, inspect history and blame, and check out revisions while offline. For most repositories, this is an effective design and a major reason Git became the standard.

Anthropic’s monorepo increasingly exceeded the practical limits of that model. The history of the main branch alone approached 100 GB, while a compressed working copy exceeded 25 GB. The company performed about 25 million code checkouts per day for CI, before including developer environments, agent sandboxes, and research jobs. A naive fetch strategy would have generated more than 600 PB of Git traffic per day.

Git supports working with repository subsets through shallow clones, sparse checkouts, and promisor remotes. Large monorepos also commonly use internal Git mirrors and repository snapshots, or seeds, stored in blob storage. Anthropic used these techniques and, at its peak, operated several hundred internal Git mirrors.

These measures provided temporary relief but became increasingly difficult to operate as the merge rate rose. Seeds became increasingly out of date between refreshes, and partial clones required more maintenance to preserve history-dependent operations such as diff and blame.

Anthropic concluded that it was using Git as a centralized system even though most of its clients were agents and jobs that were online by definition. Git’s offline and fully distributed properties, which are valuable in general use, were making it more difficult to scale the growing monorepo. The company therefore considered what source control would look like if it were designed around permanently connected agents.

Principles for agent-scale source control

Anthropic drew on prior work for very large monorepos, including Google’s Piper and Meta’s Sapling. Scion was built around several principles that differ from Git’s assumptions.

Clients are always online

Git assumes clients may work offline and therefore need complete repository copies. Since most Scion clients are agents and jobs, Scion’s client and protocols are designed around an accessible server. Clients retrieve data when they need it.

Client and server responsibilities are asymmetric

In Git, every client can function as a full server. In Scion, the server answers questions about history and blame, creates commits, and performs merges and rebases. The client maintains a bounded local object cache, lays out working-copy files, monitors filesystem changes, and provides the user interface.

The client performs relatively little computation and consequently needs much less local data.

A complete source control service can support other applications

A CI job or tool using Git that needs to answer questions about a repository, such as who last changed a line or how two commits are related, generally needs a local repository or a vendor-specific API. Scion exposes the source control queries used by its client through APIs, so many jobs do not need a local repository.

Anthropic’s automated bisect and revert pipelines are examples of tools that rely on programmatic access to source control.

Every component must scale horizontally

Anthropic’s fleet of several hundred Git mirrors placed significant demands on capacity and stopped scaling effectively when the repository exceeded the mirrors’ disk or memory limits.

Scion distributes repository data, and each component can scale independently. No component holds a fully materialized copy of the repository, including the servers. Scion also has no equivalent of Git packfiles, the compressed bundles of objects, so it does not require repository maintenance of that kind.

Commits should be incremental, inexpensive, and lock-free

With Git, users commit locally and push their work. In Scion, commits, rebases, and merges happen on the server, so there is no separate push operation. These operations must therefore be fast, and the cost of creating a commit and updating related data structures must depend on the size of the change rather than the size of the entire repository.

Scion’s workflow also discourages refs, such as branches and tags, except for the main ref and release branches. Global state that every server must coordinate around can become a scaling problem.

Working copies are optional and sparse by default

Because Anthropic’s monorepo is large and CI performs tens of millions of checkouts per day, Scion avoids checkouts where possible. A CI job that needs the difference between a commit and its merge base can request that information from the server. Many write workloads can also operate through APIs without materializing a checkout.

When files are needed locally, Scion supports sparse checkouts containing only requested directories and virtualized checkouts that materialize files on demand. Clients therefore retrieve only the data they actually use.

How Scion works

Scion’s design combines these principles through its data structures, server architecture, and checkout protocol.

Data structures

Scion’s unit of work is a changeset, an entry in a write-ahead log. A changeset contains much of the information found in a Git commit, but instead of pointing to a complete tree, it stores the files changed relative to its first parent, along with content-addressed pointers to compressed file contents in blob storage.

Changesets are created on the server and become available throughout the system immediately.

This structure supports high-throughput changeset creation because Scion does not need to accept packfiles, acquire locks, coordinate across servers, or move refs. Scion supports refs, but creating and fetching commits does not depend on them. Moving a ref is a compare-and-swap operation on a single Spanner row performed independently of changeset creation.

A changeset alone cannot efficiently answer questions such as who last edited a line or which commits affected a file. Scion therefore builds additional structures from changesets, including dedicated structures for file blame and path history, as well as skip lists for the commit graph.

Anthropic calls information that is not directly part of a changeset derived data. A generic mechanism computes derived data recursively, with each changeset’s value based on the values for its parents.

This approach has three advantages:

1. New derived data types can be added when they improve an operation.
2. Each type can be computed eagerly or deferred, avoiding unnecessary materialization.
3. The client does not depend on the internal representation, allowing the structures to be optimized without changing the client.

Anthropic has added derived data types as Scion has expanded, including indices for copy detection and path-based file search.

Scaling Scion

A small fleet of Scion servers provides APIs for operations such as retrieving changesets, computing diffs, finding merge bases, and fetching blobs. Because Scion data is content-addressed, stored data never changes, and any server can cache it without consulting another server.

The servers can therefore scale horizontally with limited coordination. They function primarily as large caches that can compute derived data when needed and write the results to Spanner.

Scion’s consumers no longer need to maintain local repositories. Previously, CI jobs and tools that needed to ask questions about commit ancestry or blame had to fetch and maintain repositories, creating a substantial maintenance burden.

During the early migration, before Anthropic had its own client, repository format, and protocols, Scion handled only metadata queries. Fetching file contents and materializing working copies required a separate design because those operations transfer much more data.

Scion’s scn client differs from Git’s fetch protocols in several ways. Its negotiation does not tell the server which objects the client already has. Instead, it operates only on trees and blobs that the client requests.

Starting with a root tree, the client checks its local store for missing trees and requests them recursively. It then repeats the process for blobs. Each request targets a specific immutable object, allowing any cache to answer it. The architecture resembles a tiered caching system.

The process is efficient and resumable because it does not produce a single multi-gigabyte packfile response. Sparse and virtualized checkouts require no special protocol support: the client simply does not request trees it does not need.

Within Anthropic’s fleet, the client communicates over a socket with scion-daemon, which stores objects for an entire node. Most nodes need access to the monorepo, and jobs on the same node can reuse many objects.

Each daemon starts from a periodically refreshed snapshot and then communicates only with regional tree and blob cache servers called scion-cache. These cache servers stream objects directly from memory in the disk format consumed by the daemon. They do not need to calculate missing objects for the client or perform delta compression.

When a cache lacks an object, it requests it from the authoritative scion-servers, which read from Spanner or cloud storage as needed.

scion-daemon, scion-cache, and scion-server respond to the same RPCs, so the client does not need to understand the cache topology. Although any tier could theoretically communicate with another, Anthropic enforces the tier structure to isolate failure domains. This prevents a regional cache failure from overwhelming upstream servers and affecting the whole system.

Each tier achieves a cache hit rate above 99 percent and does not require long-lived state, making it straightforward to scale. Anthropic reports that Scion’s infrastructure footprint is now 200 times smaller than its previous Git mirroring infrastructure in CPU and memory requirements.

CI and research jobs check out code two orders of magnitude faster, completing in seconds rather than minutes. CI alone achieved a 25 percent reduction in CPU capacity requirements. Clients and caches also do not need repository maintenance, simplifying job lifecycle management.

Lessons from building Scion

Anthropic began building Scion around the time Claude Mythos Preview and Claude Tag became available internally. The company says both releases increased the need for Scion and accelerated its development.

One example involved the Git-to-Scion ingestion pipeline. Anthropic engineers had largely handwritten an initial prototype. After receiving an early internal snapshot of Claude Mythos Preview, they asked Claude to rewrite the complete pipeline. According to Anthropic, the resulting version used 20 times less memory and ran four times faster while preserving implicit invariants related to ingestion order and data structures.

The company identifies several broader lessons.

Small teams can develop and migrate systems quickly

A team of seven people built Scion and Antique, along with approximately half a dozen related systems, and completed the migration in five months. During that period, the number of daily merged changes increased tenfold.

Anthropic contrasts this with earlier expectations that developing and deploying a source control system would require years of iterative migration and a much larger engineering organization.

Engineering responsibilities are changing

The engineers working on Scion now rate Claude as better than they are at writing code. They still provide the high-level understanding of system components, make design tradeoffs, define the problems to solve, and determine the required scale.

In many cases, engineers had to reject approaches that violated core system constraints. During the migration, some systems attempted to determine when a change merged into the main branch by reading the commit log linearly instead of querying the code review system.

Anthropic also uses adversarial review. While useful, this approach can focus too narrowly on hypothetical concerns. Engineers sometimes had to steer Claude away from overengineering, such as adding excessive validation and complexity around trust in another internal service.

Team members continue to review every change request, but they focus more on the intent of each change than on reading every line of code.

Optimization and testing can improve substantially

Claude’s ability to produce large amounts of code quickly allowed Anthropic to build extensive tests and defenses into Scion. The team created hermetic simulations for every non-trivial infrastructure and source control interaction it had encountered, along with fuzzing and sophisticated rate limiting.

Claude also identified significant optimizations. One example was an algorithmic improvement to ancestry queries that had overlooked one of Anthropic’s indexes. The company says this type of analysis could have taken an expert days or weeks, and Claude repeated similar optimization work the following day.

Monorepo security can support more granular controls

Anthropic designed Scion with safety, security, and compliance requirements in mind. It supports access control for repositories and permissions on individual directories, allowing sensitive code to be protected without giving up the advantages of a monorepo.

The associated code review tooling can express semantic approval constraints. This makes it possible to distinguish comment-only changes from changes that affect sensitive logic, allowing human reviewers to focus on the most consequential modifications.

Operational monitoring can become more continuous

Anthropic uses Claude Tag to monitor individual system components. The company created Slack channels where Claude is assigned to focus on the health of a particular component. These instances are called “superfans,” including a scion-daemon superfan, a scion-cache superfan, and an Antique merge queue superfan.

The agents have access to telemetry and logs and look for unusual behavior. Anthropic still uses conventional alerts, but says the superfans can detect subtle or novel issues that traditional alerts may not identify.

Development assumptions need to be reconsidered

The project led Anthropic to reassess workflows designed for human-scale development. A conventional merge queue, for example, may not be suitable when hundreds or thousands of changes can merge while tests are still running.

Anthropic was unable to reproduce the industry-standard global repository lock for its merge queue. Instead, it invested in automated testing after merges and before deployment. Concurrent changes can still conflict, but Claude can often resolve those conflicts faster than people can identify them.

Implications for the wider ecosystem

Anthropic presents Scion as one possible response to the scaling pressures created by increasingly capable AI agents. The company does not describe it as a universal solution.

Scion is not intended to replace Git for general use. Its design is aimed at extremely large monorepos, including environments with tens of thousands of engineers or large numbers of agents producing code continuously. Anthropic also notes that its willingness to spend tokens for internal development is unusual among businesses.

Making Scion broadly available would be difficult. It differs substantially from Git, so organizations would need to migrate other parts of their development lifecycle as well. Scion also requires compatible code review, code search, and CI systems. Anthropic’s internal versions of those components are highly customized and would be difficult for other organizations to adopt directly.

Anthropic expects similar problems to become more common over the next six to 12 months. Rather than suggesting that every organization build a separate source control system, it proposes that its experience could inform improvements to Git-based infrastructure.

A Git server does not need to operate like a Git client. New server architectures could provide significant scaling improvements. Git platforms could offer comprehensive server-side RPCs similar to Scion, potentially through standardized interfaces that clients could use directly. The negotiation protocol could also evolve, and Git’s sparse and shallow features could be made to work together more effectively.

The Git community has spent nearly two decades scaling the platform for millions of developers. Anthropic’s contribution is narrower: describing how agentic software development interacts with source control systems and sharing design ideas for the changing software development lifecycle.