Anthropic replaced Git with a custom centralized version control system called Scion after their commit rate jumped from 2,500 to 30,000 per day. The spike correlates directly with internal deployment of Fable and Mythos-class models. Claude is now the heaviest user of their source control infrastructure, and the system was explicitly designed around the assumption that agents are always online.
This is not a story about better tooling. It is a story about how agent-generated code velocity breaks the assumptions baked into distributed version control.
Why Git Could Not Scale
Git’s distributed model assumes developers work offline, clone full repositories, and merge infrequently. Anthropic’s workload inverted every assumption:
- 25 million checkouts per day across CI pipelines, agent sandboxes, and research jobs
- 100 GB of history on the main branch alone
- 25 GB compressed working copy per checkout
- Naive Git traffic would hit 600 PB per day
The bottleneck was not storage. It was the cost of materializing full working copies for ephemeral compute. Every CI job, every agent sandbox, every research experiment needed a clean checkout. Git’s object model forces you to fetch and decompress the entire history graph to get a working tree.
Agents do not care about offline workflows. Claude runs in a data center. It does not need to work on a plane. Anthropic’s engineers realized they were paying the complexity cost of distributed version control for a feature their primary user would never need.
Scion Architecture: Derived Data and Server-Side Materialization
Scion is a centralized system inspired by Google Piper and Meta’s Sapling/Mononoke. The core idea is derived data: the server precomputes and caches expensive operations so clients fetch only what they need.
Key Design Choices
| Component | Git Model | Scion Model |
|---|---|---|
| Repository structure | Distributed, full clones | Centralized, partial checkouts |
| Working copy materialization | Client-side decompression | Server-side derived data |
| Offline support | First-class | Not supported |
| Checkout cost | O(history size) | O(changed files) |
| Primary user | Human developers | AI agents + humans |
The server maintains precomputed snapshots of every commit. When a client requests a checkout, it fetches only the files it needs for that specific revision. The server handles decompression, delta application, and tree construction.
This trades server compute for client bandwidth and storage. For Anthropic’s workload, that trade is asymmetric: they have centralized infrastructure and need to minimize per-checkout cost.
Checkout Flow
# Conceptual Scion checkout (not actual implementation)
def checkout(commit_sha, sparse_paths=None):
# Server-side: lookup precomputed tree snapshot
snapshot = derived_data_cache.get(commit_sha)
if sparse_paths:
# Only fetch requested subtrees
files = snapshot.filter(sparse_paths)
else:
files = snapshot.all_files()
# Stream file contents to client
for path, blob_id in files:
yield (path, blob_store.fetch(blob_id))Clients do not decompress objects. They do not walk the commit graph. They request a snapshot and stream file contents. The server absorbs the complexity.
Agent Commit Patterns and Code Review
Anthropic’s commit velocity chart shows clear spikes aligned with model releases. The jump from 2,500 to 30,000 commits per day happened after Fable and Mythos became available internally.
Agent-generated commits have different characteristics than human commits:
- Higher frequency: Agents iterate faster and commit intermediate states more often
- Larger diffs: Agents refactor entire modules instead of making surgical changes
- Less context: Commit messages are generated, not written with institutional knowledge
Anthropic built a custom code review system called Antique to handle this volume. The system uses adversarial review, where Claude critiques its own changes and other models flag potential issues.
The engineering team noted a specific failure mode: adversarial review can be myopic. Claude over-engineers in response to hypothetical concerns. Human engineers have to steer the agent away from adding complexity for edge cases that will never occur.
This is a calibration problem. The agent does not know which concerns are real and which are paranoia. It needs human feedback to learn the difference.
Migration and Deployment
A seven-person team built Scion and migrated Anthropic’s entire codebase from Git in five months. The migration strategy was:
- Dual-write phase: All commits go to both Git and Scion
- Shadow mode: Scion serves read traffic, Git remains authoritative
- Cutover: Scion becomes authoritative, Git is archived
- Cleanup: Remove Git-specific tooling and workflows
The team did not attempt a big-bang migration. They ran both systems in parallel until Scion proved stable under production load.
The lack of offline support was a conscious trade-off. When asked on Hacker News, a Scion engineer said: “Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn’t important to do.”
This is the clearest signal that Scion is designed for agents first, humans second.
Failure Modes and Operational Concerns
Centralized systems have different failure modes than distributed systems:
- Single point of failure: If Scion goes down, no one can commit
- Blast radius: A bad server-side change affects all clients immediately
- Derived data staleness: Cache invalidation bugs can serve incorrect snapshots
- Scaling bottleneck: Server-side materialization costs grow with checkout volume
Anthropic mitigates these risks with:
- Redundant servers: Multiple Scion instances behind load balancers
- Canary deployments: Server changes roll out to a small percentage of traffic first
- Derived data validation: Checksums and consistency checks on every snapshot
- Horizontal scaling: Add more servers as checkout volume grows
The system is operationally simpler than Git for their workload, but it requires more infrastructure investment. You cannot run Scion on a laptop.
Technical Verdict
Use Scion’s architecture when:
- Agent-generated commits dominate your workflow
- You have centralized infrastructure and can run server-side materialization
- Checkout volume is high and working copy size is large
- Offline workflows are not a requirement
Avoid this approach when:
- Human developers need offline access
- Your team is small and cannot maintain custom infrastructure
- Commit volume is low enough that Git’s overhead is acceptable
- You need compatibility with existing Git tooling
Anthropic’s migration is a preview of what happens when agents become the primary users of development infrastructure. The tools we built for humans do not scale for agents. Centralized systems with server-side compute are a better fit for workloads where the client is always online and needs fast, cheap checkouts.
The interesting question is not whether Scion is better than Git. The interesting question is: what other developer tools will need to be redesigned when agents generate more code than humans?
Source Links
- Redesigning source control at Anthropic (Simon Willison’s analysis)
- Hacker News discussion (Scion engineer responses)