Anthropic Builds Scion Version Control System to Handle AI Agent Scale, Migrating from Git in Five Months

AI Writes Code Too Fast, Git Can't Keep Up: Why Anthropic Built Scion Video 1: English Version Video 2: Chinese Version

This year, GitHub has been experiencing outages every few days. In its own availability reports, GitHub noted that traffic is growing rapidly, with a significant portion driven by AI: AI assists humans in writing code, and AI agents are submitting changes on their own. They more than doubled their effective capacity over four months, yet still struggled to keep up.

Anthropic’s own codebase presents an even more extreme case: In May of this year, they merged approximately 2,500 changes per day on average. By September, that number exceeded 30,000 per day—a tenfold increase.

Git, used by programmers worldwide, can no longer handle the load. Consequently, Anthropic built their own version control system called Scion, migrating their entire codebase from git in just five months. Why can’t git handle it? What exactly did Scion change?

What Does Git Do?

You can think of git as a shared folder equipped with a time machine. Every change is saved as a version, known as a commit. You can track who changed which line and when, and if something breaks, you can revert to a previous state.

GitHub is essentially the world’s largest website for hosting git repositories.

Many large companies store the code for all their projects in a single massive repository, known as a monorepo. This is the approach Anthropic uses.

A Whole Library for Each Person

Git has a specific characteristic: everyone receives a complete copy of the repository, including its entire history. To use an analogy, it’s like borrowing a book but also photocopying and moving the entire library home. The benefit is that you can browse history and check records even when offline.

When the repository is small, this isn’t an issue. However, Anthropic’s repository has nearly 100 GB of history on the main branch alone, and even a compressed working copy exceeds 25 GB.

Too Heavy to Move

Consider how often these copies need to be moved. Just for automated builds and tests (CI), the code needs to be checked out onto machines approximately 25 million times per day. This doesn’t even account for development environments, AI agent sandboxes, or research tasks. If every instance required pulling the full repository, daily traffic would exceed 600 PB. To put that in perspective, that’s equivalent to roughly 600,000 1 TB hard drives.

The Original Patchwork Architecture: Layered Caching

They tried various solutions, including shallow clones and sparse checkout features that only pull parts of the repository. The original architecture relied on layered caching: When a machine needed code, it first checked the local packfile cache; if missing, it queried mirror replicas; those mirrors then queried the primary mirror, finally reaching the upstream repository. Each cluster had its own set. When new machines started up, they would first copy a snapshot of the repository from cloud storage to avoid pulling from scratch.

At peak times, hundreds of git mirror servers were running simultaneously. But as changes accumulated, snapshots quickly became outdated, making the mirrors increasingly difficult to maintain.

Reframing the Problem

Eventually, they realized that git’s capabilities designed for offline work were rarely utilized in their environment.

Here, "online" doesn’t refer to general internet access, but rather constant connectivity to the company’s code servers. If you take your laptop on a plane without internet and want to write code or browse history, git’s "full copy per person" model is useful. However, at Anthropic, most code consumers are AI agents and background tasks running on company infrastructure, which always have network connectivity to the code servers.

So they reframed the question: If we assume from the start that users are always online and connected to the server, what should code management look like?

Fetch Only What You Need

The answer was: Stop moving libraries; switch to checking out books from the front desk.

Scion’s client does not store the entire repository, maintaining only a limited-capacity local cache. It fetches specific directories or files from the server only when needed. Heavy operations like querying history, identifying who wrote a specific line, merging, and rebasing are handled entirely by the server. These query capabilities are exposed via APIs, allowing many tasks to interact directly with the server without pulling any code.

Commits Happen on the Server

In git, you commit locally on your computer and then push to others. In Scion, commits occur directly on the server. Once committed, the changes are immediately visible to everyone, eliminating the "push" step entirely.

Each commit only records which files were modified in that instance, acting like a manifest of changes rather than rewriting the entire directory tree. Each file in the manifest is referenced by a unique ID, while the actual content is stored in cloud storage, with identical content stored only once. Therefore, regardless of the repository size, the cost of a commit depends solely on the amount of data changed in that specific commit.

Layered Branch Libraries

