Anthropic's Scion: Inside the In-House Version Control System That Replaced Git for a 30,000-Merge-a-Day Monorepo

Anthropic replaced git with an in-house version control system called Scion, migrating its entire monorepo in five months because agent-driven coding pushed merge volume from roughly 2,500 code changes per day in May 2026 to over 30,000 per day by September 2026. The company says the new system cut its source control infrastructure footprint by 200x in CPU and memory and made code checkouts two orders of magnitude faster.

Anthropic published the details in an engineering post titled "Redesigning source control at Anthropic," written by Nick G. and the source control team. The post frames the work as a case study in what happens when AI agents, not humans, become the primary authors of code.

The scale problem: git was built for humans, not agent swarms

Anthropic's monorepo outgrew git's core design assumption that every client holds a complete, self-contained copy of the repository. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB.

The company performs on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Anthropic states that fetching those naively would generate over 600 PB of git traffic per day.

Anthropic used every standard large-monorepo workaround git offers: shallow clones, sparse checkouts, promisor remotes, internal git mirrors, and repository snapshots (seeds) kept in blob storage. At peak, the company operated several hundred internal git mirrors. Those mirrors became harder to run as the merge rate rose, and seeds fell further behind the tip of main between refreshes.

The post identifies the core mismatch directly: Anthropic was using git as a centralized system with one authoritative copy, while nearly all of its clients are agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining the company's ability to scale.

Scion's six design principles

Anthropic built Scion around six principles that deliberately diverge from git. The post cites Google's Piper and Meta's Sapling as prior art for large-monorepo source control.

Clients are always online. Git assumes clients work offline and need a complete copy of the repository. Scion assumes a server that is always reachable and has clients fetch data when they need it.
Client-server asymmetry. In git, every client can be a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, and performs merges and rebases. The client maintains a bounded local object cache, lays out working copy files on disk, monitors for filesystem changes, and offers an ergonomic interface.
A comprehensive source control service can power many novel applications. Every source control query the Scion client uses is also exposed via API, so jobs often need no local repository at all. Anthropic says its automated bisect and revert pipelines would not be practical at scale without this cheap programmatic access.
Everything must be horizontally scalable. There is no fully materialized copy of the repository anywhere, even on the server, and no equivalent of git packfiles, so no repository maintenance is needed.
Commits must be cheap, incremental, and lock-free. Every commit, rebase, or merge happens on the server, so there is nothing to push. The cost of creating a commit must scale with the size of the change, not the size of the repo. Scion discourages refs (branches and tags) except for main and release branches, because global state every server must agree on is a scaling problem.
The working copy is optional and sparse by design. Scion's protocol centers on sparse checkouts and virtualized checkouts that materialize files on demand.

How Scion works: changesets, derived data, and a three-tier cache

Scion's unit of work is a "changeset," an entry in a write-ahead log. Where a git commit stores a pointer to a tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to compressed file contents in blob storage. Changesets are created server-side and are available everywhere instantly.

Because a changeset records only what changed, it cannot by itself answer questions like who last edited a line. Scion builds additional structures from the changesets — dedicated structures for file blame and path history, and skip lists for the commit graph. Anthropic calls everything outside the changeset "derived data" and computes it through one generic mechanism in which each type is defined recursively from its values for the changeset's parents. This lets the team add new derived data types, choose eager or deferred computation per type, and optimize internals without changing the client.

Scion supports refs technically, but moving one is a compare-and-swap on a single Spanner row that happens separately from creating changesets.

The scn client deviates from git's fetch protocol: its negotiation does not tell the server what the client already has. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific immutable object, so any cache can answer it, and the process is resumable because there is no single multi-gigabyte packfile response.

The deployment has three tiers:

scion-daemon runs on each node, stores objects for the whole node, and starts from a periodically refreshed snapshot.
scion-cache servers in each region stream objects directly from memory in the disk format the daemon will consume, avoiding delta compression and client-specific computation.
scion-server is authoritative, reading from Spanner or cloud storage when a cache misses.

All three tiers respond to identical RPCs, so the client does not need to know the cache topology. Anthropic strictly enforces the tiering to isolate failure domains and prevent a regional cache failure from overwhelming upstream servers.

Measured results: 200x smaller footprint, 99% cache hit rates

Anthropic reports that each tier of the system maintains a cache hit rate of over 99% and requires no long-lived state. The company states its Scion infrastructure footprint is 200x smaller than its previous git mirroring infrastructure in terms of CPU and memory requirements.

CI and research jobs check out code two orders of magnitude faster — in seconds rather than minutes. CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance.

What Anthropic learned: engineers now tell Claude "no"

Anthropic says a team of seven people built both Scion and Antique, its code review tool, plus half a dozen related systems, and fully migrated to them in five months — all while the volume of code merged per day increased 10x. The company expects this kind of fast, nimble migration to become more common.

