# Anthropic's Homegrown Source Control: Scion

![](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-cover.png)

On October 13, 2026, Anthropic published an engineering blog post titled *Redesigning source control at Anthropic*. The official write-up says the company built its own source-control system, **Scion**, and fully migrated its monorepo off git in about five months. In the same window it also shipped a code-review surface called **Antique**, code search, a source-code permissions model, and tooling for landing large volumes of already-reviewed code. This piece focuses on Scion. The team behind Scion, Antique, and related systems is about seven people.

The headline numbers, as stated in the official post: daily merges averaged about 2,500 in May 2026 and exceeded 30,000 by September—more than a tenfold rise—with effectively unbounded merge demand. A peak callout next to their chart marks one day (September 9) at 30,401 merges. That figure is a chart annotation; this article did not independently verify it.

For anyone using agents to write code, the post reads more like a field report on *where the bottleneck moved*. Anthropic writes that coding itself is no longer the bottleneck; the bottleneck has shifted to source management, builds, and CI designed for human scale.

![Daily merge volume](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-merges-per-day.png)

*Figure: Daily merge volume (January–September 2026). Source: Anthropic Engineering · 2026-10-13; peak 30,401 is a chart annotation.*

### Where the pressure came from

Anthropic's monorepo size comes with a few hard numbers in the official post: main-branch history alone is nearly 100GB; a compressed working copy exceeds 25GB; CI alone does about 25 million checkouts per day (excluding developer machines, agent sandboxes, and research jobs). A naive full fetch, they estimate, would mean hundreds of petabytes of git traffic per day (the original says more than 600 PB).

They tried the usual mitigations: shallow clones, sparse checkout, promisors, internal mirrors, repository seed snapshots, and more. At peak, internal git mirrors numbered in the hundreds. Mirrors bought time, but once merge rates climbed, seed snapshots fell further and further behind the tip of main; history-dependent operations like diff and blame were also awkward on partial clones.

![Typical git mirror scaling architecture](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-git-mirrors-setup.png)

*Figure: Typical git mirror scaling architecture. Source: Anthropic Engineering · 2026-10-13.*

Their conclusion: they had been treating git as a centralized authority all along, while the vast majority of clients were agents and jobs that were already online. The full local replica designed for offline, distributed use was what held scaling back.

### Design principles

The official post lists several starting points that differ from git (and notes lessons from Google Piper and Meta Sapling):

1. **Clients are online by default.** They do not keep a full repository copy so work can continue offline; data is fetched from the server when needed.
2. **Clients and servers are asymmetric.** History, blame, commits, merges, rebases, and similar work happen on the server. Clients maintain a bounded local object cache, materialize the working copy, watch the filesystem, and expose a usable command surface.
3. **The source-control service drives many apps through APIs.** Much of CI does not need a checkout first: questions like "who last changed this line" or "how are these two commits related" can be answered by calling the API directly.
4. **The whole layer scales horizontally.** Repository data is stored in a distributed fashion; nowhere holds a complete physical replica, and there is no git-style packfile maintenance.
5. **Commits should be cheap, incremental, and lock-free.** Creating commits, rebasing, and merging all happen on the server; cost should scale with "how much changed this time," not with the size of the whole repository. Shared global state such as branches and tags should be touched as little as possible so it does not become a scaling bottleneck.
6. **Working copies are optional, and by default sparse and virtualizable.** Avoid the disk when you can; when files must land, pay only for the paths that are actually read.

On the data model, the unit of work is a **changeset**: a list of changed files relative to the first parent, plus content-addressed blob pointers. Once the server creates it, it is immediately available everywhere. A changeset alone cannot answer blame or path-history questions, so a derived layer is computed (blame, path history, commit-graph skip lists, and so on), eagerly or lazily as needed. The post also notes that early in the migration they answered metadata queries first, and only enabled heavyweight file materialization once clients and the protocol were ready.

### Architecture and gains

