Anthropic replaces git with Scion, an in-house version control system built for AI agents

What did Anthropic reveal about Scion?

Anthropic’s engineering blog published “Redesigning source control at Anthropic” on 13 October 2026. The post says the company’s source control, builds and CI, all designed for human-scale development, had become its biggest bottleneck once Claude began writing most of its code.

The numbers explain why. Anthropic says it averaged about 2,500 code changes merged per day in May 2026 and more than 30,000 per day by September, and that it does not expect the growth to slow. “Every bottleneck we remove immediately leads to a further increase in the amount of code we produce,” the post says.

To keep up, Anthropic built Scion, an in-house version control system, and fully migrated its monorepo from git in five months. In the same period the team shipped a code review tool called Antique, code search, an access-control system for source code, and new ways to land large amounts of reviewed code. The post focuses on Scion.

The post is signed by Nick G. and Anthropic’s source control team, and it says a team of seven built Scion and Antique. It reached the Hacker News front page the same day, partly because few companies have described moving a large monorepo off git at all.

Why did git stop working for Anthropic’s monorepo?

Git is decentralised: every clone is a complete repository that can compute diffs, read history and check out any revision offline. Anthropic says that design is right for most projects but no longer fits a repository its size.

The main branch’s history alone is almost 100 GB and a compressed working copy is more than 25 GB. Anthropic performs on the order of 25 million checkouts a day for CI, before counting developer environments, agent sandboxes and research jobs. Fetched naively, the post says, that would be more than 600 petabytes of git traffic per day.

The company used every standard workaround: shallow clones, sparse checkouts, promisor remotes, internal mirrors and repository snapshots kept in blob storage. At its peak it ran several hundred internal git mirrors. Snapshots fell further behind the tip of main as the merge rate climbed, and keeping diff and blame working on partial clones took growing care.

The key observation was that Anthropic already used git as a centralised system with one authoritative copy, and that nearly all of its clients were agents and jobs that are online by definition. So the team asked what source control would look like if it assumed always-online clients from the start. It drew on prior art from Google’s Piper and Meta’s Sapling.

How does Scion work?

Scion splits the work unevenly. The server answers questions about history and blame, creates commits and performs merges and rebases. The client keeps a bounded local cache, lays out working-copy files, watches for file changes and gives people a familiar interface, but computes very little itself.

The unit of work is a changeset, an entry in a write-ahead log. Instead of pointing to a full tree as a git commit does, a changeset lists the files that changed relative to its first parent, with content-addressed pointers to compressed file contents in blob storage. Changesets are created on the server, so there is nothing to push. Branches and tags exist, but moving one is a single compare-and-swap on a Spanner row, and Anthropic discourages refs other than main and release branches.

Questions such as who last edited a line come from what Anthropic calls derived data: blame structures, path history and skip lists for the commit graph, all computed from parent changesets by one generic mechanism. Each type can be computed eagerly or on demand, and new indexes can be added without changing the client.

Checkouts work differently too. Rather than telling the server what it already has, the scn client walks down from a root tree and requests only the trees and blobs it is missing. Every request names an object that never changes, so any cache can answer it. A scion-daemon on each machine shares objects between jobs, regional scion-cache servers stream objects from memory, and authoritative scion-servers read from Spanner or cloud storage on a miss.

Because every query the client uses is also exposed as an API, many jobs never need a working copy. Anthropic says its automated bisect and revert pipelines would not be practical at scale without that cheap programmatic access, and that sparse and virtualised checkouts are the default rather than an add-on.

What changed after the migration?

Anthropic reports a cache hit rate above 99% at every tier of the checkout system. Its Scion infrastructure is, it says, 200 times smaller in CPU and memory than the git mirroring setup it replaced.

CI and research jobs now check out code about two orders of magnitude faster, in seconds rather than minutes, and CI alone gained 25% of its CPU capacity back. Neither clients nor caches need repository maintenance, because there are no packfiles to repack.

The system also adds controls git lacks. Scion supports permissions on individual directories, so sensitive code can be protected without splitting the monorepo, and the Antique review tool can express rules that treat a comment-only change differently from a sensitive logic change.

Anthropic also changed how code lands. It says a conventional merge queue with a global lock no longer makes sense when hundreds or thousands of changes can merge while tests run, so it leans on post-merge and pre-deploy testing instead, and lets Claude fix the conflicts that follow. That is a striking choice given evidence, such as Harvard’s study of 718 firms using coding agents, that review and integration, not writing code, are where AI-assisted teams now get stuck.

How did Claude help build it?

Anthropic presents Scion as both a cause and a product of AI coding. The team started building it as Claude Mythos Preview and Claude Tag became available internally, and says both made the need more urgent and the work faster.

Its most specific example concerns the pipeline that ingests git history into Scion. Engineers had largely handwritten a first version. An early internal snapshot of Claude Mythos Preview, asked to rewrite it with no further instructions, produced a version that used 20 times less memory and ran four times faster while keeping the ordering and data-structure invariants, according to the post.

The engineers say they would all now rate Claude as a better coder than themselves, but that their job was often to tell it “no.” Agents sometimes broke core system constraints to follow a bad pattern, and adversarial review by other Claude instances could push it to over-engineer against hypothetical risks. People still review every change request, but they read for intent rather than line by line.

For operations, the team runs what it calls “superfans”: Claude instances in Slack channels, each watching the telemetry and logs of one component, such as the daemon, the cache or the merge queue. Anthropic says they spot subtle problems that conventional alerts miss.

Does this matter for teams that use git?

Not directly, and Anthropic says so. Scion “is by no means a suitable replacement for git for general use,” the post says, and it only makes sense for enormous monorepos with tens of thousands of engineers or swarms of agents. Anthropic also notes that its internal token spending is far beyond what most businesses would choose.

The company does not plan to release Scion. It diverges from git so much that adopters would have to migrate code review, code search and CI as well, and Anthropic thinks a one-size-fits-all public version would not be useful.

Instead it suggests changes to the git ecosystem. Git servers do not have to work like git clients; forges could offer server-side RPCs like Scion’s, perhaps standardised across hosts; negotiation could change; and git’s sparse and shallow features could be made to compose better. Anthropic says it wants to work with GitHub, GitLab and the open-source community, and expects this class of problem to reach more companies in the next six to 12 months. Tools such as Tencent’s TeamAI, which keeps shared agent skills under ordinary Git review, show how much agent tooling still assumes git.

For most teams the practical lesson is about pressure points, not migration. If agents are multiplying your merge rate, checkout time, CI capacity and review load will strain first, and benchmarks such as FrontierCode’s test of whether maintainers would merge agent code measure only part of that picture.

What should readers keep in mind?

Every figure in the post comes from Anthropic, and AI Lookout cannot check them. The company does not publish the size of its engineering team, how many of the 30,000 daily merges are written by agents, or how often post-merge testing catches conflicts after they land.

The post is also an advertisement for Claude. The Mythos rewrite and the claim that engineers now consider Claude the better programmer support Anthropic’s commercial pitch, and there is no independent account of the migration’s costs, outages or setbacks.

Still, it is an unusually concrete account of what agent-scale development does to infrastructure. Similar signals are appearing elsewhere, from Linus Torvalds posting a Claude Code-assisted kernel series to forges adding agent sandboxes, and source control is now one of the systems feeling the strain.