7个人、5个月！Anthropic造出了Git替代品

7 People, 5 Months! Anthropic Builds a Git Alternative

And the ones who accomplished all of this were only seven engineers and Claude, who was deeply involved in the development.

In five months, Anthropic built from scratch the internal source‑code control system Scion, its companion code‑review tool Antique, and several other related systems, and completed the migration of the entire monolithic codebase from Git to Scion.

What does this mean? A handful of people, leveraging AI, built an entirely new system in just a few months and replaced the Git they had been using internally for years. It’s almost unbelievable! No wonder some people exclaimed, “RIP GIT.”

Why build our own Git alternative?

The reason is simple: Anthropic’s AI programming scale has grown so large that the existing development infrastructure is struggling to keep up.

According to data provided by Anthropic, in May of this year they merged roughly 2,500 code changes per day on average. By September, that number had already surpassed 30,000, an increase of more than 12 times in just four months. Moreover, Anthropic expects this growth will not slow down in the short term. The potential demand for code merges is almost limitless; each time a bottleneck is resolved, code output further increases.

Under real‑world pressure, Anthropic developed an internal version‑control system and migrated the entire monorepo from Git to Scion within five months.

Anthropic fully details the entire process in its latest blog post.

1. The Ever‑Expanding Monorepo

Before introducing Scion, it’s worth explaining how unique Anthropic’s workload is. The extent to which they use Claude to write software far exceeds that of most companies. In particular, the tools designed for human‑scale development start to strain in certain areas. Source code control is just one example.

Anthropic expects that, in the short term, not many companies will face the same issue. However, as AI programming tools become more widespread, other companies are likely to encounter similar bottlenecks soon. This is why we decided to share the design and development experience of Scion.

Git is a decentralized system. Each clone receives a complete, independent repository. Even completely offline, developers can compute diffs, view commit history, trace the modification history of a specific line, and check out any version. For the vast majority of codebases, this design is very sensible and is a key reason Git has become an industry standard.

However, as Anthropic’s monorepo continues to grow, Git’s design is increasingly unable to meet the demands. Currently, just the history of the main branch is approaching 100 GB, and the compressed working copy exceeds 25 GB.The CI system alone performs about 25 million checkouts per day, not counting development environments, agent sandboxes, and research tasks. If each checkout pulls the required data directly from Git, the daily data transfer would exceed 600 PB.

Git also provides features for handling parts of repository data, such as shallow clones, sparse checkout, and Promisor Remote. The industry also has some common approaches for dealing with large monorepos, such as setting up internal Git mirrors or storing repository snapshots in object storage.

Anthropic has used all of these methods. At peak load, we were even running hundreds of internal Git mirror servers. These solutions did help for a while. However, as the volume of code merges continues to grow, they become increasingly difficult to maintain. The gap between a snapshot and the latest version on the main branch widens between snapshot refreshes. At the same time, enabling partially cloned repositories to perform diff, blame, and other operations that depend on historical information requires ever more maintenance effort.

Typical architecture for extending Git’s code checkout capabilities.

Later, Anthropic reexamined its usage and discovered an issue. Like most companies, Anthropic has actually been using Git as a centralized system, with all development work revolving around a single authoritative code repository. But the clients are almost all agents and automated tasks, which are always online. The features that Git provides for distributed and offline development actually limit the system’s scalability as the code repository continues to grow.

Thus, Anthropic began to think: if we design a source code control system from the start with the characteristic that agents are always online, what would it look like?

II. Source Code Control for Agent Scale

As agents begin to write large amounts of code, many traditional assumptions in software development are changing. Anthropic fully considered these shifts when designing Scion, and therefore adopted a different approach from Git on several core principles. Of course, source‑code control for massive monorepos is not without precedent. Google’s Piper and Meta’s Sapling have accumulated extensive experience, and Anthropic also drew on these practices while developing Scion.

Scion primarily follows the following design principles.

1. The client is always online.

Git assumes that the client needs to work offline, so it must keep a complete repository locally. But Anthropic’s clients are almost always agents and automated tasks, so Scion’s client and communication protocol are designed around a constantly reachable server. The client fetches whatever data it needs from the server.

2. The client and server assume different responsibilities.

In Git, each client can act as a full Git server. Scion delegates most of the work to the server, including querying file history and blame information, creating commits, performing merges and rebases, and so on. The client only maintains a size‑limited local object cache, writes files from the working copy to disk, monitors filesystem changes, and provides a user‑friendly interface. The client itself performs almost no complex computation, so it stores far less data locally.

3. A complete source‑code control service can support more new applications.

