7 people, 5 months, Anthropic has built a Git alternative.

Git, the version control tool that has ruled programmers for 20 years, has been unexpectedly replaced by a new system built by Anthropic itself.

And all of this was completed with only 7 engineers and Claude deeply involved in the development.

Over 5 months, Anthropic developed its internal source code control system Scion, the supporting code review tool Antique, and multiple other related systems from scratch, and completed the migration of the entire monolithic code repository from Git to Scion.

What does this mean? A small team of people, with the help of AI, only needs a few months to build a new system that directly replaces Git which their company has used internally for many years. It's absolutely astonishing! This inevitably leads to the exclamation of "RIP GIT".

Why build a Git alternative on your own?

The reason is simple: Anthropic's AI programming scale has grown so large that the original development infrastructure can barely keep up.

Data released by Anthropic shows that in May this year, it merged about 2500 code changes on average every day. By September, this figure has exceeded 30,000, a more than 12-fold increase in just 4 months. Moreover, Anthropic expects this growth will not slow down in the short term. The potential demand for code merging has almost no upper limit, and every time a bottleneck is resolved, code output will further increase.

Driven by actual operational pressure, Anthropic developed its internal version control system and completely migrated the entire Monorepo from Git to Scion within five months.

Anthropic has fully introduced the entire process in its latest blog post.

I. The Ever-Expanding Monorepo

Before introducing Scion, it is necessary to explain how special Anthropic's workload is. Its degree of using Claude to write software far exceeds that of the vast majority of companies, where tools designed for human development scale begin to struggle. Source code control is just one example.

Anthropic expects that not many companies will encounter the same problem in the short term. But as AI programming tools become more and more popular, other companies will soon hit similar bottlenecks, which is also why we decided to share Scion's design and development experience.

Git is a decentralized system. Every clone gets a complete, independent copy of the code repository. Even completely offline, developers can calculate code differences, view commit history, track modification records of a certain line of code, and check out any version. For the vast majority of code repositories, this design is very reasonable, and it is also an important reason why Git has become the industry standard.

However, as Anthropic's Monorepo continues to grow, Git's design is increasingly unable to meet the demand. At present, the historical data of the main branch alone is close to 100GB, and the compressed working copy is more than 25GB. The CI system alone performs about 25 million code checkouts every day, not counting development environments, Agent sandboxes, and research tasks. If the required data is directly obtained from Git every time, the daily data transmission volume will exceed 600PB.

Of course, Git also provides functions to process partial repository data, such as shallow clone, sparse checkout and Promisor Remote. The industry also has some common methods to deal with large Monorepos, such as building an internal Git mirror or storing snapshots of the code repository in object storage.

Anthropic has used all these methods. At the peak of the load, it even ran hundreds of internal Git mirror servers. These solutions did help sustain operations for a period of time, but as the volume of code merging continued to grow, they became more and more difficult to maintain. The gap between the snapshot and the latest version of the main branch will become larger and larger between two snapshot refreshes. At the same time, to make partially cloned repositories normally perform operations that rely on historical information such as diff and blame, more and more maintenance work is required.

Typical architecture for extending Git code checkout capabilities.

Later, Anthropic re-examined its own usage pattern and found a problem. 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 almost all clients are Agents and automated tasks that are always online by nature. Those features provided by Git for distributed and offline development instead limit the system's scalability as the code repository continues to grow.

Thus, Anthropic began to think: If a source code control system is designed from the very beginning according to the feature that Agents are always online, what should it look like?

II. Source Code Control Oriented to Agent Scale

As Agents begin to write code in large quantities, many traditional assumptions in software development are changing. When designing Scion, Anthropic fully considered these changes, so it adopted different solutions from Git on several core principles. Of course, source code control for extremely large Monorepos is not without precedent. Google's Piper and Meta's Sapling have accumulated rich experience, which Anthropic also referred to when developing Scion.

Scion mainly 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 code repository locally. But almost all of Anthropic's clients are Agents and automated tasks, so Scion's client and communication protocol are designed around the always-accessible server. The client only obtains the data it needs from the server.

2. The client and the server take different responsibilities.

In Git, every client has the ability to act as a complete Git server. Scion delegates most of the work to the server, including querying file history and blame information, creating commits, performing merges and rebases. The client is only responsible for maintaining a locally stored object cache with a limited size, writing files in the working copy to disk, monitoring file system changes, and providing an interface for user operations. The client itself hardly needs to perform complex calculations, so the amount of data stored locally is much smaller.

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

In Git, if a CI task or other tool wants to query information in the code repository, such as who last modified a certain line of code, or what the relationship is between two commits, it usually needs to maintain a local repository by itself. Another way is to rely on APIs provided by specific service providers, but these APIs may not be able to answer all questions. Scion opens all the source code query functions used by clients as APIs. In this way, many tasks can complete queries directly without a local repository at all.

Anthropic's internal automated bisecting and code rollback pipeline is an example. Without this low-cost, programmatically callable source code access capability, these tools would be very difficult to run at the current scale.

4. All components must support horizontal scaling.

In the past, Anthropic ran up to hundreds of Git mirror servers at most, occupying a large amount of computing resources. Moreover, once the size of the code repository exceeds the disk or memory capacity of a single mirror server, further expansion will become very difficult.

