Anthropic Replaces Git with AI-Built Scion in Five Months: Redefining Code Infrastructure

Git, which has dominated programmers for 20 years, is being shaken by AI.

Jiqi Zhixin Editorial Team

Git, the version control tool that has reigned supreme among developers for two decades, has been replaced by a new system built by Anthropic itself.

And only seven engineers, with deep involvement from Claude, accomplished this feat.

In five months, Anthropic developed its internal source code control system Scion, along with the accompanying code review tool Antique and several other related systems, completing the migration of its entire monorepo from Git to Scion.

What does this mean? A few people, leveraging AI, built a new system in just months and directly replaced the long-used Git within their own company. It’s simply astonishing! This inevitably led some to exclaim "RIP GIT."

Why build a Git alternative from scratch?

The reason is simple: the scale of Anthropic's AI-driven programming had grown so large that its existing development infrastructure could barely cope.

According to data provided by Anthropic, in May of this year, they merged approximately 2,500 code changes per day on average. By September, this number had surpassed 30,000, representing a more than 12-fold increase in just four months. Moreover, Anthropic expects this growth to continue without slowing down in the short term. The potential demand for code merges appears virtually unlimited; every time a bottleneck is resolved, code output increases further.

Driven by these real-world pressures, Anthropic developed an internal version control system and completed the full migration of its Monorepo from Git to Scion within five months.

Anthropic recently detailed the entire process in a blog post.

I. The Ever-Expanding Monorepo

Before introducing Scion, it is necessary to explain how unique Anthropic's workload is. Their use of Claude for software development far exceeds that of most companies. This highlights where tools designed for human-scale development begin to struggle. Source code control is just one example.

Anthropic anticipates that not many companies will face the same issues in the short term. However, as AI programming tools become increasingly widespread, other companies should encounter similar bottlenecks soon enough. This is why we decided to share our experience with the design and development of Scion.

Git is a decentralized system. Each clone results in a complete, independent copy of the repository. Even when completely offline, developers can compute diffs, view commit history, track modifications to specific lines of code, and check out any version. For the vast majority of repositories, this design makes perfect sense and is a key reason why Git became the industry standard.

However, as Anthropic's Monorepo continued to grow, Git's design increasingly failed to meet their needs. Currently, the historical data for the main branch alone approaches 100GB, and the compressed working copy exceeds 25GB. The CI system alone performs approximately 25 million code checkouts daily, not including development environments, agent sandboxes, and research tasks. If each checkout required fetching data directly from Git, the daily data transfer volume would exceed 600PB.

Git also provides features for handling partial repository data, such as shallow clones, sparse checkouts, and promisor remotes. The industry has common approaches for managing large monorepos, including setting up internal Git mirrors or storing code repository snapshots in object storage.

Anthropic used all of these methods. At peak load, they even ran hundreds of internal Git mirror servers. These solutions did help sustain operations for a while. However, as the volume of code merges grew, they became increasingly difficult to maintain. The gap between snapshots and the latest version of the main branch widened with each refresh interval. Additionally, maintaining the ability for partially cloned repositories to perform history-dependent operations like diff and blame required ever-increasing maintenance efforts.

Typical architecture for scaling Git checkout capabilities.

Later, Anthropic re-evaluated their usage patterns and identified a fundamental issue. Like most companies, Anthropic had been using Git as a centralized system, with all development work revolving around a single authoritative repository. Yet, the clients were almost exclusively agents and automated tasks, which are inherently always online. The features Git provides for distributed and offline development actually constrained the system's scalability as the repository grew.

This led Anthropic to ask: What would a source control system look like if it were designed from the ground up assuming that agents are always online?

II. Source Control at Agent Scale

As agents begin writing code at scale, many traditional assumptions in software development are shifting. In designing Scion, Anthropic accounted for these changes, adopting different approaches from Git on several core principles. Of course, source control for ultra-large monorepos is not without precedent. Google’s Piper and Meta’s Sapling have accumulated extensive experience, and Anthropic referenced these practices during Scion’s development.

Scion primarily adheres to the following design principles.

1. Clients are always online.

   Git assumes clients need to work offline, requiring them to keep a full local copy of the repository. Since Anthropic’s clients are almost entirely agents and automated tasks, Scion’s client and communication protocol were designed around an always-accessible server. Clients fetch only the data they need from the server.

2. Clients and servers have distinct responsibilities.

   In Git, every client has the capability to act as a full Git server. Scion offloads most work to the server, including querying file history and blame information, creating commits, and performing merges and rebases. Clients are responsible only for maintaining a size-limited local object cache, writing files from the working copy to disk, monitoring filesystem changes, and providing a user-friendly interface. Because clients rarely perform complex computations locally, they store significantly less data.