Can the server handle so many machines requesting data simultaneously? It relies on layered caching: Each machine runs a "concierge" service called scion-daemon, each region has a "branch library" called scion-cache, and finally, there is the "main library," scion-server, backed by a database and cloud storage.

Every file is assigned an ID based on its content hash, meaning once stored, it never changes. This allows any layer to safely cache data without needing to verify consistency with other layers. As a result, cache hit rates at every layer exceed 99%, resolving the vast majority of requests locally.

Scion’s Overall Architecture Diagram

Putting these components together yields the Scion architecture shown in the original article’s diagram. Requests follow two paths:

One path is "inquiries" (Control Plane): Querying history, viewing diffs, and committing changes. All clients, including the code review tool Antique, developer laptops, and tasks within clusters, communicate directly with the main server, scion-server.

The other path is "retrieval" (Data Plane): Directory structures and file contents go through the cache. Developer laptops query the regional scion-cache directly; tasks within clusters first query the local scion-daemon, and if there’s a miss, they traverse upward through the layers.

Behind the main server, commit records, branches, and directory structures are stored in Spanner databases, while file contents reside in cloud storage. When new machines come online, the daemon first copies a periodic snapshot to avoid pulling from scratch.

Results

The entire infrastructure consumes 200 times less CPU and memory compared to the original git mirror cluster. Pulling code for testing and research tasks dropped from minutes to seconds, saving 25% of CPU resources for CI alone. The original article’s diagram includes another set of metrics: The median time for an AI agent to create a new workspace dropped from 7.1 minutes to 5.1 seconds—an 84x speedup.

How many people are needed to build such a large system?

A team of seven completed Scion and its accompanying code review tool, Antique, in five months. They also built five or six peripheral systems and migrated the entire repository during this period. Moreover, the volume of daily merged changes increased tenfold during this time. In the past, migrations of this scale typically required much larger teams and took several years.

One example: their hand-written first version of a data import program was handed to an early internal build of Claude (an early snapshot of the Claude Mythos Preview) for rewriting. With no additional requirements specified, the new version reduced memory usage by 20x and increased speed by 4x, while preserving all original constraints.

If AI is this good at writing code, what do engineers do?

The participating engineers acknowledged that when it comes to writing code alone, Claude is already better than they are. But the nature of engineering work has changed: understanding how systems interact, weighing architectural trade-offs, and making decisions based on the problem at hand and expected scale. Often, their job is to say "no" to Claude.

For instance, several systems wanted to scan commit logs line-by-line to find when a specific change was merged into the main branch—when they could simply query the code review tool directly. Team members still review every change, but now they focus on the intent behind the modifications rather than reading code line-by-line.

Should everyone ditch git?

No. Anthropic itself states that Scion is not a general-purpose replacement for git; it is only necessary for extremely large monorepos—those backed either by tens of thousands of engineers or swarms of tireless coding agents.

The differences from git are so significant that adopting it requires rebuilding the entire toolchain, including code review, code search, and CI. Therefore, they have no plans to make it a general product. Instead, they hope these ideas will be adopted within the git ecosystem: servers doing more heavy lifting, providing richer query interfaces, and clients fetching data on demand. They predict that scaling challenges like these will become increasingly common in the industry over the next 6 to 12 months.

Remember three key points:

First, git gives everyone a full copy of the repository. When AI increases the volume of changes by more than tenfold, this model becomes unmanageable.

Second, Scion assumes users are always online and connected to the server: fetch what you need, offload heavy tasks to the server, and rely on multi-layered caching as a fallback.

Third, the faster AI writes code, the more bottlenecks shift elsewhere: source control, builds, and testing must all be redesigned for AI-scale operations.

Previously, everyone carried home an entire library; now, there’s a branch library downstairs—you borrow just the page you need.

Source: Anthropic Engineering Blog, Redesigning Source Control at Anthropic (October 2026), https://t.co/XAdWVi4gWe

↳ Quoting @AnthropicAI (Anthropic): New on our Engineering blog: Creating in-house source control.

In May, we merged around 2,500 code changes per day. In September, we merged more than 30,000 per day. As a result, we became bottlenecked by developer infrastructure built for human (rather than agent) scale.

Here, we share how we built a new version control system—and fully migrated our monorepo from git—in five months: