On October 13, 2026, Anthropic published an engineering post, Redesigning source control at Anthropic, describing Scion, a server-centric version control system it built to replace Git for its internal monorepo. The post opens with a claim that frames everything after it: "coding is no longer the bottleneck to building systems or doing research," and the bottleneck is now "all of the developer infrastructure built for human scale." One note on scope: the authors describe Scion as an in-house system and say it is not a replacement for Git for general use, so this is a case study rather than a product launch.
AnthropicClaudeWhat happened to merge volume
According to Anthropic, changes merged per day grew from about 2,500 in May 2026 to more than 30,000 in September 2026. The arithmetic is simple: 30,000 divided by 2,500 is 12, so merge volume rose at least twelvefold in roughly four months. Anthropic attributes the shape of its workload to always-online clients: CI jobs, developer environments, agent sandboxes and research jobs.
Anthropic monorepo merges grew more than tenfold in four months
Changes merged per day into Anthropic's monorepo. 30,000 divided by 2,500 is 12, so the lower bound on growth is 12x.
Source: Anthropic Engineering, Redesigning source control at Anthropic, October 13, 2026.
Other figures from the post show why that volume strains Git. The monorepo's main-branch history is almost 100 GB, and a compressed working copy exceeds 25 GB. CI alone performs about 25 million checkouts per day, before counting developer environments, agent sandboxes and research jobs. Anthropic estimates that naive fetching would have meant more than 600 PB of Git traffic per day.
Why Git's design strains at this scale
Git was created by Linus Torvalds, with its first release in April 2005, and it gives each developer a full local copy of the repository history, which lets it work without a network connection. Anthropic's authors say that design suits most repositories. Their situation differs on two counts: the repository is very large, and nearly all clients are always-online agents and jobs that gain little from an offline copy.
Workarounds existed: shallow clones, sparse checkouts, internal mirrors and seeds stored in blob storage. Anthropic says these became harder to operate as merge volume rose, with seeds drifting from the tip of main and mirrors hitting disk and memory limits. At peak the company ran several hundred Git mirrors.
How Scion is built
Scion inverts the Git model. Its main design principles, as the post lists them:
- Always online. The server is assumed reachable, and clients fetch data on demand.
- Server does the heavy work. History, blame, commits, merges and rebases run server-side, while the client keeps a bounded local cache and working copy.
- Source control as an API. CI and tools can query history without a local repository, and many write tasks run without a checkout.
- Horizontal scale. No full copy of the repo is materialised anywhere, and there are no packfiles or repository maintenance.
- Cheap commits. Commits happen server-side without locks, with cost scaling by change size.
The unit of work is a changeset, a write-ahead log entry created on the server. The client (scn) talks to a local daemon, then to regional caches, then to authoritative servers backed by Spanner and cloud blob storage. Anthropic reports cache hit rates above 99% at each tier, CI and research checkouts about two orders of magnitude faster (seconds rather than minutes), and a 25% gain in CI CPU capacity.
The bottleneck, now, is all of the developer infrastructure built for human scale.
Anthropic Engineering, October 13, 2026
Claude's role in building it
Seven people built Scion and its companion code review tool, Antique, in about five months, according to the post. Anthropic says Claude wrote most of the code while engineers wrote the tests, including hermetic simulations and fuzzing. In one example, Claude Mythos Preview rewrote the hand-written Git-to-Scion ingestion pipeline with no further instructions, producing a version that used 20x less memory and ran 4x faster while preserving ordering invariants. The authors also say the engineers' main role shifted to setting constraints and reviewing intent, and that they often had to tell Claude "no", for example when systems brute-forced merge-time lookups instead of querying the code review tool.
Analysis: where the constraint moves
Three readings follow from the numbers, offered as interpretation rather than fact.
- The limit moved from writing to integrating. If code generation gets cheaper, the systems around it (version control, review, CI, merge queues) absorb the extra volume. Anthropic says a proper global merge queue does not fit agent-scale work, so it relies on post-merge and pre-deploy automated testing instead.
- Human-scale assumptions are embedded everywhere. Git's offline-first clone model is a reasonable default for people. It is a different trade-off for tens of millions of daily automated checkouts.
- Evidence is single-source. Every figure here comes from Anthropic's own account of its own repository. Other organisations' merge volumes, and whether they would hit the same limits, are not covered by the post.
For teams working with several AI models, the practical takeaway is that the surrounding tooling, not only model quality, sets throughput. That is one reason model-agnostic setups, such as the one Metir offers, tend to keep the workflow layer separate from any single model.
Sources:
Image credits
Header image: Linus Torvalds, photograph by Brian Hankins, Wikimedia Commons, public domain (source); a file photo of Git's creator, not an image of Scion. In-body image: Linus Torvalds at LinuxCon 2011, Wikimedia Commons, CC BY 2.0 (source).