Anthropic's in-house version control, Scion: what a small team should change first after AI writes the code

What can't keep up is a repository the size of Anthropic's, not yours. The numbers they give:

• Main-branch history is “almost 100 GB,” and the compressed working copy is “over 25 GB.”
• CI alone does “on the order of 25 million code checkouts” a day. That does not count dev environments, agent sandboxes, or research jobs.
• If every checkout pulled the repository the straightforward way, Git traffic would pass 600 PB a day ("that would be over 600 PB of git traffic per day").

Git itself has ways to take only part of a repository: shallow clone, sparse checkout, and promisor remotes. Large repositories also have the usual moves, internal mirrors and seeds, meaning snapshots kept in object storage. Anthropic says they used all of them. At the peak they were operating several hundred internal Git mirrors to carry the load:

"at our peak, we operated several hundred internal git mirrors to deal with the load."

Those measures bought time, but the faster merges got, the harder the setup was to maintain. Between refreshes, seeds fell further behind the latest commit on main. Operations that depend on history, such as diff and blame, got harder to keep working on a partial clone.

The original post puts a diagram here, “a typical architecture for scaling Git checkouts,” showing how mirrors plus object-storage snapshots scale. See Growing our monorepo.

Like most companies, they were in practice using Git as a centralized system. There is one authoritative copy, and almost every client is an agent or a job, online by nature. The strengths Git was designed around, offline and distributed work, turned into resistance to scaling.

Anthropic lists several principles. I am keeping the four that matter to a small team:

1. The client is always online. Git assumes you might be offline, so every clone has to be a complete repository. Scion assumes the opposite: the server is always reachable, and the client fetches a piece of data only when it needs it.

2. Computation stays on the server. The client keeps only a bounded cache. File history, blame, creating a commit, merge, and rebase all happen on the server. The client maintains only “a bounded local object cache,” lays files out on disk, and watches for file changes. The client itself cannot compute much, but the data it needs locally is far smaller. Every query the client uses is also exposed as an API. The post says many jobs therefore “don’t need a local repository at all.”

3. A working copy is optional, and sparse and virtualized by default. If CI wants the diff between a commit and its merge base, it asks the server. It does not check anything out. When files really have to land on disk, the protocol is built around sparse checkout, which takes only the directories you want, and virtualized checkout, which materializes files on demand. The client only pays for what it actually reads ("the client only pays for what it actually reads").

4. Commits have to be cheap, incremental, and lock-free. Every commit, rebase, and merge happens on the server, so there is no push, but every operation has to be fast. The cost of creating a commit and updating its downstream data structures has to grow with the size of the change, not with the size of the whole repository:

"The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo"

In the data model, Scion’s unit is the changeset. Unlike a Git commit, which points at a whole tree, a changeset records only which files changed relative to the first parent, plus content-addressed pointers to the compressed bytes in object storage. The structures that queries such as blame and path history need are treated uniformly as “derived data” and computed separately.

The diagram of a changeset is in the original post, under Data structures.

The results they list:

• CPU and memory for the infrastructure are “200x smaller” than the previous Git-mirror setup.
• Checkouts for CI and research jobs are “two orders of magnitude faster (in seconds rather than minutes).”
• “CI alone realized a 25% CPU capacity win.”
• Every layer of the cache “maintains a cache hit rate of over 99%.”

What a small team can use from this: if you do not need the data, do not move it, and if you can ask, do not compute it.

Yes, but the way you review it changes. Once the volume of code goes up, human review easily becomes the new choke point, the thing usually called the AI code review bottleneck.

The engineers on the team all thought Claude wrote better code than they did. What they kept finding was that the engineer’s role was to tell Claude “no”:

"Very often, we found that the role of the engineers was to tell Claude “no.”"

The reason is that an agent will sometimes violate a core constraint of the system in order to fit a pattern that should never have been allowed. The example in the post: during the migration, several systems wanted to know when a change had landed on main. They did it by reading the commit log linearly and searching by brute force, instead of asking the code review tool.

The second trap is adversarial review. Anthropic uses adversarial review heavily. The post grants that it is very effective in many ways, and that it can also be “myopic.” The example: one review was overly defensive about whether to trust another internal service. Claude added too much validation and too much complexity, and an experienced engineer had to pull it back, away from over-designing for an imaginary problem.

Third, the review itself changed. People still look at every change request. They look at the intent, not at every line of code.

"Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code."

The post gives one more example. Early on they hand-wrote a prototype of the git-to-Scion ingestion pipeline and thought it was pretty good, until they got an internal early snapshot of Claude Mythos Preview and had it rewrite the whole thing, “with no further instructions.” The version it produced used 20 times less memory and ran 4 times faster, while keeping the ingestion order and every implicit invariant in the data structures.

