How Scion Works: Source Control for 30,000 Merges a Day

Anthropic’s engineers now land more than 30,000 merges a day in the company monorepo, roughly one merge every three seconds around the clock. Agents write most of that code. The system keeping up is called Scion, and Anthropic’s engineering team published its design on October 13, 2026.

The problem: git infrastructure sized for humans

The raw numbers would strain any version control system. Main-branch history sits at almost 100 GB, a compressed working copy passes 25 GB, and CI alone performs about 25 million checkouts a day. Serving those checkouts with plain git fetches would move over 600 PB of traffic daily. At its peak Anthropic ran several hundred internal git mirrors, plus shallow clones, sparse checkouts, promisor remotes, and blob-storage seeds to blunt the load.

Each workaround decayed. Seed files drifted away from the tip of main, and operations like diff and blame got slower and stranger on partial clones. Meanwhile the client mix kept shifting toward agents and CI jobs that are online by definition, while git spent its complexity budget on something they never do: working offline against a network of distributed peers.

The growth curve explains the urgency. Roughly 2,500 merges a day in May 2026 became more than 30,000 by September, a twelvefold jump in four months, and the curve kept bending upward after that.

The team’s diagnosis was blunt: “The bottleneck, now, is all of the developer infrastructure built for human scale.” Removing each bottleneck only uncovered the next one, because the appetite for merging code had no ceiling. Every constraint the team lifted immediately turned into more merging, since agents are always ready with the next change.

The Scion architecture: thin clients, one authoritative server

Scion inverts git’s division of labor. The server side owns everything heavy: history, blame, commits, merges, rebases. The client, a tool called scn, caches objects, lays out working files, and watches the filesystem. Because agents and jobs are always connected, the server can assume every client is online, which dissolves the hardest problems in distributed version control.

A chain of tiers stands between client and server, and every tier answers the same RPCs. Each machine runs a scion-daemon object store, a regional scion-cache holds trees and blobs, and the authoritative scion-server sits on Spanner for refs and changesets plus cloud storage for file content. Cache tiers sustain hit rates above 99 percent, and each tier isolates the failure domain behind it. The server side also scales horizontally, so a spike in agent traffic means adding server capacity rather than redesigning anything.

Sync is want-based: a client requests the trees and blobs it is missing, recursively from the root tree, in a transfer that can resume mid-stream. There are no packfiles and no repository maintenance. In the team’s words, “There is no fully materialized copy of the repo anywhere, even on the server.”

Even branches get minimalist treatment. Refs are discouraged outside main and release branches, and moving a ref is a single compare-and-swap on one Spanner row. Everything a developer tool needs, from blame to search, is reachable the same way, which is what lets the client stay small.

Changesets: commits as a write-ahead log

The unit of work in Scion is a changeset, and it behaves like a write-ahead log entry. It records the files changed relative to a first parent, plus content-addressed pointers to the new blobs. Appending one is cheap, incremental, and lock-free on the server, which is what makes 30,000 merges a day survivable.

Everything else is derived. Blame, path history, commit-graph skip lists, copy detection, and path-based search indices are all computed by one generic recursive mechanism, eagerly or lazily as needed, with the internals hidden from clients. A working copy is something a client can skip entirely or trim to just the files it touches, so a CI job can request a diff over the API and never check anything out.

Review and CI when the merge queue stops making sense

Review runs through Antique, an in-house code review surface with a merge queue and approval rules able to distinguish a comment-only change from a sensitive logical one. It shipped alongside separate tools on the same source-control API: code search, an IAM system that grants permissions per directory, and automated bisect and revert pipelines. The telling part is what none of them attempt: holding a global lock while tests run.

When hundreds or thousands of changes can merge during a single test run, pre-merge validation of the exact final state stops existing as an option. Scion’s answer is automated testing after merge and before deploy. Conflicts from concurrent changes still occur, and per the post, “Claude can typically fix these conflicts faster than humans can even identify them.”

Humans set the bars instead of moving the pieces. Review inside Anthropic is adversarial by default, effective, and, in the team’s own telling, prone to myopia that skilled engineers have to correct. “Very often, we found that the role of the engineers was to tell Claude ‘no.'”

The insight: agents made offline mode optional

Git’s core bet is that any peer may go offline, so every peer must be able to do everything. That bet served the industry for twenty years. Anthropic’s heaviest client is an agent that is necessarily online, so the feature git works hardest to provide became the feature this workload never touches. Drop offline distribution and version control collapses into something far simpler: a database with an API, plus a thin file cache on each client.

The idea has pedigree. Google’s Piper and Meta’s Sapling with its Mononoke server walked this centralized road before, and Anthropic credits that lineage for the derived-data design. One caveat travels with it: “Scion is by no means a suitable replacement for git for general use.”

What it means outside Anthropic

Anthropic expects these pressures to become commonplace within six to twelve months as agent-written code spreads. A category may already be forming: git-ai, an open-source project described as git designed for AI agents, passed 1,000 GitHub stars within days of its October 15 debut under its earlier name open_scion.

Until an agent-native system is publicly available, the practical substitutes are the ones Claude Code users already run: one worktree per agent for isolation, and a review step where the human still says yes or no. We covered the worktree pattern for parallel agents if you want the hands-on version.

For a team running a handful of agents today, the takeaway is not Scion itself. It is the posture: isolate each agent’s work, keep diffs small enough to review honestly, and treat post-merge testing as a first-class stage instead of a fallback.

Scion optimizes one variable: throughput for clients that never log off. It pays for that with centralization, an online-only assumption, and a five-month build by a seven-person team. At human-scale merge counts, git remains the right answer. The transferable idea is the design posture: when every client is always online, your version control can be a database.