For decades, one assumption has shaped modern version control: every developer can keep a local repository, inspect its history, and create commits offline. Git excels at that model. But what happens when thousands of automated processes produce changes, nearly all of them always connected, and the same codebase is checked out millions of times every day?

On October 13, 2026, Anthropic published Redesigning source control at Anthropic, updated on October 15. It explained how the company built Scion, an in-house version control system, and migrated its monorepo off Git in five months. This does not prove Git is obsolete. It illustrates something narrower and more useful: an architecture optimized for human, offline development can become expensive when the typical client is an agent or a CI job.

The bottleneck was not writing code: it was moving and coordinating it

Anthropic describes an exceptional workload:

MetricFigure reported by Anthropic
Changes merged per day, May 2026Approximately 2,500
Changes merged per day, September 2026More than 30,000
Main branch historyAlmost 100 GB
Compressed working copyOver 25 GB
Code checkouts for CIAround 25 million per day
Hypothetical naive Git download trafficOver 600 PB per day

Moving from 2,500 to over 30,000 daily merges means more than a twelvefold increase. That demand comes not just from interactive developers but also from agents, ephemeral environments, tests, and research infrastructure.

Anthropic had already tried shallow clones, sparse checkouts, partial clones, repository seeds, and hundreds of internal Git mirrors. These mitigations bought time, but keeping the mirrors synchronized and operational became increasingly difficult.

The design question changed: if nearly every client is continuously online, why force every client to act like a self-contained Git server?

Git and Scion make different assumptions

Design choiceConventional GitScion at Anthropic
ConnectivityClients can work offlineServer access is assumed
History and operationsEach clone can compute much of this locallyServer handles queries, merges, and rebases
Client storageLocal repository, optionally partialBounded cache and requested files
Data transferObject negotiation and packsRequests for specific immutable trees and blobs
AutomationOften requires a checkoutMany operations use APIs without a checkout
ScalingMirrors, snapshots, and maintenanceHorizontally distributed services and caches

This does not mean Git lacks partial clone or sparse checkout: it supports both. The distinction is that Scion builds the entire protocol and service architecture around this mode of operation rather than layering it onto a distributed design.

How Scion works, component by component

1. The changeset is the unit of work

In Git, a commit points to a tree representing file state. In Scion, a changeset primarily records the files modified relative to its first parent, together with content-addressed references to compressed blobs. Changesets are written server-side to a write-ahead log.

The payoff matters: the work required to create a change can scale with the size of the modification, not the size of the whole monorepo. Accepting changes does not require exchanging packfiles, advancing one branch for every task, or coordinating global locks.

Scion does support refs, but discourages unnecessary ones. Updating a ref — such as the main branch — is a separate compare-and-swap operation on a Spanner row.

2. Searchable history is built as derived data

A record of modified files alone cannot efficiently answer “who last changed this line?” or “what is the common ancestor of these changes?” Scion builds additional structures for blame, per-path history, and changeset-graph relationships, including skip lists.

Anthropic calls these indexes derived data. Each structure is computed from the changeset and its parents’ derived data; some indexes are produced eagerly, while others are built only when needed. This lets the team introduce new indexes without changing the client protocol.

The architectural idea is powerful: keep the change log lean, then build query capabilities as specialized indexes and services.

3. A checkout can be sparse, virtual, or unnecessary

The scn client requests only the trees and blobs it needs. It checks its local cache, identifies missing objects, and fetches them recursively. Because objects are immutable and content-addressed, different cache tiers can serve them without renegotiating the entire repository state.

The simplified request path is:

AI agent or CI job
        |
        v
      scn
        |
        v
scion-daemon (node cache)
        |
        v
scion-cache (regional cache)
        |
        v
scion-server (authoritative service)
        |
        +--> Spanner / blob storage

All tiers use the same RPCs; the topology is enforced to isolate regional failures. A job needing only a diff or metadata can query the service without materializing a working copy. If files are necessary, its checkout can be sparse or virtualized.

4. Expensive operations move to the server

Commits, merges, rebases, history queries, and diff computation run in central services. This eliminates many full local copies and makes the operations easier to expose as APIs to pipelines and agents. The tradeoff is dependence on connectivity, plus demanding requirements for availability, authentication, and access control.

Anthropic also built Antique, an internal code review interface, along with code search and fine-grained directory permissions. Scion was not simply a new command replacing Git: it involved redesigning the developer platform.

The reported results — and what they do not mean

According to Anthropic’s internal measurements:

  • Scion’s infrastructure uses a 200-times smaller CPU and memory footprint than the prior Git mirroring infrastructure. This compares those specific infrastructures; it does not imply Scion uses 200 times less than every Git installation.
  • CI and research checkouts are around two orders of magnitude faster: seconds instead of minutes.
  • CI realized a 25% CPU capacity saving.
  • Every cache tier maintains a hit rate above 99%.

These are measurements reported by Anthropic for its own workload, not independent benchmarks that can be generalized to every company.

Claude helped create the problem — and the solution

There is a paradox: Claude helped generate so many code changes that source control became a bottleneck; it then helped build its replacement.

Anthropic says seven engineers built Scion, Antique, and several related systems and completed the migration in five months. In one specific example, an early internal Claude Mythos Preview model rewrote an ingestion pipeline to use 20 times less memory while running four times faster than the earlier prototype.

The human role should not disappear behind those figures. Engineers defined the invariants, system boundaries, architectural tradeoffs, and which agent suggestions had to be rejected. Anthropic describes hermetic simulations, fuzzing, rate limiting, and reviews focused on the intent of changes. Writing code faster is not a substitute for defining which properties must never break.

The uncomfortable lesson: CI and code review need a redesign too

When hundreds or thousands of changes can merge while tests are running, a globally locked merge queue no longer reflects the workload well. Anthropic describes investing more in post-merge and pre-deployment tests, accepting that concurrent changes may conflict and agents can help resolve them.

That choice carries risks. It is not a blanket recommendation for teams to remove pre-merge quality gates. It succeeds or fails in the context of observability, testing, and recovery mechanisms designed for that level of throughput.

The conceptual shift is from a sequence of human developers to a continuous stream of changes generated by many agents.

Should your team abandon Git?

For the vast majority of teams, no. Scion’s ideas are still useful before considering a radical migration:

  1. Measure before replacing. Is time lost downloading the repo, running unnecessary builds, waiting for reviews, or coordinating merges?
  2. Move less data. Test sparse checkout, partial clone, dependency caching, and CI artifacts.
  3. Query without cloning where possible. Metadata and diff APIs can spare jobs and agents from materializing repositories.
  4. Isolate services and set limits. Use regional caches, concurrency limits, access controls, and graceful-degradation plans.
  5. Evaluate the entire pipeline. Version control, reviews, tests, and deployment form one throughput chain.

These five suggestions are editorial recommendations, not an Anthropic-issued checklist.

Scion should also not be presented as a publicly installable tool: the article describes an internal system and does not announce an open-source release. Anthropic acknowledges large-scale predecessors including Google’s Piper and Meta’s Sapling.

Conclusion

The most important point about Scion is not that one company replaced Git. It is that Anthropic changed which client it was optimizing for: from a human needing a self-contained local copy to thousands of agents and jobs needing small, fast answers from an online service.

As code production accelerates, the scarce resource may shift from writing it to integrating, validating, and moving it safely. That is the real warning for anyone designing engineering platforms for agents.

Sources and further reading