Anthropic Open-Sources Scion, a Custom Git Replacement Designed for AI Agent Velocity

In four months earlier this year, the number of code merges hitting Anthropic's main repository grew from roughly 2,500 per day to more than 30,000 — a 12-fold increase driven not by a hiring surge but by Claude agents writing, reviewing, and committing code at a pace that no human engineering team could match. Git, the version control system that powers virtually all of modern software development, was not designed for this. On Tuesday, Anthropic published a detailed account of what happened when it tried to run Git at that velocity — and released Scion, the custom version control system its engineers built in roughly five months to replace it.

The timing matters beyond the open-source release. Anthropic's engineers believe this is not a problem unique to Anthropic. "We believe that AI-assisted development will require the rest of the industry to face similar challenges within six to twelve months," the team wrote. For any organization currently running AI agents against a shared codebase — or planning to — Scion amounts to both a post-mortem and an architectural blueprint.

How AI Agents Broke Git's Core Architecture

Git was designed in 2005 by Linus Torvalds for distributed, offline-capable, human-paced development. Its internal data model stores full-tree snapshots packed into binary "packfiles" on disk, with periodic garbage collection runs to compress and reorganize those files. Its merge queue serializes commits: when two branches need to merge, Git locks the queue, performs the operation, and releases. For teams operating at human velocity — tens or hundreds of commits per day — this architecture is invisible overhead.

At 30,000 merges per day, it is not invisible. Git's GC (garbage collection) process, normally a routine background task, began triggering under load at unpredictable intervals, causing CI pipeline stalls. The merge queue, designed for sequential human commits, became a bottleneck that could not be parallelized within Git's architecture. Every CI node independently re-ran expensive graph traversal operations — computing ancestry chains, blame data, path history — that other nodes had already computed and discarded. The result was a system that consumed 25% of Anthropic's total CPU capacity just maintaining version control state.

The root issue is architectural. Git's model assumes the client does computation and the server stores data. That assumption breaks when CI fleets of hundreds of nodes each need to perform identical, expensive operations on the same repository state.

Scion's Changeset Architecture: What Git Never Did

Scion's core data model inverts that assumption. Where Git stores full-tree snapshots on every commit, Scion's unit of work is the changeset — a write-ahead log (WAL) entry that records only the files that changed, with content-addressed pointers into a separate blob store. This is the same structural idea used by databases like PostgreSQL and storage engines like RocksDB: record every modification to an immutable sequential log, and derive everything else from that log.

The architectural consequence is significant. Everything beyond the raw changeset — blame data, path history, commit-graph skip lists — is treated as derived data, computed lazily from the changeset log and cached. No packfiles. No repack pressure. No GC storms. When a CI job needs to know which files changed between two commits, it asks the server, which answers from its derived-data cache. The CI job does not recompute the answer itself.

That server-side computation model is the second major departure from Git. Scion is explicitly a client-server system: the server performs all diffs, merges, rebases, and ancestry computations. The client — whether a developer's workstation or a CI runner — maintains only a bounded local cache. This eliminates the repeated expensive work that made Git's CI overhead so costly.

Commit locking uses Google Spanner's compare-and-swap operation rather than a traditional serialized merge queue. Spanner's globally distributed, strongly consistent transaction model allows multiple commits to proceed in parallel, with conflicts resolved at the database layer rather than through queue serialization. This is what allows Scion to handle 30,000+ merges per day without a merge queue bottleneck.

Three-Tier Caching at 25 Million Checkouts a Day

Serving agent-scale read traffic required a cache architecture as carefully engineered as the write path. Scion uses three tiers: the scion-daemon (a per-node cache local to each machine), the scion-cache (a regional shared cache), and the scion-server (which reads from Spanner and cloud blob storage when the regional cache misses). The system achieves greater than 99% cache hit rate across 25 million checkouts per day.