Scion stores code repository data in a distributed manner, and each component can be scaled independently. There is no fully materialized complete code repository in the entire system, nor on the server. Scion also has no mechanism corresponding to Git packfile, so there is no need to perform related repository maintenance operations.

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

In Git, developers commit code locally first, and then share the changes through push. All commit, rebase and merge operations in Scion are completed on the server side, so there is no need for push. But in this case, the server must be able to process these operations quickly. The cost of creating commits and updating related data structures must be proportional to the size of this code change, instead of growing with the size of the entire repository. Otherwise, the server will sooner or later fail to keep up with the code submission speed.

Scion's development workflow also minimizes the use of refs as much as possible. A ref is a reference pointing to a commit, such as branches and tags, and usually only retains necessary references such as the main branch or release branches. Because global data that requires all servers to maintain a consistent state together will likely become an expansion bottleneck in the future.

6. The working copy can be omitted, and checkout only obtains the required data by default.

Anthropic's Monorepo is very large, and CI performs tens of millions of code checkouts every day, so they want to avoid unnecessary checkout operations as much as possible. For example, if a certain CI task needs to calculate the difference between a commit and its merge base, it can query the Scion server directly. Many write tasks can also skip code checkout and be completed entirely through APIs.

Scion's protocol is mainly designed around sparse checkout and virtualized checkout. Sparse checkout only includes the directories explicitly needed by the client, while virtualized checkout loads files only when they are actually needed. In this way, even if the task must use files on disk, it only needs to obtain the content that is actually read.

III. How Scion Works

After understanding these design principles, let's take a look at how Scion implements them. These experiences can be applied to other source code control systems, and may also help other links in the software development workflow.

Data Structure

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

Changeset stores most of the common information in Git Commit, but the data organization methods of the two are different. Git Commit stores a pointer to the directory tree, while Changeset stores the list of files that have changed relative to the first parent commit, and content-addressed pointers pointing to the compressed file content in the object storage. Changesets are created on the server side, and can be accessed from anywhere in the system immediately after creation.

The data structure of Changeset in Scion.

This structure allows Scion to receive changes at extremely high throughput. Because there is no need to receive packfiles, no locks or cross-server coordination, and no need to move refs. Strictly speaking, Scion still supports refs. But creating and obtaining commits do not depend on refs, so moving a ref only requires a Compare-and-Swap operation on a single row of data in Spanner, and this operation is separated from creating a Changeset.

However, Changeset only records the content that has changed. Relying solely on these records cannot quickly answer who last modified a certain line of code, or which commits a certain file has gone through. To solve these problems, Scion will build additional data structures based on Changesets, including data structures dedicated to querying blame and file path history, and skip lists for accelerating commit graph queries.

Anthropic collectively refers to data that does not directly belong to Changesets as Derived Data. All derived data is calculated through a general mechanism. Each type of derived data is recursively defined: the derived data of a certain Changeset can be calculated based on the corresponding data of its parent Changeset.

This mechanism has three advantages.

First, if it is found that a certain operation can be accelerated by a new data structure, a new type of derived data can be easily added.

Second, each type of derived data can independently decide whether to calculate it in advance or wait until it is actually needed, so as to avoid generating unused data.

Finally, the client does not need to understand the internal implementation of these data structures, so the server-side data structures can be continuously optimized without modifying the client.

As Scion evolves, Anthropic has added many new derived data types, such as new indexes for detecting file copies and searching files by path.

Scaling Scion

A small Scion server cluster is responsible for providing various source code control APIs to clients, including obtaining Changesets, calculating diffs, finding merge bases, and obtaining Blobs. All source code data is content-addressed, so once the data is written, the content will never change. Any server can cache this data without confirming with other servers.

Therefore, Scion servers can be scaled horizontally, requiring very little coordination with each other. These servers are essentially like large caches, and can also calculate derived data on demand and write the results back to Spanner.

A large number of internal tools using Scion no longer need to maintain their own local repositories. In the past, if a CI task or other tool needed to query the ancestor relationship of commits and track code modification records, it had to obtain and maintain the code repository first, which would bring a considerable maintenance burden. In fact, in the early stage of migration, we did not have our own client, repository format and communication protocol, and at that time Scion could only answer these metadata queries. In contrast, obtaining file content and generating working copies on disk requires a much larger amount of data transmission, so we designed a separate solution for this part of the capability.

Scion's scn client has several important differences from Git in the data acquisition protocol, so it can adopt an architecture with stronger scalability and significantly lower CPU overhead than Git servers. When negotiating data acquisition, Scion will not let the client first tell the server which data it already owns, but directly request the directory tree and Blob objects that the client wants. Starting from the root directory tree, the client checks which directory tree objects are missing in the local storage, and then recursively requests them from the server. After completing the acquisition of the directory tree, obtain Blobs in the same way. Each request points to a clear object whose content will not change, so any cache can return the result.

The entire architecture is very similar to a traditional layered cache system. This method is very efficient and supports resume transmission from breakpoints, because the whole process does not need to rely on a single packfile response that may be several GB in size. Sparse checkout and virtualized checkout do not require special support either. The client only needs to not request the directory tree it does not need.

In Anthropic's computing cluster, the client communicates with a daemon process named scion-daemon through Socket. scion-daemon stores code objects for the entire computing node. Since most nodes need to access the Monorepo, different tasks on the same node usually reuse a large number of the same objects, so it is more efficient for the daemon to manage the cache uniformly