3. A complete source control service enables more new applications.

   In Git, if CI jobs or other tools want to query repository information—such as who last modified a specific line of code or the relationship between two commits—they typically need to maintain a local repository. Alternatively, they can rely on APIs provided by specific hosting services, but these APIs may not answer all questions. Scion exposes all source control queries used by clients as APIs. This allows many tasks to perform queries directly without needing a local repository.

   Examples include Anthropic’s internal automated bisecting and code rollback pipelines. Without low-cost, programmatically accessible source control capabilities, these tools would be difficult to operate at their current scale.

4. All components must support horizontal scaling.

   Previously, Anthropic ran up to hundreds of Git mirror servers, consuming substantial compute resources. Moreover, once the repository size exceeded the disk or memory capacity of a single mirror server, further scaling became extremely difficult.

   Scion distributes repository data across storage, allowing each component to scale independently. There is no fully materialized copy of the repository anywhere in the system, nor on any server. Scion also lacks a mechanism equivalent to Git packfiles (compressed object bundles), eliminating the need for associated repository maintenance operations.

5. Commits must be lightweight, incrementally processable, and lock-free.

   In Git, developers commit code locally first, then share changes via push. In Scion, all commit, rebase, and merge operations occur on the server side, so there is no push. Consequently, the server must handle these operations quickly. The cost of creating a commit and updating related data structures must be proportional to the size of the code change, rather than growing with the total repository size. Otherwise, the server will eventually fail to keep up with the commit rate.

   Scion’s development workflow also minimizes the use of refs. Refs are references pointing to commits, such as branches and tags; typically, only essential refs like the main branch or release branches are retained. Global data requiring consistent state across all servers is likely to become a scaling bottleneck in the future.

6. Working copies can be omitted; checkouts fetch only necessary data by default.

   Anthropic’s monorepo is exceptionally large.

With these design principles in mind, let’s examine how Scion implements them. These lessons can be applied to other version control systems and may also benefit other aspects of the software development lifecycle.

Data Structures

In Scion, the fundamental unit of work is called a Changeset, which is a record in a Write-Ahead Log (WAL).

A Changeset stores most of the common information found in a Git commit, but the data organization differs. While a Git commit stores a pointer to a directory tree, a Changeset stores a list of files that have changed relative to its first parent commit, along with content-addressed pointers to compressed file contents in object storage. Changesets are created on the server side and become immediately accessible from anywhere in the system upon creation.

The data structure of a Changeset in Scion.

This structure allows Scion to ingest changes at extremely high throughput. It eliminates the need to receive packfiles, perform locking or cross-server coordination, or move refs. Strictly speaking, Scion still supports refs. However, creating and fetching commits do not depend on refs, so moving a ref only requires a single Compare-and-Swap (CAS) operation on a row in Spanner, and this operation is decoupled from Changeset creation.

However, Changesets only record what has changed. Relying solely on these records makes it difficult to quickly answer questions like who last modified a specific line of code or which commits a particular file has passed through. To address this, Scion builds additional data structures based on Changesets, including specialized structures for querying blame and file path history, as well as skip lists to accelerate commit graph queries.

Anthropic collectively refers to data that does not directly belong to a Changeset as Derived Data. All derived data is computed using a unified mechanism. Each type of derived data is defined recursively: the derived data for a given Changeset can be calculated from the corresponding data of its parent Changeset.

This mechanism offers three key benefits:

• First, if an operation can be accelerated by a new data structure, it is easy to add a new type of derived data.
• Second, each type of derived data can independently decide whether to compute eagerly or lazily (on demand), avoiding the generation of unused data.
• Third, clients do not need to understand the internal implementation of these data structures, allowing server-side optimizations without requiring client modifications.

As Scion has evolved, Anthropic has added several new types of derived data, such as indices for detecting file copies and searching files by path.

Scaling Scion

A small cluster of Scion servers provides various source control APIs to clients, including fetching Changesets, computing diffs, finding merge bases, and retrieving Blobs. All source code data is content-addressed, meaning once written, the content never changes. Any server can cache this data without needing to coordinate with other servers.

Consequently, Scion servers scale horizontally with minimal inter-server coordination. These servers essentially function as large caches that also compute derived data on demand and write the results back to Spanner.

Numerous internal tools using Scion no longer need to maintain local repositories. Previously, if CI jobs or other tools needed to query commit ancestry or track code modification history, they had to fetch and maintain a repository, imposing significant maintenance overhead. In fact, during the early stages of migration—before we had our own client, repository format, and communication protocol—Scion could only answer these metadata queries. Fetching file contents and generating working copies on disk required transferring much larger amounts of data, so we designed a separate solution for those capabilities.

The scn client in Scion differs significantly from Git in its data retrieval protocol, enabling an architecture with better scalability and lower CPU overhead compared to Git servers. When negotiating data retrieval, Scion does not ask the client to inform the server about what data it already possesses. Instead, the client directly requests the desired directory trees and Blob objects. Starting from the root directory tree, the client checks its local storage for missing directory tree objects and recursively requests them from the server. After completing the directory tree retrieval, it fetches Blobs using the same method. Since each request targets a specific, immutable object, any cache can serve the response.

The overall architecture closely resembles traditional hierarchical caching systems. This approach is highly efficient and supports resumable downloads because the process does not rely on a single packfile response, which could potentially reach several gigabytes in size. Sparse checkout and virtualized checkout do not require special support; clients simply avoid requesting directory trees they do not need.

Within Anthropic’s compute clusters, clients communicate via sockets with a daemon named scion-daemon. The scion-daemon maintains code objects for the entire compute node. Since most nodes need access to the Monorepo, different tasks on the same node often reuse many identical objects, making centralized cache management by the daemon more efficient. Upon startup, each scion-daemon loads a periodically updated snapshot. Subsequently, it communicates only with directory tree and Blob cache servers within its Region, known as scion-cache.

scion-cache serves objects directly from memory in the exact format that the daemon will eventually write to disk. Therefore, cache servers do not need to calculate which objects the client is missing or perform delta compression. If an object is missing from the cache, scion-cache requests it from the authoritative server, scion-server, which then reads data from Spanner or cloud storage as needed.

scion-daemon, scion-cache, and scion-server all use the same RPC interface, so clients do not need to understand the topology of the entire caching system. Theoretically, any layer can communicate with any other layer. However, Anthropic strictly defines access relationships between layers to isolate failures. For example, if a scion-cache in a specific Region fails, Anthropic does not want a flood of requests to surge directly upstream to scion-server, potentially causing the entire system to collapse.

Scion's code checkout architecture.

Each cache layer in this system achieves a hit rate exceeding 99%, and since it does not require maintaining long-term state, it scales easily on demand. Compared to the previous Git mirror infrastructure, Scion reduced CPU and memory resource usage by a factor of 200. Code checkout speeds for CI and research tasks improved by approximately two orders of magnitude, dropping from several minutes to just seconds. This freed up significant resources across the compute cluster, saving 25% of CPU capacity for the CI system alone. Additionally, neither clients nor cache servers need to perform repository maintenance tasks, simplifying task lifecycle management.

IV. What Did We Learn from Developing Scion?

Anthropic began developing Scion at the same time that Claude Mythos Preview and Claude Tag became available internally. These models both increased our demand for Scion and significantly accelerated development progress.

Here is a representative example. Earlier this year, Anthropic had essentially hand-coded the first prototype of the data import pipeline from Git to Scion. At the time, we considered the program quite good. Later, after obtaining an early internal version of Claude Mythos Preview, we asked Claude to rewrite the entire program without providing any additional instructions. The result was an implementation with 20x lower memory consumption and 4x faster execution speed, while fully preserving all implicit constraints regarding data import order and data structures from the original program.

Weekly merged code changes for the Scion and Antique repositories from January to September 2026.

The experience of developing and running Scion gave Anthropic new insights into software development for large-scale Agents.

Small teams rapidly building large systems will become increasingly common

A team of only seven people developed Scion and the code review tool Antique in five months, built about half a dozen related systems, and completed the full migration to these systems. Antique alone would be enough material for an entire engineering blog post.

Moreover, this entire development and migration process occurred during a period when Anthropic’s daily code merge volume grew tenfold. In the past, developing and deploying such a source control system typically required more engineers, years of iterative refinement, and gradual migration.

Anthropic believes that this kind of rapid, flexible system development and migration will become increasingly common in the future.

Engineers remain important, but their working methods are changing

All engineers involved in this project now agree that Claude’s coding ability surpasses their own. Yet, engineers continue to play an irreplaceable role. Team members understand the holistic relationships between various systems and know what trade-offs different architectural designs entail. Because Anthropic knows exactly what problems they are solving and the scale the system must support, they can make sound design decisions. Often, the engineer’s job is simply to say "no" to Claude.

Agents sometimes violate core system constraints in order to satisfy certain code patterns. This is particularly common during migrations. For example, several systems needed to query when a specific code change was merged into the main branch. Claude attempted to find the answer by linearly scanning the commit log, whereas it could have simply queried our code review tool directly.

