In 2026, Anthropic's artificial intelligence (AI) agents began to merge more than 30,000 code changes a day into one repository, and git could no longer keep up. So Anthropic built its own source control system, Scion. Here is the problem it solves, how it works, and what it means for teams that will keep using git.
This post is based on Anthropic's engineering article Redesigning source control at Anthropic, published on 13 October 2026. Scion is an internal tool and is not available outside Anthropic. Details may change; check the original article for the current state.
The picture to hold in your head
Git and Scion start from opposite ideas about where the work happens.- Git: every machine keeps a full copy of the project and all its history. It does the work on that copy, even without a network connection. Then it sends the result to a shared server.
- Scion: one central service keeps the history and does the work. Each machine stays connected and asks only for the files it needs, when it needs them.
Git's model fits people who work on a laptop, sometimes offline. Scion's model fits thousands of short-lived programs that are always online: AI agents and automatic test jobs. The rest of this post explains why Anthropic needed the second model, and how they built it.
In git, every machine has everything:
In Scion, the central service has everything:
The problem: agents write code faster than the tools can carry it
Anthropic keeps almost all its code in one big repository. This is called a monorepo (a single repository that holds many projects instead of one repository per project). Each time a change is added to the main branch of that repository, that is a merge. People also say the change lands.
The number of merges grew very fast once AI agents started to write most of the code. According to Anthropic's article:
- In May 2026, the monorepo received about 2,500 merges a day.
- In September 2026, it received more than 30,000 merges a day, twelve times more.
- The history of the main branch is almost 100 gigabytes (GB). One compressed copy of the files is more than 25 GB.
- Their continuous integration (CI) system, which builds and tests every change automatically, makes about 25 million checkouts a day. A checkout is one copy of the files that a job needs to do its work.
If every one of those 25 million checkouts downloaded a full 25 GB copy, the total would be about 625 petabytes (PB) a day. A petabyte is a million gigabytes. Anthropic's own estimate is "over 600 PB of git traffic per day". No team can move that much data, so the real question was how to avoid moving it at all.
The article states the general lesson in one line: "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI." Writing code is no longer the slow part. Storing it, sharing it and testing it are.
Why git's usual fixes stopped being enough
Git already has several ways to download less. Big companies use all of them, and so did Anthropic.
- Shallow clone: download only the most recent commits, not the whole history.
- Sparse checkout: put only some folders on disk, not every file.
- Partial clone: skip file contents during the download, and fetch each one later, only when it is needed.
- Internal mirrors: copies of the repository on many servers inside the company, so not every job uses the same machine.
- Seeds: a ready-made copy of the repository, kept in cloud storage. A job starts from the seed and then downloads only the newest changes.
These fixes helped for a while. At their peak, Anthropic ran several hundred internal git mirrors. But each fix got harder to run as merges grew. Every mirror had to keep up with 30,000 changes a day. And between two refreshes, the seeds fell further and further behind the newest version of the main branch. So every job had more to download before it could start.
The deeper problem is that each fix works around git's basic idea instead of changing it. Git still expects every machine to hold its own copy and do its own work. Anthropic decided to change the idea itself.
The rules Scion is built on
Anthropic noticed that nearly all the machines that use their repository are not people's laptops. They are agents and CI jobs, and those are always online. So Scion is designed for clients that are always connected, with a server that does the heavy work. (A client is any program that talks to the server: an agent, a CI job, or an engineer's tool.)
The article lists six design rules:
- Clients are always online. A client fetches data when it needs it. It doesn't keep a full copy "just in case".
- The server does the heavy work. History, blame (finding who last changed each line), commits, merges and rebases (moving a change on top of a newer version) all run on the server. The client keeps only a small cache and the files it is working on.
- Source control as a service. Other programs can ask questions through an application programming interface (API), so many jobs never need a local copy at all. For example, a job can ask "what changed between these two versions?" and get the answer directly. Anthropic's tools that automatically find and undo a bad change depend on this.
- The data is spread across many machines. No full copy of the repository exists anywhere, not even on one server. Because there is no single big file to clean up, there is also no repository maintenance.
- Commits are cheap and need no lock. A lock is a rule that makes every other writer wait while one writer changes something. A commit, rebase or merge happens on the server, so there is nothing to push. Named branches are discouraged, except for the main branch and release branches, because every shared name is shared state that all clients must agree on.
- A local copy of the files is optional, and it can be partial. A CI job can ask the server for a diff (the list of differences between two versions) instead of downloading files. When a job does need files, it gets a sparse copy (only some folders) or a virtual one (files appear on disk only at the moment a program reads them).
The table puts the two models side by side.
| Question | Git | Scion |
|---|---|---|
| Does every machine keep the full history? | Yes | No, only the central service does |
| Where do commits and merges happen? | On each machine | On the server |
| Does it work without a network connection? | ||
| How much must a CI job download to start? | ||
| Can a job ask a question without a local copy? | ||
| Who is it built for? | People, often offline | Agents and jobs, always online |
Each model is good at what it was built for. Git wins whenever someone needs to work offline. Scion wins when millions of short jobs each need a small part of a huge repository.
How Scion works inside
The rules above say what Scion does. This section shows how, one layer at a time: how a change is stored, where the data lives, and how a client gets files.
How a change is stored
In git, every commit points to a full snapshot of all the folders and files. (Git doesn't store unchanged files twice, but each commit still describes the whole project.) In Scion, the basic unit is a changeset. A changeset lists only the files that changed compared to the version before it. Like git, Scion stores each file content once and finds it by its hash (a short fingerprint calculated from the content).
Everything else is calculated from the changesets: blame, the history of a single file, and fast ways to walk the list of commits. Anthropic calls this derived data. The server can calculate it right away or later, when someone asks for it. Clients never see how derived data is built, so Anthropic can change it without updating every client.
Where the data lives
The servers behave like large caches (stores that keep recent answers ready, so they don't have to be calculated again). When a client asks for something, the server calculates it if needed and saves the result for next time. The permanent data lives in two places:
- Spanner, Google Cloud's database that spreads data over many machines and many regions.
- Cloud storage, for the file contents.
A branch name, like main, is just one row in Spanner. Moving main to a new commit is a single "compare and swap" on that row: the update succeeds only if nobody else changed the row first. That is how many agents can land changes at the same time without a global lock.
How a client gets files
When you clone a git repository, the data usually arrives as one big packfile (a single compressed file that bundles many files and folders). For a large repository, it can be several gigabytes. Scion doesn't use packfiles. The client starts from the top folder and asks for exactly the folders and files it is missing, step by step. If the download stops, it can continue where it left off. And because the client only ever asks for what it wants, sparse and virtual copies need no special support.
The requests travel through three tiers of servers:
All three tiers understand the same requests, but each tier may only talk to the next one. That way, a problem in one tier stays in that tier. Each cache tier answers more than 99% of requests by itself, so very few requests reach the scion-server, the one place that holds the official data.
Anthropic credits two earlier systems. Google keeps its code in one huge central repository called Piper, described in Why Google Stores Billions of Lines of Code in a Single Repository (2016). Meta built Sapling, whose server part, Mononoke, introduced many of the techniques Scion uses, including the way changesets are stored. Both Mononoke and EdenFS, Sapling's virtual file system, are open source but not supported for outside use.
No merge queue: how changes land at agent scale
Many large teams use a merge queue. Changes wait in a line. Each one is tested on top of the changes in front of it, and it lands only if the tests pass. This keeps the main branch passing its tests. Good merge queues test several changes together to go faster, but every change still has to pass through one shared line.
At 30,000 merges a day, that line never empties. The article says it directly: "A proper merge queue, for example, doesn't make much sense at agent scale."
So Anthropic does it the other way round:
- A change lands on the main branch without waiting in a line.
- Automatic tests run after the merge and again before each deployment.
- Two changes made at the same time can still conflict. When they do, Claude usually fixes the conflict faster than a person would even notice it.
This is a trade. Anthropic accepts that some problems are found after a change lands, not before, and in return, changes never wait in a line. It only works because tests after the merge and fixes by agents are fast.
Seven people, five months, and Claude's part
A team of seven people built Scion and its code review tool, Antique, and moved the whole monorepo off git in five months. During those five months, daily merges grew ten times. The team also built code search and a permission system that can protect single folders inside the monorepo.
Claude did much of the coding. The engineers decided the design, the trade-offs and the targets for speed and size. Some examples from the article:
- The team wrote the first version of the program that copies data from git into Scion themselves, without Claude. Then they asked Claude Mythos Preview (an Anthropic model) to rewrite the whole thing, "with no further instructions". The new version used 20 times less memory and ran 4 times faster, and it kept the order of changes correct.
- Claude wrote a large set of tests, including simulations of the whole system and fuzzing (feeding random inputs to find crashes). The team calls Scion one of the most tested codebases it has worked on.
- Claude found speed improvements the team had missed, such as a database query that ignored an index (a lookup table that makes searches fast) that already existed.
- "Superfan" Claude instances each watch one part of the system through its logs and metrics. They catch small problems that fixed alerts miss.
The engineers' job changed too. A key part of the human role became saying "no": stopping an agent when it breaks a rule of the system. In one example, an agent measured how long merges took by scanning the whole commit log, instead of asking the code review tool, which already had the answer. Engineers now review the intent of each change rather than every line.
The results, as reported by Anthropic:
| Measure | Before (git and mirrors) | After (Scion) |
|---|---|---|
| Processor and memory use of the source control servers | 1× | |
| Time for a CI or research checkout | ||
| Processor capacity used by CI | 1× |
What this means if you use git
The short answer: git is still the right tool for almost every team, and Anthropic says so itself. The article is clear: "Scion is by no means a suitable replacement for git for general use." It is built for very large monorepos with tens of thousands of engineers or a very large number of agents.
You can't use Scion anyway. Anthropic has no plans to release it. The article gives the reason: Scion is very different from git, so a company would have to replace every tool around it too, including code review, code search and CI. At Anthropic, all of those are custom.
Instead, Anthropic wants to bring the ideas into git. They name three ideas, and say they want to work with GitHub, GitLab and the open source community on them:
- Server-side operations: let the server answer questions and do merges, so clients don't have to download data for that.
- New server designs: servers that spread the data over many machines.
- Sparse and shallow features that work together: today, combining git's download-less fixes is fragile.
For a team today, a few lessons carry over even without Scion:
- If agents and CI jobs make most of your checkouts, measure them. They, not people, will hit your limits first.
- Download less in CI. Use partial clone and sparse checkout for jobs that only need part of the repository.
- Check the habits that assume a human pace. A merge queue or a global lock that is fine at 50 merges a day may block you at 5,000.
- Give agents the system's rules. Agents will happily solve a problem in a way that breaks a constraint they were never told about. Saying "no" stays a human job.
Git was designed in 2005 for developers who each keep their own copy and often work offline. It is still very good at that. What changed is who writes the code. When most of the writers are programs that are always online and work day and night, the tools around the code have to change too.
References
- Nick G. and the Anthropic source control team, Redesigning source control at Anthropic — Anthropic Engineering, 13 October 2026
- Git documentation, git-sparse-checkout
- Git documentation, Partial Clone
- Rachel Potvin and Josh Levenberg, Why Google Stores Billions of Lines of Code in a Single Repository — Communications of the Association for Computing Machinery (ACM), 2016
- Meta, Sapling: Introduction — Sapling documentation
- Meta, facebook/sapling (Sapling, Mononoke and EdenFS) — GitHub