Overhauling Source Control at Anthropic

Published: October 13, 2026

As our daily merge volume surged by more than a factor of ten, our source control system evolved from a utility into our primary development bottleneck. This article details our five-month journey migrating to a proprietary version control system.

The Shift to Agentic Scale

At Anthropic, the primary constraint on building systems or conducting research is no longer the act of writing code. Thanks to Claude, we can now:

• Autonomously iterate through research loops.
• Perform micro-optimizations on intricate programs.
• Construct entirely new services from scratch.

This has happened at a velocity and magnitude previously unseen. Consequently, the bottleneck has shifted to the infrastructure designed for human-scale agent-scale development: specifically, CI, builds, and source control.

The Growth Explosion

The scale of our activity increased dramatically in 2026:

We anticipate this trajectory will continue. The demand for merging code is essentially infinite; every time we resolve a bottleneck, the volume of produced code increases to fill the new capacity.

Introducing Scion

To sustain this growth, we developed Scion, an internal version control system (VCS), and transitioned our entire monorepo from git within five months. Alongside Scion, we deployed several supporting tools:

1. Antique: A bespoke code review interface.
2. Code Search: High-performance indexing for the monorepo.
3. IAM System: A sophisticated identity and access management layer for source control.
4. Landing Tools: Novel mechanisms for managing and merging massive volumes of reviewed code.

The Irony: Claude's proficiency in coding was the catalyst that broke our existing tools, but it was also the primary engine that allowed us to build a high-quality, scalable replacement so rapidly.

Why Git Failed Us

While git is the industry standard, its architecture is fundamentally decentralized. Every clone is a standalone repository capable of computing diffs and reading history offline. For most projects, this is ideal. For our monorepo, it was a liability.

The Scale Problem

Our repository reached a size where the decentralized model collapsed:

• Main Branch History: $\approx 100\text{ GB}$
• Compressed Working Copy: $> 25\text{ GB}$
• Daily Checkouts (CI): $\approx 25\text{ million}$

If we had performed these checkouts naively, the traffic would have been astronomical: $25,000,000 \text{ checkouts} \times 25 \text{ GB} \approx 625 \text{ PB/day}$

Failed Mitigations

We attempted every available git optimization:

• Shallow clones
• Sparse checkouts
• Promisor remotes
• Internal git mirrors (hundreds of them)
• Repository "seeds" (snapshots in blob storage)

Despite these efforts, the system became fragile. Seeds grew stale too quickly, and maintaining the integrity of diff and blame operations on partial clones required excessive manual effort.

A New Philosophy: Online-First

We realized that while git is designed for offline work, almost all our clients—agents and CI jobs—are always online. We decided to stop fighting the centralized nature of our workflow and instead embrace it.

Scion vs. Git: Architectural Comparison

The Scion Architecture

Core Principles of Scion

1. Server-Side Intelligence: In Scion, the server is the brain. It handles the heavy lifting—creating commits, performing rebases, and calculating file history.
2. Thin Clients: The client is primarily an ergonomic layer. It manages the local working copy, monitors the filesystem, and maintains a small cache.
3. Programmatic Access: Because the VCS is a service, all queries are exposed via API. This allows tools to ask questions about the repo without needing a local clone.

For example, an automated revert pipeline can now trigger a request like this:

// Conceptual Scion API call to find the author of a change
POST /v1/source/blame
{
  "file": "services/llm_gateway/main.py",
  "line": 452,
  "revision": "head"
}

This API-driven approach makes internal tools—such as automated bisecting—practical at a scale that would be impossible if every job required a local repository.