Anthropic Built Its Own Version Control System: Scion, Source Control for Agent Scale

Anthropic has published the most striking infrastructure case study of the agent era: they built their own version control system and replaced git in their monorepo — in five months, with a team of seven. The system, called Scion, exists for one reason: Claude now writes and merges so much code that the developer infrastructure built for human scale became the bottleneck. In May 2026, Anthropic merged ~2,500 code changes per day; by September, over 30,000 per day. At that volume, the company was doing ~25 million code checkouts a day for CI alone, and naive git traffic would have exceeded 600 petabytes per day. Their answer was not a better git server — it was a fundamentally different design, built on the premise that the clients are agents, and agents are always online. This post breaks down the six design principles, the architecture, the measured results (a 200x smaller infrastructure footprint, 100x faster checkouts), and what the "lessons learned" section reveals about how software engineering itself is changing at agent scale.

The Bottleneck Moved: From Code to the Pipes Around Code

The opening framing is the whole thesis: "coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven't seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI."

That's a quiet revolution in what "engineering capacity" means. For a century, the constraint on shipping software was the speed at which humans could write and review it. The tooling — version control, continuous integration, build systems — was designed around human tempos: a developer clones a repo, works offline, pushes when ready. Now the producers of code are agents running tens of millions of operations a day, and the tooling is the choke point. Anthropic's own observation is the key one for everyone else: "we don't expect this rate of growth to slow down… every bottleneck we remove immediately leads to a further increase in the amount of code we produce." That's a demand curve with no flat part — remove a constraint, and the system immediately loads it back up. (These are the same numbers from our earlier report on how the Claude Code team does code review — the monorepo going from ~2,500 to 30,000 merges a day is one machine; this post is about the plumbing underneath it.)

The concrete pressure numbers make the problem tangible:

• Main-branch history alone: ~100 GB; a compressed working copy: over 25 GB
• ~25 million code checkouts per day for CI — before counting developer environments, agent sandboxes, and research jobs
• Naive git fetch at that volume: over 600 PB of git traffic per day
• Peak mitigation effort: several hundred internal git mirrors — a workaround stack that "became harder to operate as our merge rate increased," with snapshot seeds falling further behind the tip of main between refreshes

The Core Insight: Git Was Designed for a World We No Longer Live In

Here is the intellectual move that everything else follows from, and it deserves to be read carefully. Git's defining property is decentralization: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision fully offline. "For the vast majority of repositories, this is the right design, and it's a large part of why git became the standard." But Anthropic noticed that in their world, they were using git as a centralized system with one authoritative copy, and nearly all of their clients were agents and jobs that are online by definition. The properties that make git excellent — complete local copies, offline capability, every client being a potential server — were actively working against their scale. So they asked the obvious-but-radical question: "if we designed source control with the fact that agents are always online in mind from the start, what would it look like?"

That's a one-sentence redesign of an industry standard, derived not from a benchmark but from an observation about who the client is. It's the same move as everything else in this story: stop assuming the user is a human, and re-derive the system from the actual workload.

Six Design Principles for Agent-Scale Source Control

Scion's architecture is organized around six explicit principles, each a deliberate inversion of a git assumption. (They credit prior art — Google's Piper and Meta's Sapling, the two great monorepo systems — for hard-won lessons, so this is informed design, not reinvention-for-invention's-sake.)

Two of these matter beyond source control. The "source control as a service" principle — every question a client can ask, the server can answer via API — is really the platform-ization of a primitive: it's the same pattern as the SBD Tool Connect post (own the data layer, expose it as an API, let others' intelligence run on it), applied to the most fundamental primitive in software. And the "commit cost scales with the change, not the repo" principle is the definition of the property any system touching agent-generated code needs: at 30,000 merges a day, any O(repo-size) operation is a queue, and any queue is a bottleneck the agents will immediately load.

