The numbers describe one garage.
Anthropic says its monorepo grew from about 2,500 merged changes a day in May 2026 to more than 30,000 a day in September. Main-branch history was nearly 100 GB. A compressed working copy exceeded 25 GB. Its CI fleet performed roughly 25 million checkouts a day.[1]
That is a real systems problem. It is also an unusual workload reported by the company that built the replacement. Scion assumes clients are online. The server creates commits, performs merges and rebases, answers history queries, and serves selected objects. Clients keep a bounded cache and materialize only the files they request.[1]
A tenfold merge rate can justify a new service. It does not make your laptop a thin client.
Source control carries more than bytes.
Git gives each clone enough history and objects to perform many operations without a server. Linked worktrees share repository data while keeping separate working trees, HEAD state, and indexes. Git also exposes lock, repair, prune, and stable machine-readable listing commands for those worktrees.[2]
Jujutsu takes a different local route. It snapshots working-copy changes into commits during normal commands and records operations. Several workspaces can share one repository. If another workspace rewrites a working-copy commit, Jujutsu marks the old workspace stale and provides an update and recovery path.[3]
These designs make different trades. Local history gives you work during a network outage, cheap private experiments, and an inspectable recovery trail. A centralized service can avoid hauling a huge repository into every job and can answer history questions without a checkout. The migration decision belongs to the workload, not the fashion cycle.
The impressive gains need the same attribution as the constraints.
Anthropic reports that Scion's infrastructure uses 200 times less CPU and memory than its former Git mirror fleet. It reports checkouts that are two orders of magnitude faster and a 25 percent CPU capacity gain for CI. Each cache tier reportedly exceeds a 99 percent hit rate.[1]
Those are vendor measurements from Anthropic's system. The post does not publish Scion, a fixture, an independent benchmark, or enough operational material to reproduce the comparison. It also says Scion is not a general replacement for Git and would require a company to migrate code review, search, and CI with it.
The missing artifact changes what readers can conclude. The architecture is worth studying. The performance claims describe Anthropic's deployment. They are not a buying guide or a benchmark for a typical repository.
The hard question is custody under failure.
An always-online client makes the source service part of the edit path. Before adopting that shape, write down what happens when identity, network, metadata, or object storage is unavailable. Define which operations continue, which fail closed, and how unfinished work leaves the service.
Then name the review boundary. Anthropic says every Scion change still receives human review, but reviewers focus on intent rather than every line. It also says the team invested in post-merge and pre-deploy testing because a global merge-queue lock did not fit the new rate.[1] That is a process choice with a larger rollback burden. It should not arrive hidden inside a checkout-speed project.
Use pressure gauges before replacement plans.
Measure clone and checkout bytes, cache hit rate, materialization time, history-query time, offline requirements, and recovery time. Separate developer workstations, CI jobs, agent sandboxes, and read-only analysis. They do not need the same custody model.
Try the smallest intervention that attacks the measured cost. That may be linked worktrees, sparse materialization, a shared object cache, or a server API for history queries. Replace the source-control model only when the current model is the measured bottleneck and the new failure contract has passed a drill.