Anthropic’s AI code surge forced a Git replacement

Anthropic replaced Git for its internal monorepo with Scion, a source control system designed for code-producing agents and large-scale automation. Seven engineers built and migrated to the system in about five months, according to Anthropic’s engineering account.

Claude-generated code drove the change. Anthropic’s merge rate rose more than twelvefold between May and September, overwhelming infrastructure built around local repositories, serialized merges, and human development cycles.

Git’s local model meets 30,000 daily merges

Git’s object model favors a complete local repository, although shallow clones, sparse checkouts, and partial-clone features can reduce how much data a client downloads. That model becomes costly when millions of short-lived jobs need small portions of a huge monorepo.

Fetching a compressed working copy for every reported CI checkout would generate more than 600 PB of daily traffic. Anthropic reduced that load with shallow clones, sparse checkouts, promisor remotes, seed snapshots in blob storage, and several hundred internal mirrors.

Those mitigations introduced their own coordination costs. Mirrors became harder to synchronize as the merge rate rose, while CI jobs, agent sandboxes, developer environments, and research workloads continued requesting fresh repository state.

Nearly all of Anthropic’s clients already require a network connection. Git’s offline capabilities therefore imposed storage and synchronization costs without providing much value for the dominant workloads.

Scion turns source control into a service

Scion draws on ideas from Google’s Piper and Meta’s Sapling while tailoring its architecture to online agents and disposable compute jobs. Its clients keep little state, and its servers perform operations that Git usually handles inside a local repository.

• Online clients: Clients request repository data as needed instead of cloning the complete history.
• Thin local state: The client maintains a bounded object cache, writes working-copy files, watches for filesystem changes, and exposes commands to users and tools.
• Server-side operations: Commits, merges, rebases, diffs, ancestry queries, and blame calculations run remotely.
• Source control APIs: Tools invoke remote procedure calls, or RPCs, without creating a local repository. An RPC is a network request that asks a server to perform an operation.
• Distributed storage: Repository data spans independently scalable services. No server holds a fully materialized copy of the monorepo.
• Limited global refs: Scion minimizes branches and tags outside the main and release lines because shared pointers require coordination across writers.
• Sparse working copies: Virtualized checkouts materialize files only when a process requests them.

Scion also removes Git packfiles, which bundle repository objects for storage and transfer. Eliminating them reduces repository maintenance and lets each storage tier serve immutable objects directly.

Changesets avoid the write bottleneck

Writes enter Scion through a write-ahead log, an ordered record that persists an operation before downstream systems process it. The unit recorded in that log is a changeset.

A Git commit points to a tree representing a complete directory snapshot. A Scion changeset instead lists files changed relative to its first parent and stores content-addressed references to compressed file data in blob storage. Content addressing identifies each object by a hash of its contents, so identical content can share the same stored object.

The server creates commits, rebases, and merges without accepting packfiles or moving a global branch pointer for every operation. That design avoids the locks and shared-state updates that would otherwise serialize writers.

Historical queries require separate indexes because a changeset stores only the changed files. Scion derives data structures for line attribution, path history, and commit-graph skip lists, which let the service jump through ancestry without visiting every intermediate commit.

Each index can be calculated from a parent’s data and the current changeset, either when the change arrives or when a query first needs it. Clients never depend on the internal representation, allowing Anthropic to replace indexes or add features such as copy detection and path search without changing client behavior.

Fetches work like CDN lookups

Git fetch negotiation commonly begins with the client and server comparing repository state. Scion’s scn client requests only the trees and blobs needed for a checkout. A tree describes a directory, while a blob contains file data.

The client starts with a root tree, checks its local store, and recursively requests missing child trees. It then repeats the process for file blobs. Every object is immutable and addressed by content hash, so any cache holding that object can answer the request.

Requests first reach a per-node scion-daemon, then a regional scion-cache, and finally authoritative scion-server instances backed by Google Spanner and cloud object storage. Each tier implements the same RPCs.

Cache servers stream objects in the on-disk format consumed by the daemon. This removes the CPU cost and protocol complexity of generating delta-compressed transfers for each client.

Anthropic reports cache hit rates above 99% at every tier without requiring durable cache state. The Scion deployment uses about one two-hundredth of the CPU and memory consumed by the previous Git mirror fleet. CI and research checkouts complete in seconds rather than minutes, and faster CI checkouts recovered 25% of the fleet’s CPU capacity.

Claude wrote most of Scion

Anthropic says Claude produced most of Scion’s implementation while engineers set the architecture, scaling targets, and system invariants. An early internal build of Claude Mythos Preview rewrote a handwritten Git-to-Scion ingestion pipeline without additional instructions, cutting memory use by a factor of 20 and running four times faster while preserving ingestion rules.

Every engineer on the project told Anthropic that they rated Claude above themselves at writing code. Their work concentrated on cross-system design, tradeoffs, and review. They frequently rejected agent-generated changes that matched a surface requirement while violating a deeper invariant, or that added elaborate defenses against hypothetical review comments.

Anthropic also runs “superfans,” Claude instances assigned to Slack channels for individual components. Each instance monitors telemetry and logs for systems such as scion-daemon, scion-cache, and the internal Antique merge queue. The company says these agents identify subtle failures that threshold-based alerts miss.

What other teams can reuse

Scion targets monorepos serving tens of thousands of engineers or large fleets of code-producing agents. Anthropic has not announced a public release, and the company says its token spending on internal tooling exceeds the budget most organizations would accept.

1. Remove repository-wide serialization. A merge queue that locks the entire repository can cap throughput as concurrent changes increase. Anthropic shifted validation toward post-merge and pre-deployment testing, allowing concurrent changes to land and using Claude to repair conflicts.
2. Account for stale CI results. Thousands of changes may land while one test run is still executing. CI systems need to track which repository state a result covers and decide when later changes require another run.
3. Separate server architecture from client behavior. Git-compatible services can adopt server-side RPCs, object-aware caching, improved negotiation, and composable sparse checkouts without copying Git’s local implementation. Anthropic points to potential work with the Sapling project, GitHub, and GitLab.

Most engineering organizations remain far below Anthropic’s reported workload. The reusable lesson is narrower: when agents become the main producers of code, source control, merge coordination, and CI must be sized for machine-speed concurrency rather than human submission rates.