How Scion Works: Changesets, Derived Data, and a Tiered Cache Fleet

The implementation has three parts worth understanding, because each one is a response to a specific scaling law.

1. The changeset. The unit of work is a "changeset" — an entry in a write-ahead log. Like a git commit it stores the expected metadata, but instead of a pointer to a tree, it stores the list of files that changed relative to its first parent, plus content-addressed pointers to compressed file contents in blob storage. Changesets are created server-side and "available everywhere, instantly." Because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move, the system accepts changesets at very high throughput. Content-addressing does quiet heavy lifting: once a piece of data is stored, it never changes, so any server can cache it without checking with the others — that single property is what makes the whole fleet horizontally scalable with almost no coordination.

2. Derived data. A changeset records only what changed, so it can't directly answer "who last edited this line" or "which commits touched this file." Scion answers those with additional data structures (blame, path history, commit-graph skip lists) built from the changesets — all computed through one generic mechanism, where each derived-data type is defined recursively: its value for a changeset is computed from its parents' values. Three benefits: new derived data types can be added when a new operation needs them; each type can be computed eagerly or lazily; and because clients never see the internals, the team can re-optimize a data structure without changing the client. "We've added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search." That's the architecture of a system expected to evolve under load — the shape of a living infrastructure, not a frozen design.

3. The tiered cache fleet. The client protocol is the part that breaks from git most deliberately. Git's fetch negotiation tells the server what the client already has; Scion's negotiation "operates exclusively on trees and blobs the client wants." Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats for blobs. Every request is for a specific, never-changing object, so any cache tier can answer it — "the architecture closely resembles traditional tiered caches," and it's resumable because there's no single multi-gigabyte packfile response. Sparse and virtualized checkouts need no special support: the client simply doesn't ask for trees it doesn't want. The fleet has three tiers: scion-daemon (per node, stores objects for the whole machine — jobs on the same node reuse most of the same objects), scion-cache (regional, streams objects directly from memory in the format the daemon consumes), and scion-server (authoritative, backed by Spanner and cloud storage). All three tiers respond to identical RPCs, so the client never knows the topology — but the tiering is strictly enforced "to isolate failure domains," because a failed regional cache must not be able to overwhelm the authoritative servers and take down the whole system. Each tier holds a cache hit rate over 99%.

The Measured Results

Those numbers compound in a way worth sitting with. The 25% CI capacity win isn't a feature — it's returned compute: capacity that previously went to moving bytes now goes to running tests, training, and research jobs. And the seven-people-in-five-months figure is the human-scale surprise: in the pre-agent world, building and migrating a source control system of this kind "would have taken a company years of iterative migration, with many more engineers." A quarter of a year, during a 10x traffic increase. That's not an incremental improvement in engineering velocity; it's a different order of how infrastructure gets built.

What They Learned: The Engineering Org Chart, Rewritten

The "lessons" section is, for many readers, the most valuable part of the post — because it describes how the organization changed, not just the system. Six findings:

1. The Mythos rewrite: 20x less memory, 4x faster, no instructions

They had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. "We thought it was good — until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures." That's a specific, checkable claim about a model doing what senior engineers spend weeks on — finding the algorithmic structure that was already implied but not written.

2. The engineer's job is now to say "no"

Every engineer on the team rates Claude as better at writing code than themselves. Yet the engineers "still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs." The concrete failure mode is illuminating: agents "will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place." Their example: multiple systems that brute-forced "when did this change merge to main" by linearly reading the commit log instead of asking the code review tool. And because Anthropic leans on adversarial review (which is effective but "can also be myopic"), skilled engineers had to steer Claude away from over-engineering in response to hypothetical concerns — one review was so paranoid about trusting another internal service that Claude added excessive validation and complexity. The net effect: "Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code." That sentence is the single best description of the 2026 senior-engineer role I've seen from inside a company shipping at agent scale.

3. The "superfans": Claude as an obsessive SRE

