Anthropic's Scion Source Control: 30,000 Merges a Day, but Not Available to Install

Bottom line: Anthropic’s engineering post on Scion says daily merges grew from about 2,500 in May to more than 30,000 in September 2026, and separately describes a 10x increase. Scion is an internal system; it is not available to download or install.

The merge rate and the download page are not the same object. Anthropic’s engineering post, “Redesigning source control at Anthropic”, says the company averaged around 2,500 code changes merged per day in May 2026 and merged over 30,000 per day as of September. The same post says a team of seven fully migrated the monorepo to Scion in five months while the volume of code merged per day increased by 10x. 2,500 times 10 is 25,000. Over 30,000 is not 25,000.

We already had a local model flag that was not an offline mode. Copilot’s /model can find Ollama. It does not go offline. We already had an install that was two commands and a second system that was not step two. OpenShell’s install is not the Sentry step. We already had a knowledge API that wants a search before a dump. Search the chunks first. Scion is the same shape of mistake waiting to happen: a lab built a source-control system, published the scale, and did not publish the binary.

2,500 and 30,000 are a chart. 10x is a different sentence.

The May and September figures are in the opening of the engineering post. Around 2,500 merged changes per day in May 2026. Over 30,000 per day as of September. Anthropic says it does not expect that growth to slow. The latent demand for merging code is “practically infinite,” and every bottleneck they remove leads to more code, not to a plateau. Simon Willison’s October 13 link post quotes that paragraph. He does not add a third rate. If a recap says “about 12x,” that recap did the division. The post did not print 12.

The 10x is later, in the lessons section. Seven people built Scion and Antique, the code-review tool, plus half a dozen related systems, and fully migrated in five months, “while the volume of code merged per day increased by 10x.” That “while” is the five-month build, not a labeled May-to-September ratio. 10 times 2,500 is 25,000. The September figure is over 30,000. Both can be true if the 10x window is not May versus September, or if 10x is a round number and “over 30,000” is the chart. They cannot be true as one equation. A slide that says “10x, from 2,500 to 30,000” has glued two sentences into a false identity.

The operational fact is the level, not the slogan. A monorepo that merges on the order of 30,000 changes a day is not a repo that still fits the “clone it and go offline” assumption, which is the next paragraph of the same post.

The git design they say no longer fits is a size, not a vibe.

Anthropic does not call git a mistake. The post says git is decentralized, every clone is a complete repository, and that design is right for the vast majority of repositories. It is a large part of why git became the standard. The break, as they describe it, is their monorepo. Main-branch history is almost 100 GB. A compressed working copy is over 25 GB. They perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

Those four figures are one argument. 100 GB is history. 25 GB is a working copy. 25 million is a checkout count, CI only. 600 PB is the naive product, not a bill they say they paid. The post says that is what naive fetches would be. A capacity plan that treats 600 PB as observed traffic has deleted the word “naively.”

The New Stack’s October 15 piece reports the same class of claim from the company: coding is no longer the bottleneck; the bottleneck is developer infrastructure built for human scale, including source control, builds, and CI. That is Anthropic’s sentence as TNS renders it. It is not a benchmark against another lab. Simon’s guess that Fable and Mythos class models drove the chart is his guess.

What Scion changes, if you are Anthropic.

The post names prior art: Google’s Piper and Meta’s Sapling. Scion is not presented as the first centralized monorepo system. The principles they list are the reviewable part.

Clients are always online. Git assumes a client can work offline with a complete copy. Scion assumes a server that is always reachable, because nearly all of their clients are agents and jobs, and clients fetch data when they need it. Simon records a Hacker News reply from Scion engineer Nick G, who is also the byline on the engineering post: offline support was not important to build, because Claude is by far the heaviest user and is necessarily online. The post’s principle and the HN reply are the same direction. They are not the same text. One is a design rule for agents and jobs. The other is a person saying the heaviest user cannot be offline anyway.

