Anthropic Replaces Git With In-House Scion After Merges Hit 30,000 a Day

TL;DR

Anthropic published an engineering post on October 13 explaining why it ripped git out of its monorepo. Merges grew from about 2,500 a day in May 2026 to more than 30,000 a day by September, the main branch history alone is almost 100 GB, and CI checks out code on the order of 25 million times a day. Fetched naively, that is over 600 PB of git traffic daily. A team of seven built Scion, a centralized, always-online version control system with a tiered cache, and Antique, a review tool that approves intent rather than lines. The migration took five months. Scion is not open source, and Anthropic says it is "by no means a suitable replacement for git for general use."

The numbers that broke git

The post, written by Nick G. and the source control team, opens with the growth curve. In May 2026 Anthropic averaged around 2,500 merged changes a day. As of September it merges over 30,000. Simon Willison, who annotated the post's chart with public model release dates, suspects Mythos-class models drove the climb, and notes his markers show public releases rather than internal availability.

Volume is one half of the problem. Size is the other. The main branch history is almost 100 GB and a compressed working copy is over 25 GB. Anthropic performs about 25 million code checkouts a day for CI alone, before counting developer environments, agent sandboxes and research jobs. The post's arithmetic on a naive fetch comes out above 600 PB of git traffic per day. At the peak, the company ran several hundred internal git mirrors to absorb the load.

Git's shallow clones, sparse checkouts and promisor remotes exist for exactly this, and Anthropic says they do not compose well enough at that scale. The post's framing: "The bottleneck, now, is all of the developer infrastructure built for human scale."

What Scion is

Scion is a centralized system. Git assumes offline clients that each hold full history. Almost every Scion client is an always-online agent or CI job, so the server answers history, blame, commit, merge and rebase queries, and the client keeps a bounded local cache and lays files out on disk. Asked on Hacker News about offline support, engineer Nick G., posting as nickg-anthropic, said: "Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn't important to do."

The unit of work is a changeset, an entry in a write-ahead log that stores the changed files relative to the first parent plus content-addressed pointers into blob storage. Changesets are created server side, and the post's design rule is that "commits must be cheap, incremental, and lock-free." Metadata and refs live in Google Spanner. Moving a ref is a compare-and-swap on a single Spanner row, separate from creating the changeset, and refs are discouraged except for main and release branches.

Derived data such as blame, path history and commit-graph skip lists is computed recursively from parent values, eagerly or lazily per type, which is how the post can claim "there is no fully materialized copy of the repo anywhere, even on the server." Picture a library that never shelves a complete book. Every page sits in a content-addressed warehouse, and when you ask for chapter three, a clerk assembles exactly those pages and nothing else.

Fetches negotiate only the trees and blobs the client actually wants, starting from a root tree. There are no packfiles, responses are resumable, and there is no repository maintenance step. Working copies are optional: sparse checkouts include only the directories requested, virtualized checkouts materialize files on demand, and many CI jobs skip the checkout entirely and query the server over an API.

Three tiers, strictly enforced

Each node runs a scion-daemon that stores objects for every job on that machine. Daemons talk only to a regional scion-cache, caches talk only to the authoritative scion-server, and the server reads from Spanner or blob storage. Each tier holds a cache hit rate above 99% and carries no long-lived state. The tiering is strictly enforced so that a failure in one layer stays in that layer.

What it bought them

The post lists the wins after cutover. Scion's infrastructure footprint is 200x smaller than the old git mirroring setup in CPU and memory. CI and research jobs check out code about two orders of magnitude faster, seconds rather than minutes, and CI alone recovered 25% of its CPU capacity.

Those are Anthropic's own numbers with no outside audit, so treat the multipliers as claims from the team that built the thing. The 25% CI figure is the one most likely to survive scrutiny, since it is a plain capacity measurement rather than a ratio against a fleet that no longer exists.

Antique: reviewing intent, not lines