They created Slack channels where they tasked Claude with being "obsessively focused on the health of a single component." They call these Claudes "superfans" — a scion-daemon superfan, a scion-cache superfan, an Antique merge-queue superfan — with access to telemetry and logs, acting "like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange." Traditional alerts still exist for everything, but "our superfans can detect subtle and novel issues that make these alerts seem one-dimensional by comparison." This is the natural end-state of monitoring: instead of writing N alert rules, you delegate the entire watch to an agent whose job is to notice anything strange — which is what good on-call actually is, minus the pager fatigue.

4. The merge queue, abolished

Perhaps the most interesting admission: "A proper merge queue, for example, doesn't make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running?" They couldn't replicate the industry-standard global repository lock on the merge queue, so instead they "invested in post-merge and pre-deploy automated testing." Concurrent changes can conflict now — but "Claude can typically fix these conflicts faster than humans can even identify them." Read that again: the industry's answer to conflicting changes is a serialization mechanism (the merge queue), and Anthropic's answer is to let the conflicts happen and have an agent resolve them faster than they'd be detected. The mechanism for safety moved from prevention by lock to detection by automation. That's a genuine conceptual shift in how landing code works, and it has downstream implications for every team whose agents will soon merge at real volume.

5. Monorepo security as a first-class design goal

Scion supports rich repository access control plus directory-level permissions — protecting the most sensitive code without fragmenting the monorepo — and the code review tooling can express "complex semantic constraints on approvals" that differentiate comment-only changes from sensitive logical changes, so human reviewers focus on the consequential ones. At agent merge volumes, security review can't be a human line of defense; it has to be encoded in the system's approval logic.

6. The whole "human scale" workflow is suspect now

"This project prompted us to take a very hard look at other workflows designed for human scale." The merge queue was one; the implication is that CI semantics, branching models, code review norms, and release processes are all on the list of things to re-derive from the agent workload rather than inherited from the human one.

The Honest Position: Scion Is Not a Product, and They Say So

Anthropic is unusually direct about the limits of the announcement, and the post's credibility rests on these caveats:

• "Scion is by no means a suitable replacement for git for general use." The concepts "really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code." Their token budget for internal use is, in their words, far beyond what any other business would realistically spend.
• They're not shipping it, deliberately. Scion diverges significantly from git — adopting it would mean migrating the entire development lifecycle — and their code review, search, and CI components are highly bespoke. "We worry that attempting to build a public version that tries to please everyone wouldn't actually be very useful." That's a rare, honest admission that some in-house systems are valuable precisely because they're tailored, and that a generic version would be worse for everyone.
• The plan is to change git's server side, not replace git. Their prediction: "this class of problems will become more commonplace over the next six to 12 months." Their proposed contribution is sharing the thinking so other teams can "apply some of the most successful parts of Scion to git without departing from the overall model": a git server doesn't have to work the way a git client does; forges could offer comprehensive server-side RPCs, "perhaps even in a standardized way across forges that the git client can learn to talk to"; the fetch negotiation protocol can change; and sparse/shallow features can be made to compose. They close by crediting the git community's two decades of scaling work and asking to "partner with GitHub, GitLab, and the OSS community." Note the implied timeline: they're telling GitHub and GitLab the pressure valve opens within a year.

What This Means for Everyone Else

Strip the proprietary details and the post makes four arguments with real consequences:

1. "Agent scale" is a distinct engineering regime, and it has a name now

Before this, "our agents generate a lot of PRs" was a growth problem. Scion formalizes it as a design space with its own invariants: always-online clients, server-side mutations, O(change) operations, optional working copies, API-exposed everything. Any team whose CI bill or merge queue is starting to feel the weight of agent volume is seeing the same pressure at lower amplitude. The post is effectively a map of where the pressure points will be: checkouts first, then history queries, then merge coordination, then review — in that order.