In Git, if CI jobs or other tools want to query information about the code repository—such as who last modified a particular line of code, or what relationship exists between two commits—they usually need to maintain a local copy of the repository. Another approach is to rely on APIs provided by specific service providers, but those APIs may not answer every question. Scion exposes all source‑code query capabilities used by clients as APIs. This way, many tasks can perform queries directly without needing a local repository.

Anthropic’s internal automated bisection and code‑rollback pipelines are examples. Without this low‑cost, programmatically accessible source‑code access capability, these tools would be hard to run at current scale.

4. All components must support horizontal scaling.

In the past, Anthropic ran up to several hundred Git mirror servers, consuming a large amount of compute resources. Moreover, once a repository’s size exceeded the disk or memory capacity of a single mirror server, further scaling became very difficult.

Scion stores repository data in a distributed manner, allowing each component to scale independently. There is no complete, materialized repository anywhere in the system, nor on any server. Scion also lacks a mechanism corresponding to Git packfiles (compressed object bundles), so repository maintenance operations are unnecessary.

5. Commits must be lightweight enough, support incremental processing, and not require locking.

In Git, developers first commit code locally and then share the changes by pushing. All commits, rebases, and merges in Scion are performed on the server side, so a push is not required. Consequently, the server must be able to process these operations quickly. The cost of creating a commit and updating the related data structures must be proportional to the size of the code change, not to the overall size of the repository. Otherwise, the server will eventually fall behind the commit rate.

Scion’s development workflow also tries to minimize the use of refs. A ref is a reference that points to a commit, such as a branch or a tag, and typically only essential references like the main branch or release branches are kept. Because global data that must be consistently maintained across all servers is required, refs are likely to become a scalability bottleneck in the future.

6. The working copy can be omitted; checkout by default retrieves only the needed data.

Anthropic’s monorepo is massive, and its CI runs tens of millions of code checkouts each day, so they aim to avoid unnecessary checkouts whenever possible. For example, if a CI job needs to compute the diff between a commit and its merge base, it can query the Scion server directly. Many write tasks can also skip code checkout entirely and be performed via the API.

Scion’s protocol is built around sparse checkout and virtualized checkout. Sparse checkout includes only the directories the client explicitly needs, while virtualized checkout loads files only when they are actually required. This way, even when a task must use files on disk, it only retrieves the content that is read.

III. How Scion Works

Having covered these design principles, let’s see how Scion implements them. These insights can be applied to other version‑control systems and may also help other parts of the software development workflow.

Data Structures

In Scion, the basic unit of work is called a Changeset, which is a record in the Write-Ahead Log.

A Changeset stores most of the common information found in a Git commit, but the two organize data differently. A Git commit stores a pointer to a tree, whereas a Changeset stores a list of files changed relative to the first parent commit, along with content-addressed pointers to the compressed file contents in object storage. Changesets are created on the server side and become immediately accessible throughout the system once created.

The data structure of Changeset in Scion.

This structure enables Scion to receive changes with extremely high throughput. Because it does not need to receive packfiles, does not require locking or cross‑server coordination, and does not need to move refs. Strictly speaking, Scion still supports refs. However, creating and retrieving commits do not depend on refs, so moving a ref only requires a single compare‑and‑swap operation on a single row in Spanner, and this operation is separate from creating a Changeset.

However, a Changeset only records the content that changed. Relying solely on these records, you cannot quickly answer who last modified a particular line of code, or which commits a file has gone through. To address these issues, Scion builds additional data structures on top of Changesets, including structures specifically for querying blame and file‑path history, as well as skip‑list structures to accelerate commit‑graph queries.

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

This mechanism has three benefits.

• First, if you discover that a certain operation can be accelerated with a new data structure, you can easily add a new type of derived data.

• Second, each derived data type can independently decide whether to compute it in advance or defer computation until it is actually needed, thus avoiding the generation of unnecessary data.

• Finally, the client does not need to know the internal implementation of these data structures, allowing the server-side structures to be continuously optimized without requiring changes to the client.

As Scion has evolved, Anthropic has repeatedly added new derived data types, such as indices for detecting file duplication and for path‑based file search.

Extending Scion

A modestly sized Scion server cluster that provides various source‑code control APIs to clients, including fetching changesets, computing diffs, finding merge bases, and retrieving blobs. All source‑code data is content‑addressed, so once written the content never changes. Any server can cache this data without needing to coordinate with other servers.

Therefore, Scion servers can scale horizontally with minimal coordination between them. These servers essentially act as large caches while also computing derived data on demand and writing the results back to Spanner.