On the changing role of engineers, the post states that all engineers who worked on the system would now rate Claude as better at writing code than them, but that engineers supplied the high-level understanding of inter-system components and design-level tradeoffs. The post describes the role bluntly:

Very often, we found that the role of the engineers was to tell Claude "no." Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place.

Anthropic gives two concrete examples. Multiple systems tried to brute-force looking up when a change merged to main by linearly reading the commit log instead of asking the code review tool. Separately, an adversarial review that was overly defensive about trusting another internal service caused Claude to add excessive validation and complexity. Team members still review every change request, but now examine the intent of the change rather than reading every line of code.

On code quality, Anthropic says Scion is among the most well-tested and well-defended codebases it has worked on, with hermetic simulations of every non-trivial infrastructure and source control interaction, plus fuzzing and sophisticated rate limiting. The post also describes an early internal snapshot of Claude Mythos Preview rewriting the handwritten git-to-Scion ingestion pipeline with no further instructions, producing a version that consumed 20x less memory and was 4x faster while preserving implicit invariants around ingestion ordering and data structures.

On operations, Anthropic uses Claude Tag to run "superfans" — Claude instances assigned to obsess over the health of a single component, such as a scion-daemon superfan or an Antique merge queue superfan. These have access to telemetry and logs and act like an experienced engineer refreshing charts and looking for anything strange. Anthropic says the superfans detect subtle and novel issues that traditional alerts miss.

On merge queues, Anthropic states it has not been able to replicate the industry standard of a global repository lock on the merge queue, so it invested in post-merge and pre-deploy automated testing instead. Concurrent changes can conflict, but the post says Claude can typically fix those conflicts faster than humans can identify them.

Scion will not be open sourced, and Anthropic says it is not a general git replacement

Anthropic states plainly that Scion is by no means a suitable replacement for git for general use, and that its concepts only make sense for truly enormous monorepos with either tens of thousands of engineers or swarms of agents writing code prolifically. The company also notes that its ability to spend tokens for internal use far exceeds what any other business would realistically want to spend.

Anthropic says it is difficult to offer Scion in a form broadly useful to other organizations because it diverges significantly from git and requires its own code review, code search, and CI, all of which are highly bespoke internally. Instead, Anthropic says the most impactful thing it can do is share its thinking so other developers can apply parts of Scion to git without departing from the overall model — for example, by building novel server architectures, comprehensive server-side RPCs, and a negotiation protocol that does not look like today's.

Community reaction: "Did Anthropic just reinvent Subversion?"

The most repeated reaction on Hacker News was that Scion resembles older centralized version control systems. Commenter mijoharas wrote: "So... Anthropic reinvents SVN?" Commenter mey asked flatly, "Did they reinvent subversion?" and tatersolid asked whether Anthropic "just re-invent and vibe-code Subversion."

tancop drew a closer comparison: "So it's a SVN/Perforce style server based VCS with a more modern design. Sounds exactly like Lore from Epic Games but with zero production use outside the company and no support for non text assets. And they won't release the code."

apf6 argued the work is less novel than it appears: "A lot of large tech companies (Google, Facebook, Microsoft) have already built their own homegrown SCM (or have implemented custom extensions to Git), because Git and other SCMs don't handle their scale. Most interesting thing about Scion is how quickly it was deployed."

rcleveng offered a related anecdote from Oracle: the person who ran Oracle's move off ClearCase called it his "$LASTNAME law" that every large company will at some point write its own source control system. rcleveng added that git was "just good enough (and cheap enough)" that companies did not need to escape the physical and cost scaling problems of commercial SCM systems.

Community reaction: the monorepo question

Several commenters questioned whether the monorepo itself is the root problem. exabrial wrote: "Changes merged to our monorepo > monorepo. Well, there's your problem." zmmmmm asked whether Anthropic considered not going all-in on a monorepo, noting the jump from "let's have a monorepo it will make merging easier" to "let's redesign version control because merging is too hard now" without the middle question. zmmmmm also wondered whether AI tooling is tipping teams toward monorepos because it gives an agent the whole app context in one go.

zactato raised the same question from a different angle: "I have been questioning whether agentic development changes the mono-repo vs multi-repo question."

Community reaction: skepticism about infinite demand for code

Several commenters pushed back on Anthropic's claim that "the latent demand for merging code is practically infinite." netburst asked what the benefits of supporting extremely high churn are, what the code is doing, and what problems are being solved, adding: "If the goal is to write software which solves real problems, how can the demand for code grow infinitely?"

frangonf took the premise to its logical end: if the repo is in constant automated change with no direct human supervision, "then why even have source control? Why not just let software be fluid and, like Heraclitus river, never step twice in the same repo."

piker asked what people at Anthropic actually do now, and whether they are soon to be laid off. he0001 asked whether the churn is really a flex: "Sounds to me that it a large failure as they cannot agree upon what is needed to be done?"