Anthropic also heavily adopted adversarial code reviews. While effective in many ways, this approach sometimes over-focuses on local issues. Therefore, experienced engineers must guide Claude promptly to prevent it from overcomplicating system designs to address hypothetical risks. For instance, one review was overly cautious about the trustworthiness of another internal service, leading Claude to add extensive extra validation that unnecessarily complicated the system.

Significant improvements in development efficiency

In addition, Anthropic has incorporated fuzz testing and robust rate-limiting mechanisms. Claude frequently identifies significant performance optimization opportunities with ease. For instance, it once discovered that a commit ancestry query algorithm was missing an existing index, indicating room for optimization. If handled by human experts, such issues might require days or even weeks of analysis and tuning. However, after completing the optimization, Claude can immediately move on to similar tasks the next day.

Actual performance improvements in Scion's native code repository.

Laying New Foundations for Secure Monorepo Management

For massive monorepos, security and compliance are just as critical as capacity and scalability. Anthropic considered these factors from the very beginning of Scion's design. Scion supports rich repository access controls and allows permissions to be set at the individual directory level. This approach protects the most sensitive code while retaining the benefits of a monorepo structure.

Furthermore, the code review tools developed by Anthropic support complex, semantics-based approval constraints. For example, the system can distinguish between simple changes that only modify comments and modifications involving sensitive program logic. This allows human reviewers to focus their attention on high-impact changes.

System Operations Reach a New Level

Anthropic teams extensively use Claude Tag to monitor various system components. For instance, they have created dedicated Slack channels where Claude continuously monitors the health of specific components. Anthropic refers to these Clauses as "Superfans."

Currently, Anthropic has Superfans responsible for scion-daemon, scion-cache, and one specifically focused on the Antique merge queue. These agents have access to system telemetry and logs. They act like experienced engineers with ample time, constantly refreshing monitoring dashboards to look for any signs of anomalies.

Of course, Anthropic still maintains traditional alerts for all systems. However, compared to traditional alerts, which can feel somewhat singular in scope, Superfans are capable of detecting subtle issues that have never occurred before.

Rethinking Past Practices

This project prompted Anthropic to re-evaluate workflows designed for human-scale development. For example, in scenarios involving large-scale programming by Agents, traditional merge queues may no longer make sense. While a set of tests is still running, hundreds or even thousands of code changes might be merged into the repository. In this context, how should CI function?

So far, Anthropic has not been able to effectively replicate the industry-standard approach of managing merge queues via global repository locks. Consequently, Anthropic has invested more effort in automated testing post-merge and pre-deployment. Naturally, this means concurrent code changes may result in conflicts. However, Claude typically resolves these issues before human engineers even notice them.

V. What Does This Mean for the Broader Developer Ecosystem?

Anthropic believes that Scion is only part of the solution to the scalability challenges posed by the ever-increasing capabilities of AI Agents. Sharing these details is intended to inspire other teams to draw insights from our practices.

However, Anthropic does not believe Scion's approach is suitable for every scenario. Scion is absolutely not intended as a general-purpose replacement for Git. The design principles described here primarily apply to truly massive monorepos, such as those used by tens of thousands of engineers or repositories where a large number of Agents continuously generate code.

Additionally, Anthropic operates under a unique condition: it consumes tokens for internal tasks at a scale far exceeding what other companies would realistically bear. This serves both its own software development needs and the testing of Claude's capabilities. Practically speaking, turning Scion into a product widely usable by other companies would also be extremely difficult.

The differences between Scion and Git are substantial. If other companies wish to migrate to Scion, they would need to overhaul every stage of their software development process, including accompanying code review, code search, and CI systems. Anthropic's internal systems are highly customized, making them difficult for other companies to adopt directly.

Anthropic is also concerned that attempting to develop a public version satisfying everyone's needs might result in a product that isn't particularly useful. Nevertheless, Anthropic anticipates that these issues will become increasingly common within the next 6 to 12 months. If every company using Git has to solve similar problems independently, it would clearly waste significant engineering resources.

Therefore, Anthropic believes the most valuable action currently is to share its design philosophy, allowing other developers to apply effective solutions from Scion to Git without completely abandoning Git's existing overall model. For example, Git servers do not necessarily need to work in the same way as Git clients. There are already emerging server architectures that can significantly improve system scalability.

Git hosting platforms could also provide comprehensive server-side RPC interfaces, similar to Scion. These interfaces could even be standardized across different hosting platforms, allowing Git clients to call them directly. Git's current data negotiation protocol does not necessarily need to remain unchanged. Furthermore, existing features like sparse checkout and shallow cloning could be further improved to work better together.

Reference Link:

https://x.com/AnthropicAI/status/2110047081414987957

https://www.anthropic.com/engineering/redesigning-source-control

© THE END

Please contact this official account for authorization to reprint.

For submissions or media inquiries: [email protected]