A large number of internal tools that use Scion no longer need to maintain their own local repositories. In the past, if a CI job or other tool needed to query commit ancestry or trace code changes, it had to first fetch and maintain a repository, which imposed a significant maintenance burden. In fact, early in the migration we didn’t even have our own client, repository format, or communication protocol, and Scion could only answer these metadata queries. By contrast, fetching file contents or generating a working copy on disk requires far more data transfer, so we designed a separate solution for that capability.

The scn client of Scion differs from Git in several important ways regarding the data retrieval protocol, allowing it to use a more extensible architecture with CPU overhead significantly lower than that of a Git server. When negotiating data retrieval, Scion does not have the client first tell the server which data it already has; instead, it directly requests the directory tree and Blob objects that the client wants. The client starts from the root directory tree, checks which tree objects are missing in local storage, and then recursively requests them from the server. After the directory tree is fetched, it retrieves the Blobs in the same manner. Each request targets a specific, immutable object, so any cache can return the result.

The entire architecture is very similar to a traditional layered caching system. This approach is highly efficient and supports resumable transfers, because the process does not rely on a single packfile response that can be several gigabytes in size. Sparse checkout and virtual checkout also require no special support. The client simply needs to avoid requesting directory trees it does not need.

In Anthropic’s compute clusters, the client communicates with a daemon called scion-daemon via a socket. scion-daemon stores code objects for the entire compute node. Because most nodes need to access the Monorepo, different tasks on the same node often reuse a large number of identical objects, so having the daemon manage the cache centrally is more efficient. Each scion-daemon loads a periodically updated snapshot at startup. Afterwards, it only communicates with the directory tree and Blob cache servers of its Region, which are called scion-cache.

scion-cache transfers objects directly from memory using the same format that the daemon ultimately writes to disk. Therefore, the cache server does not need to compute which objects the client is missing, nor does it need to perform delta compression. When an object is missing from the cache, scion-cache requests it from the authoritative server scion-server, which then reads the 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 know the topology of the entire caching system. In theory, any layer can communicate with other layers. However, Anthropic strictly defines the access relationships between different layers to isolate failures. For example, if a scion-cache in a Region fails, Anthropic does not want a large number of requests to flood the upstream scion-server, ultimately causing the entire system to collapse.

Scion’s code checkout architecture.

Each layer of this system’s cache has a hit rate above 99%, and it requires no long‑term state maintenance, making it easy to scale on demand. Compared with the previous Git mirror infrastructure, Scion reduces CPU and memory usage by a factor of 200. Code checkout speeds for CI and research tasks have improved by roughly two orders of magnitude, shrinking from minutes to seconds. This frees a large amount of resources across the entire compute cluster, saving 25% of CPU capacity for the CI system alone. Moreover, neither the client nor the cache servers need to perform repository maintenance tasks, simplifying lifecycle management of jobs.

4. What We Learned While Developing Scion

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

Here is a very representative example. Earlier this year, Anthropic basically hand‑crafted the first prototype of the Git‑to‑Scion data import pipeline. At the time, Anthropic thought the program was already quite good. It wasn’t until they got an early internal version of Claude Mythos Preview that Anthropic asked Claude to rewrite the entire program without giving any additional instructions. As a result, Claude produced an implementation that reduced memory usage by a factor of 20 and increased runtime speed by 4×, while fully preserving all the implicit constraints on data import order and data structures from the original program.

Number of code changes merged weekly in the Scion and Antique codebases from January to September 2026.

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 seven‑person team built Scion and the code‑review tool Antique in five months, created roughly half a dozen related systems, and completed a full migration to those systems. Antique alone is enough material for a separate engineering blog post.

Moreover, the entire development and migration took place while Anthropic’s daily code merge volume grew tenfold. In the past, developing and deploying such a source‑code control system would typically require more engineers and years of iterative development and gradual migration.

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

Engineers are still important, but the way they work is changing

All the engineers involved in this project now believe that Claude’s coding ability has surpassed their own. Yet engineers still play an irreplaceable role. Team members understand the overall relationships between the various systems and are clear about the trade‑offs required by different architectural designs. Anthropic knows what problems it needs to solve and how large a scale the system must support, so it can make sound design decisions. Often, it turns out that an engineer’s job is to tell Claude “no.”

The agent sometimes violates core constraints that the system must originally obey in order to satisfy a certain coding pattern. This situation is especially common during migration. For example, several systems need to query when a particular code change was merged into the main branch. Claude tries to find the answer by linearly scanning the commit log, whereas it could simply query our code review tool directly.

Anthropic also makes extensive use of adversarial code review. This approach is very effective in many ways, but it can sometimes over‑focus on local issues. Therefore, experienced engineers need to steer Claude in time, preventing it from over‑engineering the system to address hypothetical risks. For instance, one review was overly cautious about the trustworthiness of another internal service, resulting in Claude adding a large amount of extra validation and making the system more complex. Currently, Anthropic team members still review every code change request for this system, but now they mainly check whether the intent of the modification is reasonable rather than reading every line of code.

