Anthropic's Scion: Replacing Git for 30k Daily AI-Generated Merges

Git Overload at Anthropic

By May 2026 Anthropic was merging ~2,500 changes per day; by September that figure exceeded 30,000 — a 10× increase in four months. The monorepo’s main‑branch history approached 100 GB , compressed working copies exceeded 25 GB , and CI alone performed ~25 million checkouts daily. Naïve fetching would generate >600 PB of Git traffic per day. Existing mitigations (shallow clones, sparse checkouts, hundreds of internal mirrors) only delayed the inevitable: mirrors drifted further behind, history‑dependent operations became slower, and mirror storage exploded.

Why Git Could Not Scale

Git’s decentralized, offline‑first design assumes clients may be disconnected. At Anthropic every client — human or AI agent — is permanently online. The team realized they were using Git as a centralized system while carrying the overhead of full‑repository clones on every node.

Scion’s Six Design Principles

Clients always online — fetch data on demand, no full clone required.

Asymmetric client/server — all history queries, blame, commit creation, merge, rebase happen server‑side; clients keep only a bounded object cache and a sparse working copy.

Full source‑control service via API — every query is exposed programmatically, enabling CI tasks without a local repo (e.g., automated bisect and rollback pipelines).

Horizontal scalability — data is distributed; no single materialized repository exists anywhere , not even on servers. No packfiles, no repository maintenance.

Cheap, incremental, lock‑free commits — commits, rebases, merges occur server‑side; cost depends only on change size, not repo size. Branches and tags are discouraged because global consensus harms scalability.

Optional, inherently sparse working copies — CI can request diffs without checkout; when checkout is needed, only required directories are fetched, with virtualized file access.

Internal Mechanics

Data Model: Changesets + Derived Data

The atomic unit is a changeset (write‑ahead log entry) storing the list of changed files relative to its first parent plus content‑addressed blob pointers. Unlike Git commits, changesets are created server‑side and instantly globally visible — no packfile negotiation, no locks, no cross‑server coordination, no ref movement beyond a single Spanner compare‑and‑swap.

Derived data (blame structures, path history, commit‑graph skip lists) is built recursively from parent changesets. This allows:

Adding new indexes anytime (e.g., copy detection, path search).

Choosing eager vs. lazy computation per index.

Internal restructuring without affecting clients.

Three‑Layer Caching: Checkout 100× Faster

The scn client protocol differs fundamentally from Git:

Clients request desired trees/blobs, never advertise what they already have.

Recursive fetch from root tree down to missing blobs.

Every request targets an immutable object → any cache layer can serve it.

No multi‑GB packfile responses → natural resumability.

Sparse/virtualized checkout requires no special support — unwanted trees are simply not requested.

The cache hierarchy:

Client daemon starts from a periodically refreshed snapshot, talks only to its regional scn-cache.

Cache servers stream objects in the exact on‑disk format clients expect — no delta computation, no “what’s missing” logic.

All layers use the same RPC but enforce strict isolation to contain failure domains.

Measured Outcomes

Every cache layer hit rate >99%.

Scion infrastructure CPU/memory 1/200 of the previous Git mirror fleet.

CI and research checkout latency dropped two orders of magnitude (minutes → seconds).

CI alone saved 25% CPU capacity .

Clients and caches no longer perform repository maintenance.

Claude as Both Problem and Solution

Mythos Rewrite: 20× Memory Reduction, 4× Speedup

The initial Git‑to‑Scion ingestion pipeline was hand‑written. When given to an early Claude Mythos Preview with no extra instructions, it rewrote the entire pipeline, preserving all implicit invariants while cutting memory usage 20× and boosting throughput 4×.

7 Engineers, 5 Months, 10× Merge Growth

A 7‑person team delivered Scion, the code‑review tool Antique, and half a dozen auxiliary systems while daily merges grew 10×. Such a migration would traditionally take years and many more engineers.

Engineer Role Shift: Design Decisions and Saying “No”

Engineers now focus on cross‑system architecture, design trade‑offs, and frequently rejecting Claude’s suggestions (e.g., linear log scans instead of querying the review service, over‑defensive validation). Reviews still happen on every change, but inspect intent rather than line‑by‑line code.

“Superfan” Agents: Per‑Component Guardians

Each component gets a dedicated Slack channel with a Claude‑powered “superfan” that monitors telemetry and logs 24/7, detecting anomalies traditional alerts miss.

Rethinking the Merge Queue

With hundreds of concurrent merges, a global merge‑queue lock is infeasible. Anthropic shifted to post‑merge, pre‑deploy automated testing , accepting that conflicts may arise but noting Claude resolves conflicts faster than humans detect them.

Context: Not a General Git Replacement

Anthropic explicitly states:

Scion targets only ultra‑large monorepos with tens of thousands of engineers/agents committing at high frequency.

No plans to offer externally; it requires tightly coupled review, search, and CI tooling and is highly customized.

Their compute budget (token spend) is an outlier.

Prior art exists:

Piper (Google): Centralized; Bigtable → Spanner backend; “cloud client” keeps local copies tiny (avg <10 files).

Sapling (Meta): Scalable, user‑friendly; client compatible with Git repos.

Scion (Anthropic): Designed for “always‑online agents”; changeset + derived data; server‑centric.

(Piper data from 2016 ACM paper: ~25k developers, ~16k human + ~24k bot commits/day. Different era/scope, but proves massive monorepos are not new — the novelty is AI as primary author.)

Feeding Lessons Back to Git

Anthropic aims to contribute experience to the Git ecosystem:

Git servers need not mirror client architecture; novel server designs are possible.

Platforms could expose Scion‑style full server RPCs, potentially standardized across hosts.

Negotiation protocol could evolve; sparse and shallow features should compose better.

They acknowledge Git’s 20‑year journey to serve millions and express interest in collaborating with GitHub, GitLab, and the open‑source community.

Takeaway

When code generation cost approaches zero, every human‑speed bottleneck in the SDLC becomes the next constraint — version control first, then build, CI, merge queues, code review. Anthropic predicts this pattern will spread widely within 6–12 months. Teams should ask: how much CI time is spent fetching code? Does our toolchain assume human velocity? Which link breaks when agent count grows 10×?