Anthropic Replaced Git With Scion: 30,000 Merges a Day and a 200x Smaller Footprint

Anthropic has replaced git for its own monorepo. In an engineering post published on October 13, 2026, the company says the number of code changes merged per day grew from about 2,500 in May to over 30,000 in September, source control became its biggest development bottleneck, and a team of seven built an in-house version control system called Scion and fully migrated in five months. The details matter beyond Anthropic: it is a rare detailed account from a major lab of what happens to developer infrastructure when agents write most of the code.

This post walks through what Anthropic reports, how Scion is designed, the numbers it published, and what builders can take from it. Everything below comes from Anthropic's engineering post unless noted; these are the company's own figures and we have not verified them independently.

Quick reference

Why did git stop working?

Chart of changes merged per day to Anthropic's monorepo, January to September 2026, showing the source control bottleneck behind Scion Image: Anthropic

The chart above, from Anthropic's post, shows the curve. Merges were around 1,000 a day in January, rose through the spring, and then climbed steeply from July. The company marks a "quiet week" in early August when volume dipped, then a recovery to a single-day peak of 30,401 on September 9. The chart also shows the shift from pull requests (blue) to Anthropic's own change requests in Antique (orange) during June and July.

Anthropic's explanation is blunt: "coding is no longer the bottleneck to building systems or doing research." Claude can iterate on research loops, micro-optimize programs and build services quickly, so the limit moved to infrastructure built for human scale: source control, builds and CI.

The monorepo numbers explain why git strained:

• The history of the main branch alone is almost 100 GB.
• A compressed working copy is over 25 GB.
• About 25 million code checkouts happen per day for CI, before counting developer environments, agent sandboxes and research jobs.
• Fetched naively, that would be over 600 PB of git traffic per day.

Git has tools for this: shallow clones, sparse checkouts, promisor remotes, internal mirrors and seeds in blob storage. Anthropic used all of them and at its peak ran several hundred internal git mirrors. That bought time, but seeds drifted from the tip of main, and operations such as diff and blame on partial clones needed ever more care.

The key insight in the post is architectural. Git is decentralized: every clone can compute diffs, read history and check out any revision offline. Anthropic was using it as a centralized system with one authoritative copy, while nearly all clients were agents and jobs that are online by definition. The properties that make git excellent for offline human work were working against scale.

What are Scion's design principles?

Anthropic credits prior art, notably Google's Piper and Meta's Sapling, and lists six principles.

1. Clients are always online. Clients fetch data when they need it instead of holding a full copy.
2. Client-server asymmetry. The server answers history and blame, creates commits, performs merges and rebases. The client keeps a bounded object cache, lays out working files, watches for filesystem changes and gives users an ergonomic interface. It computes very little on its own.
3. A source control service enables new tools. Every query the client uses is also an API, so many CI jobs need no local repository. Anthropic says internal automated bisect and revert pipelines would not be practical at scale without cheap programmatic access.
4. Everything scales horizontally. There is no fully materialized copy of the repo anywhere, even on the server, and no packfiles, so no repository maintenance.
5. Commits are cheap, incremental and lock-free. Every commit, rebase or merge happens on the server, so there is nothing to push. Refs are discouraged except for main or release branches, because global state that every server must agree on is a scaling problem.
6. The working copy is optional and sparse. A CI job that needs the diff to a merge base can ask the server for it. When files are needed, sparse or virtualized checkouts materialize only what is read.

How does Scion work under the hood?

Diagram of Scion checkout architecture with scion-daemon, scion-cache and scion-server tiers for agent-scale source control Image: Anthropic

Changesets and derived data

The unit of work is a "changeset", an entry in a write-ahead log. Where a git commit points at a tree, a changeset stores the list of files changed relative to its first parent plus content-addressed pointers to compressed file contents in blob storage. Changesets are created server-side and are available everywhere instantly. Moving a ref is a compare-and-swap on a single Spanner row, separate from creating changesets.

Because a changeset records only what changed, answering "who last edited this line" needs extra structures. Anthropic calls them derived data: file blame, path history and skip lists for the commit graph. Each type is defined recursively from its values for the changeset's parents. That makes it easy to add new types (the post mentions copy detection and path-based search), choose eager or deferred computation, and optimize without changing the client.

The checkout path

Scion's client, scn, differs from git's fetch protocols. It does not tell the server what it already has. Starting from a root tree, it checks the local store for missing trees, requests them recursively, then repeats for blobs. Every request is for an immutable object, so any cache can answer it, and there is no multi-gigabyte packfile response.

A node-level daemon, scion-daemon, stores objects for all jobs on the node and talks to regional scion-cache servers, which stream objects from memory in the daemon's disk format. When a cache misses, it asks the authoritative scion-server, which reads from Spanner or cloud storage. All three answer identical RPCs, but Anthropic enforces strict tiering so a failing regional cache cannot overwhelm the servers above it.