Checkout itself works differently. Rather than materializing the full working directory from a packfile — Git's model — Scion supports sparse and virtualized checkouts: files are fetched on demand, and CI jobs can bypass checkout entirely through a direct API that returns file contents without writing them to disk. For large AI-generated codebases where CI jobs need only a fraction of the repository's files, this is a substantial throughput improvement. Anthropic says checkout time dropped from minutes to seconds.

The repository Scion manages is not small: Anthropic's main branch history weighs 100 GB, with a 25 GB compressed working copy. The claim that this infrastructure is 200 times smaller than an equivalent Git setup is company-reported and has not been independently verified.

Claude as Both Cause and Solution

Roughly 80% of Anthropic's code is now written by Claude — a figure that Anthropic leadership has cited publicly and that explains the merge-volume growth. But Claude is also embedded in Scion's operational infrastructure in ways that go beyond passive code generation.

Read more: Anthropic ties API credits to Claude subscriptions, bypassing Pro tier

When Anthropic migrated its existing Git history into Scion's changeset format — a technically complex operation involving the entire repository's commit graph — it used Claude Mythos Preview to rewrite the ingestion pipeline. The rewrite reduced memory consumption by 20 times and improved processing speed by four times, according to Anthropic.

Day-to-day operations use what Anthropic calls "superfans": dedicated Claude Tag instances (Claude deployed within Slack) assigned to monitor specific system components. Each superfan watches its component's behavior and flags anomalies — a form of always-on operational observability that scales without human on-call burden.

The role of human engineers has also shifted. When Claude agents produce merge conflicts — a routine occurrence when many agents write to overlapping code paths — Claude resolves those conflicts faster than a human engineer can identify them. Engineers now review the intent behind proposed changes rather than auditing line-by-line diffs. Antique, a companion code review tool built alongside Scion, is purpose-built for this workflow. Where standard pull-request tooling assumes human reviewers approving discrete diffs, Antique supports complex semantic approval constraints that match the scale and structure of agent-generated code review.

Scion in Context: Google Did This, Meta Did This — Now Anthropic

Anthropic is not the first technology company to outgrow Git. Google hit Subversion's scaling limits in the early 2010s and built Piper — a client-server VCS backed by Bigtable and later Spanner — that now manages approximately two billion lines of code. Piper was never open-sourced. Meta spent roughly a decade building Sapling (originally Eden SCM), a Mercurial-compatible VCS optimized for its own monorepo scale; Meta open-sourced Sapling in November 2022. Microsoft addressed a different dimension of the same problem with GVFS (VFS for Git), which virtualizes checkouts for very large repositories while keeping Git compatibility.

Read more: Claude Code Mods ship in v2.1.287 with TypeScript event hooks

What distinguishes Scion from all of these is its design brief. Piper, Sapling, and GVFS were built to scale human development teams. Scion was built because AI agents rendered human-scale tooling obsolete in under a year. The architectural choices — WAL-based changesets, server-side computation, Spanner compare-and-swap commits, virtualized CI checkouts — are direct responses to agent-velocity requirements, not human-velocity requirements.

The Spanner dependency is worth noting for organizations considering Scion. Operating Scion as designed requires access to Google Spanner or a compatible globally consistent distributed database — not commodity infrastructure. The system is open-sourced as reference architecture, not as a drop-in Git replacement for teams running standard cloud infrastructure.

What Comes Next for the Industry

Anthropic's six-to-twelve month prediction for industry-wide Git scaling failures is grounded in the same math that produced Scion: AI agent adoption is accelerating across every major AI lab and an increasing number of enterprise software teams. Organizations currently running agent-assisted development at low volume will face the same merge-queue contention, the same GC pressure, and the same CI fleet CPU overhead that Anthropic documented — just later.

The open-sourcing of Scion gives those organizations a head start Anthropic did not have. The architectural decisions are well-documented: the WAL-based changeset model, the derived-data abstraction, the tiered cache topology, the server-side computation model, and the Spanner-backed locking strategy together constitute a coherent response to agent-scale VCS demand. Whether the broader industry converges on Scion specifically, forks it, or builds competing architectures — as Google and Meta each did independently — the era of Git as the unchallenged default for production AI development infrastructure appears to be ending.