Scion shipped with a code review tool called Antique, and the post's chart shows its change requests displacing pull requests over the summer.

• Approvals can carry semantic constraints, so a comment-only change can be approved separately from a change that touches sensitive logic in the same request.
• Directory-level permissions protect sensitive code inside the monorepo, backed by a source control IAM system and repository-level access control.
• There is no global lock on a merge queue. Anthropic could not replicate the industry standard serialization at 30,000 merges a day, so it invested in post-merge and pre-deploy automated testing instead. Concurrent changes do conflict, and the post says "Claude can typically fix these conflicts faster than humans can even identify them."

Engineers review the intent of each change request rather than every line. Monitoring follows the same pattern: Claude instances the team calls "superfans" each watch one component, the scion-daemon or the scion-cache or the Antique merge path, using telemetry and logs, with traditional alerting still in place underneath.

Who wrote the code

The build story drew the most argument on HN. Early in 2026 the team hand wrote a prototype of the git-to-Scion ingestion pipeline. Then an early internal snapshot of Claude Mythos Preview arrived, and they asked it to rewrite the whole thing. 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."

Two more lines from the lessons section will get quoted for a while. "Very often, we found that the role of the engineers was to tell Claude 'no.'" And: "All of the engineers who worked on this system would now rate Claude as better at writing code than them." Professional No-Sayer is not on LinkedIn's job title list yet, but give it a quarter.

The post is not uncritical. Adversarial review by Claude is described as effective and also "myopic," prone to over-engineering in response to hypothetical concerns, which is why the humans spend their time on design judgment and vetoes. Commenter JohnMakin suggested the repo bloat came from agents using git history as a message queue. Nick G. replied: "We generally don't allow agents to use source control for coordination in that way. There really is tremendous growth in actual software and code being written that necessitated Scion."

Should you care if you are not Anthropic?

Probably not as a user. The post cites Google's Piper and Meta's Sapling as prior art, and one HN commenter asked whether Anthropic had reinvented SVN. (Another answered: closer to Perforce, but effectively yes.) Anthropic is not releasing Scion and says a public version would be hard because the internal tooling is bespoke. The ecosystem ask is narrower: git hosting platforms could add server-side RPCs for history, blame and merge, and git's sparse and shallow features could be made to compose.

The thread hit 519 points and 513 comments in a day, and Steve Klabnik showed up to say the post validates East River Source Control, which is building a centralized system with a git compatibility bridge. For a builder, the transferable parts are the design rules rather than the software: cheap lock-free commits, optional working copies, refs as a rare privilege, and a review model that approves intent and lets post-merge testing catch what a merge queue used to.

The other transferable fact is the shape of the curve. Anthropic's merge volume went 12x in four months, and the first thing to break was the version control layer, not the model. If your agents are doing a tenth of that, your git server is on the same road.

Key Takeaways

• Anthropic's monorepo went from about 2,500 merges a day in May 2026 to over 30,000 by September, on a repo with a nearly 100 GB main branch history and 25 million CI checkouts a day.
• Scion is a centralized, online-only source control system: server-side changesets, Spanner for metadata, content-addressed blobs, optional sparse or virtualized working copies, and a three-tier cache with over 99% hits per tier.
• Reported wins are a 200x smaller infrastructure footprint than the git mirror fleet, checkouts in seconds instead of minutes, and a 25% CI CPU recovery. These are company figures.
• Antique drops the global merge-queue lock in favor of post-merge and pre-deploy testing, with semantic approvals and directory-level permissions. Claude fixes the resulting conflicts.
• Seven people built both systems and migrated in five months. Claude Mythos Preview rewrote the ingestion pipeline to use 20x less memory, and every engineer on the team now rates Claude as the better coder.
• Nothing is being open sourced, and Anthropic says Scion is not a general git replacement.

Sources: Anthropic Engineering, Redesigning source control at Anthropic, Simon Willison, Hacker News discussion, East River Source Control