Anthropic's Scion: Replacing Git for 30,000 Daily Merges

Anthropic has moved its main code repository off git and onto Scion, a version control system it built in-house. The reason is volume: the number of code changes merged each day grew from about 2,500 in May 2026 to more than 30,000 in September, as Claude agents took on a growing share of the coding.

What Anthropic announced

In a post on the Anthropic engineering blog dated October 13, 2026, the company’s source control team explains that writing code is no longer the constraint. The new bottleneck is developer infrastructure designed for human scale: source control, builds, and continuous integration (CI), the automated testing pipeline that runs every time code changes.

To deal with it, a team of seven people built Scion to replace git for the company’s monorepo, a single large repository that holds the code for many projects. The same team also built Antique for code review, a code search system, and access controls for the repository. The full migration took five months, during which merge volume grew roughly tenfold.

Anthropic is clear about the limits. In the same post, the team writes, “Scion is by no means a suitable replacement for git for general use.” Scion is designed for very large repositories worked on by many agents at once, and it has not been released publicly.

Why git started to struggle

Git assumes that each developer works on their own machine, often offline. Every copy of a repository therefore carries the full history. That model works well for human teams, but it becomes expensive when thousands of agents and automated jobs pull the same code every minute.

The figures Anthropic shared show the scale:

• The monorepo’s main-branch history is close to 100 GB, and a compressed working copy is more than 25 GB.
• The company performs on the order of 25 million code checkouts per day for CI, agent sandboxes, and research jobs.
• If every checkout fetched the repository in full, git traffic would exceed 600 PB per day.
• To absorb that load, Anthropic once ran several hundred internal git mirrors. The faster the code changed, the harder it became to keep those mirrors in sync with the main branch.

In other words, a tool used by almost every development team in the world started to slow things down once most of its users were machines working around the clock.

How Scion works

Scion reverses git’s division of labor. The server holds all the data, and developer machines or CI runners fetch only what they need.

The server keeps the history, clients fetch on demand

Scion assumes that clients are always connected. Code history, blame (who changed a given line), commits, merges, and rebases all run on the server. A client keeps only a bounded local cache plus the files it is working on.

Many CI jobs do not need a copy of the repository at all, because they can query the server through an API. When a copy is required, Scion downloads only the files that are actually read. According to Anthropic, no complete copy of the repository exists anywhere, including on the server, because the data is spread across many machines.

Changes are recorded as changesets

The unit of work in Scion is the changeset. Each changeset records the files that changed relative to the previous version and is stored in an ordered log. The pointer to the main branch is updated in a single row of Google Spanner, so committing does not lock the whole repository. Derived data such as blame and per-file history is computed incrementally and stored on the server.

The system has four layers: the scn client, a scion-daemon on each machine, a regional scion-cache, and scion-server as the authoritative source. Anthropic says each cache tier keeps a hit rate above 99 percent.

The results for Anthropic

Anthropic reports three headline results. Scion’s CPU and memory footprint is 200 times smaller than the previous git mirroring setup. Checkouts for CI and research now finish in seconds instead of minutes. CI alone freed 25 percent of its CPU capacity.

The role of Claude and the engineers

Claude did much of the work on the project. Anthropic gives one example: the pipeline that moves data from git into Scion was first written by hand, then rewritten by an early internal snapshot of Claude Mythos Preview. The new version used 20 times less memory and ran four times faster.

The engineers’ role changed as well. According to the team, they spent more of their time setting design direction and turning down shortcuts or over-engineered designs that Claude proposed. Code review also shifted toward the intent of each change. Anthropic even replaced its traditional merge queue with automated testing after merge and before deployment, because Claude usually fixes conflicts between concurrent changes faster than humans notice them.

What this means for your development team

Most development teams are nowhere near that volume of changes. Even so, Anthropic expects this class of problems to become more common over the next six to 12 months as more teams use AI agents to write code. IT teams at startups, banks, and government agencies can start preparing with simpler steps.

• Measure your CI load first. Record how many pipeline runs you have per day, how long checkouts take, and what CI machines cost each month. These numbers become your baseline as agent use grows. Cloud computing services can help you plan capacity.
• Use the git features you already have. Git offers partial clone and sparse checkout, which download only the files you need. For large repositories, these two features can speed up CI without changing systems.
• Sharpen your code review rules. If AI agents write code, decide which parts always need a human reviewer, such as payment modules, personal data, and access control. Anthropic’s experience suggests reviewers should focus on the intent and impact of each change.
• Set permissions per folder. Directory-level permissions help make sure changes to sensitive areas always go through the right people.
• Keep ownership of design decisions. AI agents can write code quickly, but architecture decisions still belong to engineers who understand what the system needs.

If your team is setting up a development process that uses AI, Merakit’s web development and AI services pages are a good starting point for the conversation.

Frequently asked questions

Can other companies use Scion?

Not at the moment. Anthropic has not released Scion publicly and says it only makes sense for very large monorepos. The company says it wants to share ideas with GitHub, GitLab, and the open source community, for example by having git platforms offer more server-side operations.

Will git be replaced?

Not any time soon. Git remains the standard for almost every project, and Anthropic itself says Scion is not a replacement for general use. What is changing is how git services run when most of their users are AI agents.

What is a monorepo?

A monorepo is a single repository that holds the code for many projects or services. It makes changes across projects easier, but it can grow very large, like Anthropic’s monorepo with a history of nearly 100 GB.

Closing thoughts

Scion shows that when AI agents write code far faster, the tools around them need to change too. For most teams, the first steps are simple: measure CI load, use the git features that already exist, and make code review rules clearer. If you want to discuss a development process that is ready for AI agents, contact the Merakit team.

Sources

• Anthropic Engineering: Redesigning source control at Anthropic (October 13, 2026)
• OfficeChai: Anthropic Builds In-house Version Of Git Called Scion After Code Merges Rise 12x In 4 Months (October 14, 2026)
• HackerNoon: AI Agents Are Killing the Git Client, Not Git (October 14, 2026)
• Git documentation: partial clone
• Git documentation: git sparse-checkout