The chart of weekly merged changes in the Scion and Antique codebases is in the original post, What we learned building Scion.

Each item starts with what Anthropic did, then my suggestion for a small team. The suggestions are not something they wrote.

a. If CI can ask an API, don't clone

What they wrote: every source-control query the client uses is exposed through an API, and many jobs do not need a local repository at all.

"With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all."

Suggestion: look back at your CI and your scripts. How many git clone steps exist only to ask one question: who last changed this file, which paths this PR changed, which commit a tag points at. The hosting platform’s API can answer a lot of those. There is no need to pull the whole repository.

When you really cannot avoid a clone, use Git’s own sparse checkout and partial clone, and take only the part you need:

b. Write the hard constraints down for the agent, and review AI code for intent first

What they wrote: an agent will sometimes violate a core constraint of the system in order to satisfy a pattern that should never have been allowed.

"Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place."

Suggestion: a small team does not have that many senior engineers standing by to say “no,” so write the “no” down ahead of time. In AGENTS.md at the root of the repository, or whichever instructions file your agent reads, list the forbidden patterns. For example:

When you review a PR, ask three questions first. What is this change trying to solve? Why this approach? Does it hit one of the constraints above? Look at the details only after the intent is right. I derived that from their “look at the intent instead of reading line by line.” It is not a checklist from Anthropic.

c. Adversarial review needs a boundary

What they wrote: adversarial review “can also be myopic.” Being overly defensive about another internal service once led Claude to add too much validation and too much complexity.

Suggestion: if you let one agent review another agent’s code, write the boundary down for the reviewer. For example: “Trust boundary: treat return values from internal service X as trusted, and do not require extra checks. Report only problems that have a realistic way to be triggered. List hypothetical risks on their own, marked optional.” Also require review comments to be split into “must change” and “optional.” The author only has to act on the first.

d. Let one agent watch one component: superfans

What they wrote: they set up Slack channels where Claude watches the health of a single component. They call them “superfans”: a scion-daemon superfan, a scion-cache superfan, an Antique merge-queue superfan, and others. These agents can see telemetry and logs. They act like an engineer who has nothing else to do but refresh charts and look for anything strange.

"They have access to our telemetry and logs, and act like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange."

The post also says they kept the traditional alerts.

Suggestion: a small team can start with one component. Give one agent read-only access to the logs and the monitoring of a single service, such as your API or a queue worker. On a schedule, have it write a short “what looks off today” note into a dedicated channel. Do not start by letting it see the whole system, and do not let it replace alerts.

e. Does the merge queue still need a global lock?

What they wrote: they were not able to put a global repository lock on the merge queue, so they invested in automated tests that run after the merge and before deploy.

"We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing."

The post admits this means concurrent changes can conflict, but “Claude can typically fix these conflicts faster than humans can even identify them.”

Suggestion: a small team should not copy “drop the tests that run before merge” straight across. Measure first: how long a PR sits in the queue, and how often concurrency actually causes a problem. If the queue is the main wait and conflicts are rare, consider moving some of the slow tests to after the merge and before deploy. The gate before deploy has to stay.

Anthropic’s own monorepo has already moved off Git. Scion is not a replacement for Git in the general case. They say so themselves:

"Scion is by no means a suitable replacement for git for general use."

The post says these ideas only matter for a truly enormous monorepo: either tens of thousands of engineers, or swarms of agents writing a large amount of code. A few more things not to copy:

• The token budget. The post says the tokens Anthropic can spend internally “far exceeds what any other business would realistically want to spend.” Adversarial review and superfans both spend tokens. A small team has to do the arithmetic.
• Building the whole toolchain yourself. Scion is very different from Git. It needs its own code review, its own code search, and its own CI. The post says those internal components are highly customized, and another organization would have a hard time adopting them.

It is also not someone else’s problem. The post expects this class of problem to “become more commonplace over the next six to 12 months.” The direction they offer is to apply the most successful parts of Scion onto Git, “without departing from the overall model.” A Git server, for example, does not have to work the same way the client does, and a platform can offer a fuller set of server-side RPCs.

Keep using Git. Stop assuming that every job needs a full copy of the repository, and stop assuming that a person reads every line AI writes. Start with the CI steps that clone only in order to ask one question.

• Anthropic Engineering, Nick G. and the source control team, “Redesigning source control at Anthropic,” published 2026-10-13: https://www.anthropic.com/engineering/redesigning-source-control
• Every screenshot in this article comes from that blog post. Source: Anthropic, 2026-10-13.

• X Algorithm Code: Copy-Link Shares Weigh 30x a Like
• More articles