![Scion checkout layered architecture](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-checkout-architecture.png)

*Figure: Scion checkout layered architecture. Source: Anthropic Engineering · 2026-10-13.*

The client path is roughly: CLI client `scn` → `scion-daemon` (node-local object store) → regional `scion-cache` → authoritative `scion-server` (reading Spanner or cloud storage). The negotiation protocol asks for "which trees and blobs the client still lacks," without dumping a full inventory of what it already has; any layer can answer requests for content-immutable objects. Anthropic reports cache hit rates above 99% at each layer.

Every layer speaks the same remote-call interface, but the stack is strictly layered so a regional cache failure cannot take down the upstream authoritative servers with it.

Relative to the previous git-mirror infrastructure, the official post reports roughly 200× lower CPU and memory use; checkouts for CI and research jobs about two orders of magnitude faster (minutes down to seconds); and about 25% more CPU capacity freed for CI alone. Neither clients nor caches need to do repository maintenance.

### What they learned

The write-up ties the build window to an internally available Claude Mythos Preview, and to Claude Tag for watching the system. One example: an early handwritten git→Scion ingestion pipeline, rewritten on Mythos Preview, cut memory to about 1/20th and sped up by about 4×, while preserving implicit invariants around ingestion order and data structures.

Takeaways, as summarized in the official post, are roughly:

- **Small teams shipping fast will become more common.** About seven people built Scion, Antique, and a batch of related systems at once, finished the cutover in five months, and saw daily merges rise about tenfold during that window.
- **Engineers add value in high-level design—and in telling Claude "no."** Participants now often rate Claude as a stronger coder than themselves; people still set problem boundaries and cross-system tradeoffs, block changes that violate core constraints to satisfy a short-lived pattern, and avoid defensively adding complexity in adversarial reviews. The team still reviews every change request, with attention on intent rather than reading every line.
- **Testing and operations.** They built isolated simulations of key interactions, fuzzing, and rate limiting; Claude Tag raised a flock of "superfan" Claudes that watch individual component health—Anthropic says that kind of watch catches subtle anomalies that traditional alerts look thin against.
- **Merge queues and global locks do not copy cleanly to agent scale.** While tests are still running, hundreds or thousands of changes may already have landed. They invest more in automated testing after merge and before deploy; conflicts are handed to Claude to fix, often faster than humans would notice them.

On the security side, the post also describes directory-level permissions and semantic approval that can distinguish "comment-only edits" from "sensitive logic changes," so human review effort goes where it matters more.

### Limits of applicability

Scion is **not** a drop-in replacement for general-purpose git. These assumptions mainly matter for very large monorepos—tens of thousands of engineers, or swarms of agents writing code flat-out. Anthropic's internal token budget for building software also far exceeds what most companies would spend on homegrown tooling.

Turning it into a broadly available product is hard for the same reasons: it differs sharply from git, so switching means migrating review, search, and the whole CI lifecycle together; internal components are highly customized. Officially they would rather share the ideas so others can borrow them while still using git: servers can be asymmetric with clients; richer server-side RPCs are possible; negotiation protocols need not stay fixed; sparse and shallow capabilities can be combined better. The closing acknowledgments name Nick G. and the source-control team, among others.

### What it means for us

Anthropic itself does not sell this as "go replace your company repos with Scion." It reads more like a stress-test report that arrived early: when agents push merge throughput up by an order of magnitude, full local replicas designed for offline humans, mirror farms, and merge-queue global locks show strain first.

For people who day-to-day still use tools like Claude Code or Codex, the more portable takeaway is on the verification side: writing more code is not the same as shipping more production-ready software. The bottleneck slides toward source management, builds, CI, and "who watches intent and who blocks bad constraints." Anthropic used a small team plus Claude to rebuild the infrastructure—and still admits the result is hard to productize for the outside world.

### References

1. https://www.anthropic.com/engineering/redesigning-source-control