Scion: Agent-Scale Source Control
Scion is Anthropic’s in-house version control system, built to replace git for their monorepo and migrated into production in five months in 2026. The engineering post that introduced it (2026) is a detailed account of a source-control system designed around the assumption that nearly every client is an AI agent or CI job rather than a person with a laptop. The same team shipped a code review surface (Antique), code search, and a source-control IAM system in the same window. 1
Why git stopped fitting
Anthropic’s monorepo merge rate went from about 2,500 changes per day in May 2026 to over 30,000 per day in September 2026, and the post describes latent demand for merging code as “practically infinite” — every bottleneck removed produces more code. The main-branch history approaches 100 GB, a compressed working copy exceeds 25 GB, and CI alone performs on the order of 25 million checkouts per day; fetched naively that would be over 600 PB of git traffic daily. The standard workarounds (shallow clones, sparse checkouts, promisor remotes, blob-storage snapshot seeds, and several hundred internal git mirrors at peak) held for a while and then strained as the merge rate grew: seeds drifted from the tip of main, and history-dependent operations like diff and blame grew fragile on partial clones. 2
The diagnosis: git’s design serves distributed, offline work — every clone complete and self-contained — and Anthropic was running git as a centralized system whose clients (agents and jobs) are online by definition. The monorepo prior art they built on is Google’s Piper and Meta’s Sapling; Google’s published account of Piper documents the same centralized, trunk-based shape at one billion files, 35 million commits, and roughly 16,000 human plus 24,000 automated commits per workday, distributed across ten datacenters on Spanner. 3
Design principles
The post states six principles (paraphrased and compressed):
- Clients are always online. Protocols assume a server that is always reachable; clients fetch data when they need it.
- Client-server asymmetry. The server answers history and blame questions, creates commits, performs merges and rebases. The client keeps a bounded local object cache, lays out the working copy, and monitors the filesystem.
- The source control service is a platform. Every client query is also an API: CI jobs, automated bisect, and revert pipelines work without holding a local repository at all.
- Everything horizontally scalable. Repository data is distributed with no fully materialized copy anywhere, including on the server; there are no packfiles and no repository maintenance.
- Commits are cheap, incremental, and lock-free. Commit cost scales with the size of the change rather than the size of the repo. Refs (branches, tags) are discouraged beyond main and release branches because global state every server must agree on is a scaling problem — a ref move is a compare-and-swap on a single Spanner row.
- The working copy is optional and sparse. Sparse checkouts contain only requested directories; virtualized checkouts materialize files on demand. Writes often skip the checkout entirely and go through the API.
How Scion works
Data model. The unit of work is a changeset: an entry in a write-ahead log storing the list of files changed relative to its first parent, with content-addressed pointers to compressed file contents in blob storage. A git commit stores a pointer to a tree; a changeset stores the delta itself. Changesets are created server-side and become available everywhere instantly. Questions like “who last edited this line” are answered by derived data — blame structures, path history, commit-graph skip lists — computed from changesets through one generic recursive mechanism (a changeset’s derived value is computed from its parents’ values). Derived data is computed eagerly or lazily per type, and clients never see its internals, so structures can be swapped without client changes. 5
Fetch architecture. Scion’s negotiation runs on wants rather than haves: starting from a root tree, the client recursively requests trees and blobs it is missing. Every request names an immutable object, so any cache tier can answer it, and the fleet looks like traditional tiered caches: a per-node scion-daemon, regional scion-cache servers streaming objects from memory, and authoritative scion-servers reading Spanner or cloud storage. All tiers answer identical RPCs; tiering is enforced to isolate failure domains. Each tier holds a cache hit rate above 99%, the infrastructure footprint is 200x smaller than the git mirror fleet it replaced, checkouts are two orders of magnitude faster (seconds instead of minutes), and CI alone recovered 25% CPU capacity. 6
Git’s own object store already shows the mechanism underneath: a content-addressed key-value store where blobs, trees, and commits are immutable objects named by the hash of their contents, and branches are just mutable pointers into the object graph. Scion keeps that property (“a piece of data never changes once it’s stored”) and drops git’s requirement that every participant hold the whole graph. 7 8
Building it with Claude
A team of seven engineers built Scion and Antique plus related systems and migrated the monorepo in five months while merge volume grew 10x. An early hand-written git-to-Scion ingestion pipeline was rewritten by an internal Claude Mythos Preview snapshot with no further instructions: 20x less memory, 4x faster, all implicit ingestion-ordering invariants preserved. 9
The post is explicit about where the humans stayed load-bearing. Engineers supplied system-level understanding and design tradeoffs, and “very often… the role of the engineers was to tell Claude ‘no’” — agents would violate core system constraints to satisfy patterns (e.g. brute-forcing merge-lookup by linearly scanning the commit log instead of asking the review tool), and adversarial review could be myopic, producing over-engineering in response to hypothetical concerns. Change review shifted accordingly: team members now examine the intent of a change rather than reading every line of code, and the Antique review tooling can express semantic constraints on approvals — comment-only changes are routed differently from sensitive logical changes. 10
Operational practice moved too: dedicated monitoring agents (“superfans,” one per component, watching telemetry and logs in Slack channels) catch subtle issues that conventional alerts miss, and the classic merge queue gave way — a global repository lock makes little sense when hundreds of changes merge while tests run — to post-merge and pre-deploy testing, with concurrent conflicts fixed by Claude faster than humans spot them. 11
What transfers
Anthropic’s stated position: Scion is not a git replacement for general use, and it only makes sense for enormous monorepos with thousands of engineers or swarms of prolific coding agents. The company’s token budget for internal use is unusual, and the surrounding components (review, search, CI) are highly bespoke. What they argue can transfer to git: server-side RPCs at the forge (“a git server doesn’t have to work the same way as a git client does”), richer fetch negotiation, and composition of the existing sparse/shallow features. 12
The merge-rate numbers are a first-party, unverifiable self-report, and the claims about small-team rapid development are a prediction; treat the mechanism descriptions as authoritative and the trend claims as Anthropic’s outlook (hence confidence: medium).
Connections
- content-addressed-storage — the property Scion leans on hardest: immutable, hash-named objects let any cache answer any request without coordination; the same shape as git’s object store, the Nix store, and IPFS’s Merkle DAG.
- ai-economic-growth-complementarity — “engineers are no less valuable, but their work is changing” is the complementarity frame in one sentence: Claude supplies code-writing intelligence, humans supply design judgment and the veto.
- ai-research-productivity — the same execution/judgment split measured inside economics research: AI narrows execution gaps and widens the premium on senior judgment.
- reproducible-builds — Scion’s CI story (25 million checkouts a day, hermetic simulations) is the source-control half of build infrastructure at agent scale.
- ai-peer-review — review load shifting from line-reading to intent-checking is the code-review version of what happens to peer review when AI writes the drafts.
Sources
- 2026 — Redesigning Source Control at Anthropic
- Rachel Potvin and Josh Levenberg 2016 — Why Google Stores Billions of Lines of Code in a Single Repository
- Scott Chacon and Ben Straub 2014 — Git Objects (Pro Git)