Scion vs Git After Anthropic’s Agent Merge Spike

Agent-scale monorepos now sit between classic Git workflows and a short list of centralized systems built for enormous codebases, and Anthropic’s October 13 engineering post put that contest in public view by documenting Scion after a full monorepo migration. Daily merges there rose from about 2,500 in May 2026 to more than 30,000 in September, according to the company’s Redesigning source control at Anthropic post and the matching AnthropicAI note on X.

Classic Git workloads

Git still wins where every clone is a full offline peer: diffs, history, blame, and checkouts without a reachable server. Anthropic’s post treats that as the right default for most repositories, then shows where a single authoritative monorepo stops fitting the model.

Their main-branch history alone is almost 100 GB, a compressed working copy tops 25 GB, and CI performs on the order of 25 million checkouts per day. Fetched naively, that is more than 600 PB of Git traffic per day, numbers Anthropic publishes in the same engineering article.

They ran the usual mitigations: shallow clones, sparse checkouts, promisor remotes, internal mirrors, and blob-storage seeds. At peak they operated several hundred Git mirrors. That bought time, then became harder to run as merge rate climbed and seeds drifted from tip of main.

Git remains the portable standard. At Anthropic’s reported agent throughput it was the bottleneck, not the coding layer.

Scion server asymmetry

Scion is Anthropic’s in-house VCS, built and used to migrate the monorepo off Git in five months, as stated in that engineering post. Clients stay online. The server creates commits, merges, rebases, history answers, and blame. The client keeps a bounded object cache, lays out a sparse or virtualized working copy, and does little computation alone.

The unit of work is a changeset in a write-ahead log: changed files relative to the first parent, plus content-addressed blobs. Commits are cheap, incremental, and lock-free on the server. Refs are discouraged except main and release lines. Derived data (blame, path history, graph skip lists) is computed recursively so new indexes can land without client changes.

Anthropic reports a Scion footprint about 200x smaller in CPU and memory than the prior Git mirroring stack, checkouts in seconds rather than minutes (two orders of magnitude), and a 25% CI CPU capacity win, all in the same engineering write-up. A team of seven shipped Scion plus Antique (code review) and related systems while daily merges rose roughly 10x.

Claude both created the merge pressure and accelerated the build. An early Mythos Preview rewrite of the git-to-Scion ingestion pipeline cut memory about 20x and ran about 4x faster, per Anthropic’s account. Scion is not offered as a general Git replacement. Anthropic says the design only fits enormous monorepos with huge engineer counts or agent swarms, and that shipping a public, pleasing-everyone product would be hard because review, search, and CI are bespoke too.

Scion is the clearest public blueprint for always-online, API-first source control under agent load. It is still a private stack, not a forge you can point a laptop at tomorrow.

Piper monorepo lessons

Anthropic explicitly names Google’s Piper as prior art for huge-monorepo source control when listing principles for Scion. Piper’s public reputation is the opposite of Git’s peer clone: one authoritative tree, clients that do not carry the whole universe, and scale aimed at a company-sized codebase rather than offline hobby repos.

No Piper price card or checkout latency figure appears in Anthropic’s post. The useful signal is the design family: server-held truth, clients that fetch on demand, and tooling that assumes connectivity.

Piper proves centralized monorepo VCS can work at Google scale. Outside Google it remains a reference, not a product you buy.

Sapling prior art

Meta’s Sapling is the other system Anthropic cites beside Piper. Sapling’s public positioning has long been scalable workflows and friendlier client ergonomics while still talking to large repos, including Git interoperability in Meta’s open materials over the years.

Anthropic does not publish a Sapling-versus-Scion benchmark table. The citation is about hard-won monorepo lessons, not a bake-off score. Sapling’s differentiator in this field map is an available lineage of client and server ideas that other teams can study without Anthropic’s token budget or Spanner-backed internals.

Sapling is the nearest named, study-able cousin for teams that want monorepo scaling without inventing a full private forge on day one. It still is not Anthropic’s agent-first, changeset-and-API stack.

Shared forge RPC layer

None of these options is a portable, vendor-neutral “agent source control” you can adopt the way you adopt Git. Git strains first under Anthropic’s published volumes. Scion solves that class of load inside Anthropic and stops at the company wall. Piper and Sapling show the centralized and scalable-client traditions, not a drop-in standard for every forge.

Anthropic’s own ask to the wider ecosystem is narrower than open-sourcing Scion: keep Git’s model, but let servers diverge from clients, expose comprehensive server-side RPCs (ideally in a standardized way across forges), and make sparse and shallow features compose cleanly, as they write in the closing sections of Redesigning source control at Anthropic.

If your merge rate is still human-shaped, stay on Git and invest in mirrors, sparse checkouts, and server-side query APIs. If agents are already multiplying landings the way Anthropic’s May-to-September curve describes, treat Scion’s published principles as the checklist for your forge and CI, not as a repo format you should rewrite from scratch this quarter.