Each tier reportedly keeps a cache hit rate above 99% and needs no long-lived state. The result, in Anthropic's words, is a footprint 200x smaller than the old mirror fleet, checkouts two orders of magnitude faster, and a 25% CPU capacity win for CI.

What did Claude do in the build?

This is the part many readers will quote. Anthropic says it started Scion around the time Claude Mythos Preview and Claude Tag became available internally. Earlier in the year, engineers had largely handwritten the first version of the git-to-Scion ingestion pipeline. Then they gave an early internal snapshot of Claude Mythos Preview the job of rewriting it, with no further instructions. The result, per the post, "consumed 20x less memory and was 4x faster" while preserving implicit invariants around ingestion ordering and data structures.

For background on that model family, see our posts on Claude Mythos Preview and the Glasswing program and the Fable 5 and Mythos 5 launch. Claude Tag is the Slack-based assistant covered in our Claude Tag guide and top use cases.

Anthropic lists other lessons:

• Small teams can move fast. Seven people built Scion, Antique and half a dozen related systems and completed the migration in five months while merge volume grew tenfold.
• Engineers still steer. All the engineers involved would now rate Claude as better at writing code than themselves, but their job was often to tell Claude "no". Agents sometimes violate core constraints, for example by reading the commit log linearly instead of asking the code review tool when a change merged. Adversarial review can also be myopic and push Claude to over-engineer. Reviewers now examine the intent of a change instead of reading every line.
• Quality improved. Hermetic simulations of every non-trivial infrastructure interaction, fuzzing and rate limiting were built. Claude also found an algorithmic optimization to ancestry queries that missed an index, work Anthropic says would have taken an expert days or weeks.
• Security groundwork. Scion supports access control per repository and per directory, and the review tooling can express semantic constraints on approvals, such as separating comment-only changes from sensitive logic.
• Operations. "Superfan" Claudes watch a single component each, such as scion-daemon or the Antique merge queue, through telemetry and logs, alongside traditional alerts.
• Rethinking priors. A global-lock merge queue did not scale, and when thousands of changes can merge while tests run, CI changes meaning. Anthropic invested in post-merge and pre-deploy testing and accepts that concurrent changes can conflict, because Claude can usually fix conflicts faster than people can find them.

What should other teams take from this?

A merge conflict being untangled by a hook, representing how agent-scale source control handles concurrent changes to a monorepo

Anthropic is clear that its workload is unusual and that most organizations will not hit these limits soon. But it expects others using AI coding tools to feel similar pressure points. Several lessons apply at smaller scales.

1. Measure the human-scale assumptions in your pipeline. CI wait times, review queues, branch protection rules and mirror setups were all designed for people committing a few times a day. If you adopt agents, look at them first. Our comparison of Claude Code, Cursor and GitHub Copilot covers the tool side.
2. Make repository questions an API. Even without a new VCS, exposing blame, merge-base and history through a service avoids every job cloning the repo.
3. Revisit the merge queue. Post-merge testing with fast automated repair is a different risk model from a pre-merge gate. Decide deliberately.
4. Keep humans on intent. Anthropic's reviewers read intent, not every line, and still review every change request for the system.
5. Expect a market. Other vendors are working on the same problem. See our coverage of Cursor's Origin git hosting for AI agents. If you are new to monorepos, our monorepo primer and git beginners guide give the basics.

Caveats

• Company-reported numbers. The 200x, two-orders-of-magnitude and 25% figures come from Anthropic. No independent audit is cited.
• Not a product. The text we read does not announce a release of Scion or Antique for outside use.
• Specific infrastructure. Scion leans on Google Spanner and cloud blob storage. A team on different infrastructure would need different building blocks.
• Survivorship. The post describes a success; it says little about failed approaches or migration incidents beyond a few anecdotes.
• Git is not dead. Anthropic says git is the right design for most repositories.

What we are watching next

• Whether Anthropic open-sources Scion or Antique, or publishes protocol details.
• Whether GitHub, GitLab and other hosts announce server-centric or agent-aware features.
• Further Anthropic engineering posts, since the company says it could write a whole other post about Antique.
• Independent reports of teams hitting merge-rate limits with agents.

Related reading

• Claude Code vs Cursor vs GitHub Copilot
• Cursor Origin: git hosting for AI agents
• Claude Tag: Slack team AI guide
• Claude Mythos Preview and Glasswing
• What are monorepos?
• Jack Clark's RSI forecast for 2027

Details are accurate as of October 13, 2026. All Scion figures are from Anthropic's own post; we will update this page if the company publishes more.