Anthropic's Scion Replaces Git for Its Agent-Scale Monorepo

Introduction

On October 13, 2026, Anthropic's engineering blog published "Redesigning source control at Anthropic," describing Scion, an in-house version control system that replaced git for the company's monorepo. According to the post, Anthropic averaged around 2,500 merged code changes per day in May 2026 and merged over 30,000 per day as of September. The team says it fully migrated the monorepo from git to Scion in five months.

The post frames the problem as one of infrastructure built for human scale. In Anthropic's words, coding is no longer the bottleneck; source control, builds and CI are. Scion is internal only, and Anthropic says it would be difficult to offer in a form broadly useful to other organizations, so this review treats it as a case study in architecture rather than a product evaluation.

Why git strained

Anthropic's post notes that git is a decentralized system in which every clone is a complete repository, a design it calls right for the vast majority of repositories. For this monorepo, the figures it reports are large.

Shallow clones, sparse checkouts, promisor remotes, mirrors and blob-storage seeds bought time, the post says, but became harder to operate as the merge rate rose. Anthropic's observation was that nearly all of its clients are agents and jobs that are online by definition, so git's offline-first properties were working against scale.

Six design principles

The post lists six principles and acknowledges prior art in Google's Piper and Meta's Sapling.

1. Clients are always online and fetch data when they need it.
2. Client-server asymmetry: the server answers history and blame questions and performs commits, merges and rebases, while the client keeps a bounded local object cache and lays out the working copy.
3. Every source control query is also exposed via API, so many jobs need no local repository.
4. Everything is horizontally scalable, with no fully materialized copy of the repository anywhere and no packfiles to maintain.
5. Commits are cheap, incremental and lock-free, with refs discouraged except for main and release branches.
6. The working copy is optional and sparse by design, with sparse and virtualized checkouts.

How Scion works

The unit of work is a "changeset," an entry in a write-ahead log. Instead of a pointer to a tree, a changeset stores the files changed relative to its first parent, plus content-addressed pointers to compressed contents in blob storage. Moving a ref is a compare-and-swap on a single Spanner row, separate from creating changesets. Data such as blame, path history and commit-graph skip lists are "derived data," computed through one generic recursive mechanism that can be eager or deferred per type.

For checkouts, the client talks to scion-daemon on each node, which talks to regional scion-cache servers, which fall back to scion-server instances reading Spanner or cloud storage. All tiers answer the same RPCs, but Anthropic strictly enforces the tiering to isolate failure domains. Because requests target immutable, content-addressed objects, any cache can answer them.

Reported results

Anthropic says each tier holds a cache hit rate over 99%, the infrastructure footprint is 200x smaller than the previous git mirroring setup in CPU and memory, and CI and research jobs check out code two orders of magnitude faster, in seconds rather than minutes. CI alone saw a 25% CPU capacity gain. These are self-reported figures with no independent benchmark.

Building it with Claude

A team of seven built Scion, the Antique code review tool and about half a dozen related systems. In one example, an early internal snapshot of Claude Mythos Preview rewrote the handwritten git-to-Scion ingestion pipeline, producing a version Anthropic says used 20x less memory and ran 4x faster. Engineers often had to tell Claude "no" when agents violated system constraints. Humans still review every change request, but examine intent rather than every line. Engineers also run Claude "superfans" in Slack, each watching one component through Claude Tag.

The post also describes dropping the global-lock merge queue in favor of post-merge and pre-deploy automated testing, and notes Scion supports directory-level permissions.

Limits and outlook

Anthropic says Scion is not a suitable general replacement for git, would require its own code review, search and CI, and would be difficult to package for other organizations. Instead it hopes GitHub, GitLab and the open-source community can apply ideas such as server-side RPCs and different negotiation protocols to git, and it anticipates this class of problem becoming more common over the next six to 12 months.

Conclusion

This is a detailed, candid engineering account that is most useful to teams running very large monorepos or agent-heavy pipelines. The figures are vendor-reported and the system cannot be tried, so the lasting value lies in the design ideas.

Editor's Verdict

Anthropic's Scion Replaces Git for Its Agent-Scale Monorepo is a worthwhile read within the Claude space, as an engineering case study rather than a product to adopt.

The strongest case for paying attention is that the post reports concrete scale figures, such as almost 100 GB of main-branch history and on the order of 25 million daily CI checkouts. Reinforcing that, it explains the architecture in enough detail, from changesets to the three cache tiers, for other teams to borrow ideas. The broader signal worth registering is straightforward: merge volume rising from around 2,500 to over 30,000 per day shows how agent-written code shifts the bottleneck from writing code to the infrastructure around it. On the other side of the ledger, the system is internal only, and Anthropic says a public version would be difficult to make broadly useful, so readers cannot try or adopt it. Layered on top of that, performance gains such as the 200x smaller footprint and 25% CI CPU savings are self-reported without independent benchmarks.

For platform and developer-infrastructure engineers running very large monorepos or heavily agent-driven CI, this is worth reading closely for the design ideas. For teams whose git setup is not under strain, the safer posture is to bookmark it and revisit if merge volume starts to outgrow their tooling.