On October 13, 2026, Anthropic published an account on its official engineering blog of how and why it moved its internal source control system from Git to its own in-house system, Scion, along with the technical design behind it. The company says it migrated its monorepo, which manages multiple projects in a single repository, in just five months.
The number of code changes merged into the main branch jumped from an average of about 2,500 per day in May to more than 30,000 in September. As AI agents accelerated code generation, the existing development infrastructure for fetching source code, building, and testing could no longer keep up with the volume.
Rather than simply speeding up Git, Anthropic redesigned source control itself around the assumption of large volumes of development work done by always-connected AI agents. The company says it reworked the entire development process, from how changes are recorded to how files are delivered, how code is integrated, and how quality is verified.
25 million code fetches a day pushed Git infrastructure to its limit
Anthropic's main branch, "main," had grown to nearly 100 GB in Git history data alone, and the compressed working files exceeded 25 GB.
In addition, continuous integration (CI) was fetching source code about 25 million times a day. That figure does not include fetches from developers' local environments, AI agent execution environments, or research jobs.
Fetching such a huge repository so many times put heavy strain on the development infrastructure.
According to Anthropic, if all the data had been fetched in full each time, traffic would have exceeded 600 PB (petabytes) per day. However, this is a theoretical figure that assumes full fetches; that much traffic was not actually generated.
The company was already using shallow clones, which limit the history that is fetched, and mechanisms for fetching only the necessary data.
At peak times it ran hundreds of internal Git mirrors to distribute access. It had also introduced a method of storing repository snapshots in cloud storage and fetching code starting from them.
But as code changes grew rapidly, snapshot updates could not keep pace, and the gap from the latest main branch kept widening.
Git is fundamentally a distributed version control system in which each developer holds a repository locally and can review history and record changes. Being able to keep working without a network connection is one of Git's major advantages.
In Anthropic's development environment, by contrast, the authoritative home of the source code had effectively become a single location, and most users were always-connected AI agents and automated jobs.
Git's design, in which each client holds rich history data and processes changes on its own, no longer matched how the company actually used it.
That said, Git does not necessarily copy an entire repository.
Git provides partial clone, which fetches necessary objects later, and sparse checkout, which limits the files expanded into the working directory.
Anthropic developed Scion because processing load kept growing even with these existing optimizations. The company therefore decided to fundamentally rethink the division of roles between client and server.
Scion handles everything from recording changes to computing history on the server side
Scion records code changes in units called changesets.
A Git commit references a tree representing the file structure at that point in time. A Scion changeset, in contrast, stores a list of the files changed from its parent changeset, along with references to the compressed file contents.
This does not mean that only the changed lines within a file are stored as diffs. By centering the recorded information on changed files, the design reduces the processing load of creating a new changeset.
Scion also creates changesets on the server side. This removes the need to create a commit locally and then send it to a remote repository, as Git requires.
A list of changed files alone, however, cannot efficiently answer questions such as "who last changed this line?" or "how has this file changed over time?"
Scion therefore generates "derived data," such as indexes for history search, on the server side from the changesets.
Derived data can be computed in advance or at the time it is needed, depending on the use. Adding a new index requires no changes on the client side.
This mechanism also makes automated processes that use history more efficient.
For example, jobs that look for the change that caused a bug or revert a particular change do not need to keep the entire repository locally. They can get the information they need simply by querying the server through an API.
Scion also handles diff calculation, merges, and rebases on the server side. Clients manage a capacity-limited cache and working files, leaving heavy processing to the server.
Updates to shared reference information, such as branches and tags, are also kept to a minimum.
Branches and tags have not been abolished. References that need to be shared, such as main and release branches, still exist.
Updates to these are separated from changeset creation: a single row stored in Google Cloud's distributed database Spanner is updated after confirming that its current value is what was expected.
This reduces the coordination needed when creating changesets while maintaining the consistency of shared information.
A three-tier cache that fetches only the files you need
Scion also changed how files are fetched.
With conventional Git, the server may build a pack file for transfer while taking into account the data the client already holds.
In Scion, the client specifies the trees and file contents it needs, and the server returns the requested objects.
Each piece of data is managed by a content-based identifier, and once stored, its content never changes. That means there is no need to repeatedly check whether cached data has been updated, which makes it easier to keep delivery load low.
Data delivery uses the following three-tier structure:
- scion-daemon: a cache shared by multiple jobs running on the same compute node
- scion-cache: a cache used within the same region
- scion-server: the server that manages the authoritative source code
According to Anthropic, the cache hit rate at each tier exceeds 99%.
In addition to fetching only the directories needed, Scion can defer fetching file contents until the files are actually read.
Furthermore, processes that only search history do not need to fetch working files at all.
The effects of these changes are significant.
Anthropic says the CPU and memory required fell to about one-two-hundredth of what the previous Git mirror infrastructure needed.
Source code fetch times for CI and research jobs also dropped from minutes to seconds, a speedup of about two orders of magnitude. CI as a whole also saw a 25% reduction in CPU capacity, the company says.
These figures, however, were measured under Anthropic's own development environment and load conditions, and they do not mean the company's overall development costs fell to one-two-hundredth.
Consolidating processing on the server side also creates a risk that failures spread more widely.
Scion clearly separates each cache tier and is designed so that, even if a failure occurs within a region, access does not concentrate on upstream servers and overload them.
How Scion differs from Google's and Meta's source control systems
The idea of reducing the data clients hold in order to manage huge monorepos efficiently is not new in itself.
In a technical paper published in 2016, Google introduced Piper, which manages its huge monorepo, and CitC, which treats working state in the cloud as a file system.
With CitC, code can be viewed and edited without copying and syncing the entire repository to a local environment. Only the files a developer has changed are stored in their workspace.
Systems that avoid keeping the entire repository on every machine were already in practical use before AI agents began generating code in large volumes.
Meta's Sapling, released in 2022, likewise fetches needed history and files on demand.
In specialized configurations it also uses a virtual file system, while retaining a design that allows the offline work developers commonly do, such as committing on the client.
Anthropic itself cites Piper and Sapling as predecessors to Scion.
The main differences among the systems can be summarized as follows.
| System | How it reduces locally held data | How changes and history are processed |
|---|---|---|
| Git (official spec) | Partial clone defers data fetching; sparse checkout limits the files expanded | The client manages the repository and fetches missing data from the server |
| Google Piper/CitC (2016) | References a cloud workspace and stores only changed files | Combines centralized Piper with CitC, which provides the cloud workspace |
| Meta Sapling (2022) | Lazy fetching of history and files, plus a virtual file system | Clients can commit, and caches and indexes support some offline work |
| Anthropic Scion (2026) | Fetches only the needed objects from a multi-tier cache and supports processes that can be completed with APIs alone | Changeset creation, merges, history search, and more are processed on the server side |
This comparison organizes data-fetching methods and the division of processing based on Git's official specification and technical materials published by Google, Meta, and Anthropic. It is not a direct comparison of the systems' speed or performance. Nor are all of Sapling's optimizations for large-scale environments available to Git-connected clients.
Scion's defining feature is that it assumes clients are always connected to the network and greatly reduces the processing run locally.
Mechanisms for fetching only the necessary files exist in earlier technologies, but Scion goes further, moving even changeset creation, the equivalent of a commit, and merging to the server side.
As a result, clients are lightweight and a huge number of AI agents can work at the same time more easily.
On the other hand, creating changes and processing history require a connection to the server. While local processing load is reduced, dependence on the network and server grows, which is a trade-off.
Emphasis on post-merge testing and AI-driven repair
The challenge in adopting Scion was not only the speed of fetching source code. The mechanisms for safely integrating large numbers of code changes and maintaining quality also had to be rethought.
According to Anthropic, while tests run for a given change, hundreds to thousands of other changes can be merged into the main branch.
In such an environment, it was difficult to operate a conventional merge queue, which verifies and merges changes in sequence, in a way that delivered enough benefit.
The company therefore adopted an approach of strengthening the automated tests run after code is merged and before it is deployed to production.
When changes developed in parallel conflict with one another, Claude is used to fix them.
A typical merge queue checks not only whether a change passes tests on its own, but also whether it works correctly in combination with other changes.
For example, GitHub's official documentation on merge queues describes a mechanism that runs required checks on the latest state of the target branch combined with the preceding changes in the queue and the new change.
This is because code changes that work correctly on their own can still cause defects when applied together.
That, however, describes the specification of GitHub's merge queue, which is not identical to that of Git itself or of the development environment Anthropic previously used.
Even if Scion speeds up code fetching and change integration, it does not eliminate the problems that arise when multiple changes are combined.
Anthropic's new approach can be seen as shifting emphasis from rigorously verifying combinations of changes before integration to strengthening the ability to detect problems after integration and fix them quickly.
The company does not, however, say it has abolished all pre-merge testing.
Anthropic says Claude can resolve code conflicts faster than humans. But repair speed alone cannot be used to judge the quality of a development infrastructure.
What matters is how long a broken state persists, whether problems can be detected before deployment to production, and how quickly problematic changes can be reverted or repaired.
The announcement gives no specific figures for these metrics.
Being able to process tens of thousands of changes a day and being able to safely release them to production need to be evaluated separately.
A team of just seven built the migration in five months
According to Anthropic, the team that built Scion, the new code review system "Antique," and related development infrastructure, and completed the full migration in five months, consisted of just seven people.
The team made extensive use of Claude in development, speeding up implementation and expanding verification such as simulation and fuzzing.
Fuzzing is a testing technique that feeds a program a wide variety of input data to uncover unexpected behavior and bugs.
Even so, the ability of AI to generate large amounts of code has not removed the need for design judgment by human engineers.
Anthropic says that during development it also found that Claude does not always choose an appropriate design.
For example, in one case where it would have sufficed to query the code review system to find when a given change was merged into the main branch, Claude generated an implementation that kept reading through the repository history one entry at a time.
Strict code review by AI systems also sometimes produced excessive verification and unnecessary complexity.
The company says checks were added excessively even for trusted internal services, making the overall system more complicated than necessary.
To address such problems, human engineers decided which service should handle which process and what constraints the system must uphold, and instructed Claude to make fixes.
The team still has humans review every change request to Scion and related systems. However, the emphasis is on whether a change's purpose and design intent are sound rather than on checking code line by line.
While delegating much of the implementation and verification to AI, the team keeps humans responsible for architectural consistency and technical judgment.
Stronger access control for a huge monorepo
In operating a huge monorepo, access permissions to source code are also important.
Scion lets permissions be set per directory, controlling the scope that each user can view and modify.
The code review system can also distinguish minor changes, such as fixing a comment, from changes to highly sensitive logic, and set approval requirements for each.
Even in an environment where AI agents routinely generate and merge large volumes of code changes, mechanisms for managing who can access which code and which changes require human approval remain in place.
Most companies can't simply adopt Scion as is
The fact that Anthropic could roll out Scion in a short time owes much to its distinctive development environment and abundant AI computing resources.
Anthropic itself acknowledges that the volume of AI model tokens available to it internally far exceeds what ordinary companies would realistically want to pay for.
Scion is also not a standalone product that can replace Git on its own.
It assumes integration with a dedicated code review system, code search infrastructure, CI, and more, so adopting it would require migrating the entire development process.
For that reason, the company says it would not be appropriate to offer Scion as a general-purpose Git alternative, and that releasing it externally in a widely usable form would also be difficult.
That said, the design contains ideas that can be applied to existing Git environments.
What Anthropic says it particularly wants to share with the Git community are the APIs that handle history and change queries on the server side, and mechanisms for efficiently fetching only the necessary data.
As AI agents spread and code generation grows, companies that continue to use Git may also face rising load from repository fetches, history searches, and merge processing.
Designs that move part of this processing to the server side and use caches to reduce data transfer can serve as a reference for improving existing source control systems.
However, anyone increasing reliance on servers will need to consider whether development can continue during outages and how much work can be done in environments without network access.
Anthropic's Scion stands as an example of how conventional source control systems might be rethought in an era when AI agents generate code in large volumes.
If server-side processing and efficient data-fetching mechanisms are brought into existing Git environments, it may become possible to cope with the development load that AI is rapidly increasing without fully migrating to a dedicated system like Scion.