Scion is Anthropic’s in-house, server-centered version-control system. Anthropic says it moved its monorepo from Git to Scion over five months, while describing Scion as unsuitable for general-purpose use. The company laid out the migration and design in an engineering account published October 13, 2026, and updated October 15. That makes Scion an answer to Anthropic’s workload—not a drop-in Git option for every development team.
Why Anthropic moved its monorepo
Anthropic reported that its average daily total rose from about 2,500 merged code changes in May 2026 to more than 30,000 per day as of September. Those are counts of merged changes, not a count of new features or a measure of code quality.
The repository’s scale also shaped the problem. Anthropic said its main-branch history was almost 100 GB, its compressed working copy exceeded 25 GB, and continuous integration (CI) performed about 25 million code checkouts a day. The company estimated that fetching the repository naively for that checkout volume would generate more than 600 petabytes of Git traffic per day—a hypothetical estimate, not measured traffic.
Before Scion, Anthropic used shallow clones, sparse checkouts, promisor remotes, internal Git mirrors, and repository snapshots. At its peak, it ran several hundred mirrors. Scion changes the model: instead of having each client carry a complete repository, it serves source-control operations and lets clients request the data they need.
How Scion handles changes without a full local repository
A client keeps a bounded local cache of repository objects and manages its working files. Scion’s servers handle operations such as creating commits, merging, rebasing, and querying history. Sparse checkouts retrieve selected directories; virtualized checkouts materialize files on demand. Some CI and tool workloads can use source-control APIs without creating a local checkout at all.
A Scion changeset records which files changed relative to its first parent. It points to compressed file contents stored separately and addressed by their content, rather than bundling the repository into Git-style packfiles. Anthropic also describes separate derived data for queries such as blame, path history, and commit graphs.
The service is arranged in layers: a node-level scion-daemon, regional scion-cache servers, and authoritative scion-server services. Anthropic reports cache hit rates above 99% at each tier. One coordination detail matters: moving a reference uses a compare-and-swap operation on a single Spanner row, so the system’s server-centered design does not mean every operation avoids coordination.
What Anthropic’s performance figures measure
Anthropic reports that Scion’s infrastructure requires 200 times less CPU and memory than the company’s previous Git-mirroring infrastructure. That comparison is about Anthropic’s old mirror setup, not Git deployments in general. The company separately reports that checkouts became two orders of magnitude faster—seconds rather than minutes—and that Scion increased CI CPU capacity by 25%.
Those figures describe Anthropic’s own systems. They show the results the company reports for its unusually large repository and workload; they are not a performance guarantee for another team’s hardware, codebase, or development process.
Who Scion is for—and how Anthropic handles conflicts
Anthropic says Scion is not a suitable general-purpose replacement for Git. A broad offering would be difficult to adopt, the company says, because organizations would also need to migrate connected development systems such as code review, code search, and CI. Anthropic describes Scion as an internal system for very large repositories and workloads involving many engineers or agents.
High merge volume also does not remove the need to check whether changes work together. Anthropic says it has not been able to reproduce a global repository lock in its merge queue at agent scale. It instead invested in automated tests after merging and before deployment, while acknowledging that concurrent changes can conflict. A successful merge, by itself, is not a guarantee that the software behaves as intended.
