Evidence at a glance
The Change Is More Than a Higher Commit Rate
On October 13, 2026, Anthropic described Scion, an internal source-control system replacing Git for the company’s large monorepo and serving CI, developer environments, and research jobs. The stated trigger was a rapid rise in code changes, which made the existing ways of retrieving and maintaining the repository a drag on the wider development workflow.
The redesign is worth reading not because it proves Git is inadequate for every team, but because it shows how the bottleneck can move. As code generation accelerates, fetching code, querying history, and running CI can consume a growing share of infrastructure resources. Source control is no longer only a choice of local developer tool. It can also determine whether agent-driven workflows scale.
Checkout Volume Changes the Cost Structure
Anthropic reported that its average daily code changes merged rose from about 2,500 in May 2026 to more than 30,000 in September. The main branch history is nearly 100 GB, a compressed working copy exceeds 25 GB, and CI checks out code roughly 25 million times a day. “Code changes” should not be casually equated with Git commits, but together these figures show that both access frequency and repository size had become important design variables.
Anthropic also estimated that naively fetching Git data for every CI checkout would amount to more than 600 PB per day. That is a projection under a stated assumption, not measured network traffic. Its value is in illustrating how repeated retrieval can multiply costs, not in suggesting that the company actually transferred that volume. Anthropic’s hundreds of internal Git mirrors at peak also indicate how many copies had been used to serve different workloads.
Scion Replaces Full Clones with On-Demand Access
Scion uses a client-server architecture. The server handles commits, merges, rebases, and history and blame queries. Clients keep bounded object caches, working copies, and file-change monitoring. CI and internal tools can query information through APIs rather than preparing a complete repository for every task.
A change is represented as a changeset recording files modified relative to the first parent, with content-addressed pointers to compressed file data. Clients request trees and objects when needed instead of first receiving a large packfile. Sparse checkouts fetch selected directories, while virtual checkouts materialize files on demand. Caches can forward object requests across layers. Anthropic says cache hit rates exceed 99% at each layer, and that the hierarchy is designed to prevent a regional cache failure from overwhelming upstream services.
The point is not simply to make one Git operation faster. Scion changes where data lives and when it moves. Git’s distributed design lets a full local clone work offline. Scion places more history operations and data services on the server, trading that independence for more selective distribution to online CI and agent workloads. The two designs optimize for different working conditions.
What the Performance Figures Do—and Do Not—Show
Anthropic reports that Scion’s infrastructure requires 200 times less CPU and memory capacity than its former Git mirror infrastructure. Checkouts for CI and research jobs are two orders of magnitude faster, falling from minutes to seconds, and CI gains 25% in CPU capacity. The company also says cache hit rates exceed 99% at every layer. These results fit the design goal of reducing full copies and repeated transfers, but they remain Anthropic’s internal figures.
The public account does not provide a complete benchmark method, workload range, or cost definition that would allow independent reproduction. The 200-fold figure refers to CPU and memory requirements, not a 200-fold reduction in total cost. Faster checkouts also do not imply that every build task speeds up by the same amount. For teams considering similar work, the useful step is not to copy these results, but to measure mirror resources, checkout time, cache hits, and CI machine usage separately.
The Migration Boundary Matters More Than the Diagram
Anthropic says a team of seven built Scion, the Antique code-review tool, and related systems, then completed the Git migration in five months. Daily merged code changes grew roughly tenfold during the same period. That timeline shows that a rapid redesign is possible, but it does not prove Scion caused the growth, nor does it mean the migration involved source control alone. Code review, search, and CI also had to work with the new system, so the engineering effort extended beyond replacing a client.
Anthropic explicitly says Scion is not for general use and does not claim to offer it as a general-purpose product. Centralized services reduce the burden of maintaining full repository copies for every task, but they make clients more dependent on server and network availability and give up some of the convenience of offline full clones. Teams with very large monorepos should first determine whether repeated clones and mirrors are a measurable bottleneck, then weigh on-demand retrieval against the cost of migrating supporting systems. If that bottleneck has not appeared, rebuilding source control may simply move complexity somewhere else.