Commits are server-side. In git you commit locally and push. In Scion, every commit, rebase, or merge happens on the server, so there is nothing to push, and each of those operations has to be fast. The cost of creating a commit has to scale with the size of the change, not the size of the repo. The post also says the lifecycle discourages refs, meaning branches and tags as pointers every server must agree on, except for the main ref or release branches. Global agreement is the scaling problem they are refusing.

The client is called scn. It does not tell the server what the client already has. It starts from a root tree, asks for missing trees, then asks for blobs. Every request is for a specific object that never changes, so a cache can answer it. There is no single multi-gigabyte packfile. Each cache tier, the post says, holds a hit rate over 99% and does not require long-lived state. The infrastructure footprint is now 200x smaller than the previous git mirroring setup, in CPU and memory. CI and research jobs check out code two orders of magnitude faster, which the post glosses as seconds rather than minutes. CI alone realized a 25% CPU capacity win.

200x, two orders of magnitude, and 25% are three different measurements. 200x is the footprint versus the old mirror fleet. Two orders of magnitude is checkout time. 25% is CPU capacity on CI, not on the whole company and not a 25% faster checkout. A vendor slide that says “200x faster and 25% cheaper” has swapped the nouns. TNS repeats the 200x footprint and the two-orders checkout line. That 25% stays attached to the engineering post.

You cannot install it. The two pages do not use the same refusal.

This is the tool-review conclusion, and it is a refusal. The engineering post says it is practically difficult to offer Scion in a form that would be broadly useful. It diverges from git, so a company would have to migrate every piece of the development lifecycle. It needs its own code review, code search, and CI. Anthropic’s internal versions of those are highly bespoke. They worry that a public version built to please everyone would not be very useful. The contribution they offer instead is narrower: an early view of how agentic development hits these systems, and a wish to partner with GitHub, GitLab, and the open-source community.

TNS’s October 15 article is sharper. It says Anthropic has no plans to release Scion or create a public version any time soon, that the system is too specialized, and that other companies hitting the same wall get inspiration rather than a repo. It also says Anthropic wants to partner with GitHub, GitLab, and the open-source community, which matches the engineering post’s partner sentence. “No plans any time soon” is TNS’s wording. “Difficult” and “wouldn’t be very useful” are the engineering post’s.

Simon’s comparison, that Scion sounds like a reinvention of centralized source control along the lines of Subversion, is his comparison. The engineering post cites Piper and Sapling, not Subversion. If you are evaluating the design, use the prior art they named. If you are evaluating whether your team can vendor it this quarter, both pages agree on the practical answer. You cannot.

What to do with a git repo that is merely large.

Most repositories are still in the set Anthropic calls the vast majority, where a full clone is the right design. A 2 GB repo and a slow CI fetch are not a 100 GB history and 25 million CI checkouts. Copying Scion’s conclusion onto a normal monorepo is how this post gets misused. The numbers that justify their design are printed. If you do not have numbers in that range, the post is a warning about agent-scale checkouts, not a migration order.

If you do have agent sandboxes checking out the same tree all day, the transferable part is not the scn binary. It is the diagnosis. A checkout that ships a complete history to a client that only needed a tree is the naive 600 PB shape, at whatever size you actually have. Sparse checkout, a blobless clone, or a CI cache that does not re-fetch the world are git features. They are not Scion. The post’s own checkout story, objects requested by id, no packfile the size of the repo, is the idea they say they want the git hosts to absorb. Until GitHub or GitLab ships something you can point a remote at, the action is to measure your checkout count and your working-copy size, and to stop treating a blog post about 30,000 merges as a package name.

The October pages gave a rate, a size, a footprint, and a refusal. The review is that Scion is a real internal system with printed scale, and it is not a tool you can add to a Dockerfile this week.

What this means for you

For most teams, the takeaway is not to replace git but to watch for the same pressure points: merge queue throughput, repository size, and CI load. Standard git scaling options are still the first tools to try for a large repository.