preommr warned about imitation: "There's going to be an ugly phase where everybody FOMOs into thinking they need to do the same, only to realize that they're not Anthropic/Google/etc."

Community reaction: can humans review 30,000 changes a day?

tetraodonpuffer quoted the section on engineers reviewing intent rather than every line and asked how easy it is to review 30,000 PRs per day even for intent alone, and how one notices if the model takes shortcuts on implementing that intent without reading the code.

duttish described a related experience: "Every time I stop reviewing the code from Claude I later find janky crap. Not every review finds janky crap, but often enough that I can't stop reviewing everything. This is my disconnect with this kind of speed, how are they avoiding the janky crap?"

realo raised compliance: "I guess Anthropic are not IEC-62443-4-1 compliant, because I doubt a human reads and understands every single line of those 30,000 merges a day."

vhantz predicted trouble, arguing that a company with fewer than roughly 2,500 developers needing tens of thousands of merges a day, handled by seven "Claude baby sitters," will become "a major clusterfuck in not too long."

Community reaction: the "tell Claude no" line resonated

kazzak13 said the "What we learned building Scion" subsection was more fascinating than the technical details, quoting the line about engineers telling Claude "no." alex_suzuki wrote: "That line stuck with me. I wonder how the engineers building Scion feel about that? If that really is the future, then I guess I have to find another profession."

idk1 drew a different conclusion from the Mythos Preview rewrite anecdote: "We still need the human creativity and spark in the loop to come up with these fresh, new, bold, creative ideas. I think if you let the current version of Claude run forever, it still wouldn't have the creative spark to create its own new source control system."

Community reaction: prior art, timing, and model releases

simonw listed Anthropic's public model releases through 2026 and guessed that any public model was available internally at least a month earlier, concluding: "My best guess is that the uptick in code changes corresponds to the availability of Mythos/Fable-class models inside of Anthropic."

steveklabnik, commenting on behalf of East River Source Control, said the post validated his company's thesis that large teams plus agents in a monorepo will hit git's scaling limits, and noted that East River offers a git compatibility layer to ease migration.

0c3ca83 found the repo size surprisingly small: "From what I recall, Google's repo is closer to 80 terabytes."

altcognito did the arithmetic on checkouts: "30k merges per day, 25 million CI checkouts. 833 checkouts for every merge? That's quite a few." colek42 argued Anthropic framed the problem wrong: "Maybe they should have asked, 'Why does our process need to do so many git checkouts?' Why can't you just run the tests where you already checked out the code?"

rao-v noted a security benefit that is often left unspoken: server-centric source control reduces the risk of accidental or deliberate code exfiltration, because "basically nobody's laptop ever holds much of a buildable codebase."

Community reaction: open source and the closed garden

nickysielicki asked why Anthropic published the post at all if it will not open source Scion: "You have a new internal VCS? Kudos! Why should I care? Do you offer it as a service? Can I pay you for it?"

whiplash451 wrote: "open-sourcing scion would have been the true generous move." kneel25 argued it is "pretty fked that they stole an unfathomable amount of developer projects to train the models that lets them build this and they don't have the decency to release developer tools back out to the community."

liyu1981au framed the shift historically: git's most important contribution was that anyone can own the full history of a repo, which is the foundation of true open source. "Anthropic now? a backward step to a closed garden that's all."

w10-1 called Scion a great example of addressing scaling issues with just seven engineers, but a sad example for open source and small engineering companies, because companies can now tailor major infrastructure to their own needs and avoid coordination. w10-1 also noted a different scale problem: merging all the related docs, which get lost in a stream of comments, PRs, and documentation that goes stale because none of it is automatically correlated.

Community reaction: what a genuinely agent-native VCS might need

armcat argued the post addresses scale but not semantics: "I am still lacking semantic re-invention of source control for agentic era." armcat proposed three axes worth rethinking — "intent" (what the agent was trying to actually accomplish), "provenance" (which agent made what decision, based on what evidence), and "continuous verification" (maintaining correctness through ongoing validation, repair, and rollback rather than a single pre-merge testing gate).

amelius suggested committing prompts as the source code and letting AI-generated code sit in the repo as expensive-to-generate build output. blurbleblurble plugged Pijul as working well for agent collaboration, and bhouston described building git-dedup, which uses a global cache like pnpm so repeated checkouts are near instant.

startakovsky1 objected to the framing of "human scale" as a limitation, arguing that if humans use a tool then it is at human scale by definition.

What to watch

Anthropic says it expects this class of problem to become more commonplace over the next six to 12 months and wants to partner with GitHub, GitLab, and the open source community on server-side architectures, standardized server-side RPCs, and a negotiation protocol that composes sparse and shallow features well. The company acknowledges that the git community has spent nearly two decades scaling the platform for millions of developers and describes its own contribution as far narrower: an early view into how agentic software development interacts with source control.