2. The data-plane/control-plane split is the general pattern

Scion's deepest idea is that source control's control plane (commits, merges, refs) and data plane (trees, blobs, working copies) should scale completely independently — which is what tiered caches, content addressing, and derived data accomplish. That separation isn't unique to version control; it's the same shape as the Service Data Plane in telecom, and it's the shape any system under agent load will converge on. If your tools don't have a clean data/control split, that's the refactoring that will matter when your agents speed up.

3. The human role inverts from "reads code" to "vets intent and says no"

The engineering lessons are a field manual for the post-agent org: engineers supply design-level tradeoffs and kill bad patterns before agents brute-force around them; reviews examine intent, not lines; and monitoring becomes a fleet of obsessive, component-specific agent "superfans" that catch what rules can't. Combined with the earlier Claude Code code-review post — same team, same monorepo — you now have both halves of the picture: how they review agent code (continuous, risk-tiered, machine-checked) and how they move it (no merge queue, post-merge testing, agent-resolved conflicts). The two posts together are the most complete public description of a software org operating at agent throughput that exists.

4. The bottleneck whack-a-mole is structural, and only some of it is Anthropic's

Their demand curve — remove a bottleneck, volume immediately fills it — means the "fix the pipeline" phase of AI adoption is over and the "re-architect the pipeline for agents" phase has started. Most companies won't need Scion. But the specific predictions matter: within 6–12 months, this class of problem "will become more commonplace." The teams to watch are the ones whose CI is already doing millions of checkouts a day, and the platforms to watch are GitHub and GitLab, who have just been publicly told their server architecture is the next frontier.

Bottom Line

This is the infrastructure counterpart to everything else we've been covering: if the Claude Code review post showed how agent-written code gets reviewed, and the harness and ub-mode posts showed how it gets produced with discipline, then Scion shows how it gets moved — and it's the first clear proof that "agent scale" is not a volume problem to be mitigated but a design regime to be designed for. The core move is almost embarrassingly simple once stated: their clients are agents, agents are always online, so the entire offline, complete-copy, symmetric design of git — brilliant for humans in airplanes — became the bottleneck, and a server-centric, content-addressed, tiered-cache rewrite with O(change) commit cost was the correct answer. The results are measured, not aspirational (200x smaller infrastructure, checkouts in seconds, a 25% CI capacity win), and the build itself is a datapoint: seven engineers, five months, during a 10x traffic increase, with Claude rewriting their own ingestion pipeline to be 20x more memory-efficient when pointed at it. The honest caveats — this is not a product, not for general use, and deliberately not open-sourced — don't weaken the post; they sharpen it. The real announcement isn't Scion. It's the timeline: within six to twelve months, Anthropic says, this class of problem becomes commonplace, and the git server side — the part nobody thought about in two decades of git's success — is the next frontier. The team that re-derives its pipeline from the agent workload, rather than optimizing the human one, will have the capacity; everyone else will have a queue.

References

• Anthropic Research — "Redesigning source control at Anthropic" (Scion) [anthropic.com]
• The Claude Code team — "How we do code review at this scale" (first-person companion piece, same monorepo numbers) [claude.dev] — see also our post [ThinkSmart Research]
• Google Piper (monorepo prior art) [Wikipedia]
• Meta Sapling (monorepo prior art) [sapling-scm.com]
• Anthropic — Claude Mythos Preview (referenced internal release) [anthropic.com]
• Anthropic — Introducing Claude Tag (referenced internal release) [anthropic.com]

All figures (merge rates, checkout volumes, 600 PB/day, 100 GB history, 200x footprint reduction, 25% CI win, seven-person team, five-month migration, 20x/4x Mythos rewrite) are as reported by Anthropic in the source post, read in full on October 29, 2026. Scion is an internal, non-open-sourced system; no third-party verification exists. "Claude Mythos Preview" and "Claude Tag" are referenced as internal Anthropic releases.