Significantly improved system performance and code quality

Claude can write large amounts of code at a speed far faster than human engineers, making Scion one of the most thoroughly tested and best-protected codebases Anthropic has ever worked with. Even under very tight development schedules, Anthropic built fully isolated, repeatable simulation tests that cover a wide range of complex infrastructure interactions and source‑code control operations previously encountered.

In addition, Anthropic added fuzz testing and a robust rate‑limiting mechanism. Claude also frequently discovers important performance‑optimization opportunities with ease. For example, it once found that a commit‑ancestor‑relationship query algorithm omitted an existing index, leaving room for optimization. If left to a human expert, analyzing and tuning such an issue could take days or even weeks. After Claude completed the optimization, it was able to tackle similar tasks again the next day.

Actual performance improvements of Scion’s native code repository.

Laying a new foundation for secure management of Monorepos

For large-scale monorepos, security and compliance are as important as capacity and scalability. Anthropic has considered these issues from the very beginning of designing Scion. Scion supports rich code repository access controls and can set permissions for individual directories. This allows protecting the most sensitive code while retaining the advantages of a monorepo.

In addition, Anthropic’s code review tool supports complex, semantics-based approval constraints. For example, the system can distinguish simple changes that only modify comments from modifications that involve sensitive program logic. This enables human reviewers to focus their effort on changes with greater impact.

System operations can reach a new level

Anthropic’s team heavily uses Claude Tag to monitor various system components, for example by creating dedicated Slack channels where Claude continuously watches the health of a specific component. Anthropic calls these Claudes “Superfans.”

Currently, Anthropic has a Superfan for the scion‑daemon, a Superfan for the scion‑cache, and a Superfan dedicated to monitoring the Antique merge queue. They have access to the system’s telemetry data and logs. These Claudes act like seasoned engineers with plenty of time, constantly refreshing monitoring dashboards and looking for any abnormal signs.

Of course, Anthropic still retains traditional alerts for all systems. However, compared to those, Superfans can spot very subtle, previously unseen issues, making traditional alerts seem somewhat limited.

Rethinking many past practices

This project prompted Anthropic to reexamine workflows that were designed for large‑scale human development. For example, in scenarios where agents perform massive programming, the traditional merge queue may no longer make sense. While a set of tests is still running, hundreds or even thousands of code changes could be merged into the repository. In such a case, how should CI actually operate?

So far, Anthropic has not been able to effectively reproduce the industry‑common approach of managing merge queues with a global repository lock. Consequently, Anthropic has devoted more effort to automated testing after code merges and automated testing before deployment. Of course, this means that concurrent code changes may conflict. However, Claude typically fixes the issue before human engineers even notice the conflict.

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 continuously improving AI Agent capabilities. We share these details in the hope that other teams can draw some inspiration from our practice.

However, Anthropic does not think that Scion’s approach is suitable for every scenario. Scion is definitely not meant to be a universal replacement for Git. The design ideas presented here are mainly applicable 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.

In addition, Anthropic has a special condition: it can consume tokens for internal tasks far beyond the scale that other companies are willing to bear in reality. This is done both to meet its own software development needs and to test Claude’s capabilities. In practice, turning Scion into a product that can be widely adopted by other companies is also very challenging.

Scion differs greatly from Git. If other companies want to migrate to Scion, they need to transition every part of their software development workflow, along with supporting code review, code search, and CI systems. The systems Anthropic uses internally are highly customized, making it difficult for other companies to adopt them directly.

Anthropic also worries that trying to develop a public version that meets everyone’s needs might end up producing a product that isn’t very useful. However, Anthropic expects that over the next 6 to 12 months, these issues will become increasingly common. If every company using Git has to solve similar problems on its own, it will clearly waste a lot of engineering resources.

Therefore, Anthropic believes that the most valuable approach right now is to share its design ideas so that other developers can apply some of Scion’s proven solutions to Git without completely abandoning Git’s existing overall model. For example, a Git server doesn’t have to operate in the same way as a Git client. New server architectures already exist that can significantly improve system scalability.

Git hosting platforms can also, like Scion, provide a full server‑side RPC interface. These interfaces could even be standardized across different code‑hosting platforms, allowing Git clients to call them directly. The current Git data negotiation protocol does not necessarily have to remain unchanged. Moreover, Git’s existing sparse checkout, shallow clone, and other features can be further refined to work together more effectively.

Reference links:

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

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

© THE END 

For reprints, please contact this public account for permission

Submit articles or request coverage: liyazhou@jiqizhixin.com