Anthropic Replaced Git with Scion, a Custom Version Control System Built for AI-Driven Development

Anthropic abandoned the industry-standard version control tool Git and developed its own new system named Scion.

When AI began writing code and commit volume exploded, Anthropic's existing Git infrastructure was pushed to its limits. From developing Scion to migrating the repository, the team took five months.

The core logic of this new system centers on three main points:

• On-demand retrieval: Most workers are always-connected AI agents that do not need to download the entire history every time. The system fetches the corresponding content from the server only when specific files are needed.
• Server-heavy lifting: Complex, heavy version control computations are handled primarily by cloud servers. Clients are mainly responsible for placing files on disk, monitoring changes, and maintaining a lightweight cache, dramatically reducing resource consumption on local machines.
• Lighter recording mechanism: Each time changes are saved, the system only records a list of modified files and content pointers. Creating a changeset requires no locks across the entire codebase; branch refs are updated separately, reducing coordination overhead and congestion when massive numbers of tasks submit concurrently.

Why Git Couldn't Keep Up (Background and Pain Points)

Inside Anthropic, writing code is no longer the bottleneck. Because Claude can autonomously advance research loops, optimize low-level programs, and even build new services from scratch, code generation speed has become extraordinarily fast:

• Merge volume grew more than 12-fold: In May 2026, they merged roughly 2,500 times per day; by September, that figure surged to over 30,000 times per day.
• Massive repository and staggering potential traffic: The main branch history is close to 100 GB, with compressed local clones exceeding 25 GB. To run CI (Continuous Integration), approximately 25 million checkouts are executed daily. Pulling the full compressed clone every time would hypothetically generate over 600 PB of daily network traffic.
• Git's design assumptions no longer matched the workload: Git's nature is decentralized and offline-capable, with default full clones retaining complete history. However, the vast majority of Anthropic's code clients are always-online AI agents and cloud CI tasks. To keep Git afloat, they previously ran hundreds of mirror nodes. Yet as merge frequency climbed and the main branch moved too fast, scaling mirrors, refreshing snapshot seeds, and computing diffs and blames on partial clones became increasingly difficult to maintain.

Why Git's Offline Strengths Became a Burden Here

Git's key advantage is that local repositories work independently: developers can still commit code, inspect diffs, and review existing history without a network connection.

This design grants clients extensive capabilities:

1. Decentralized: Every developer's local clone is a fully functional, complete repository. Even on a train or plane with no internet, you can inspect commit history, view Diffs, and trace who changed every line (Blame) completely offline.
2. Peer-to-Peer Architecture: Client and server capabilities are fully symmetrical. Your laptop is essentially a Git server capable of serving others at any time.
3. Full Snapshot Integrity: Every commit logically represents a full snapshot of the entire project's file tree, using packfiles and delta compression to conserve disk space.

For small-to-medium projects or typical open-source communities, this design is extraordinarily elegant and robust. But in an ultra-large monorepo with histories reaching hundreds of gigabytes, when countless online agents and ephemeral tasks repeatedly fetch the same codebase, maintaining individual local repositories incurs massive overhead.

Git inherently provides tools to narrow fetch scope, and Anthropic initially adopted common scaling approaches:

• Deploying multi-tier mirror arrays: Running Git mirrors within clusters—Anthropic ran hundreds at peak—to offload fetch pressure from the primary repository.

• Cold-data snapshot seeds: Storing repository snapshot seeds in object storage so newly initialized nodes download the snapshot first before incrementally pulling a small set of new commits.

• Partial checkouts and shallow clones: Leveraging Git's shallow clone (fetching only recent commits) or sparse-checkout (retaining only specific directories).

These measures alleviated pressure, but became increasingly difficult to sustain at their scale:

• Seeds fell further behind: As merges accelerated, periodically refreshed seed snapshots drifted further behind the latest trunk tip, forcing new tasks to fetch more supplementary changes.

• Growing mirror footprint and maintenance costs: With trunk history approaching 100 GB and compressed working copies exceeding 25 GB, the disk, memory, and operational maintenance of mirrors became scaling bottlenecks as the repository expanded.

• Complex history queries on partial clones: Partial clones often lack the historical objects required for queries; making Diff and Blame work on them forced the toolchain to handle extra backfilling steps.

Anthropic recognized that the vast majority of its clients were online agents and automated tasks, and actual collaboration centered around a single authoritative codebase. It therefore shifted its design starting point: clients fetch only what they need, while history queries and commit processing are delegated to online services.

What Work Did Scion Offload to the Server?

With the 'always-online client' premise established, Anthropic drew on architectural lessons from large monorepo systems like Google Piper and Meta Sapling to establish the six core pillars of Scion, its bespoke version control system designed for agent-scale workloads:

1. Always Online: Freeing clients from the burden of autonomous offline computation. Clients request specific data from the server only when needed, no longer retaining a full historical clone by default.
2. Extreme Client-Server Asymmetry: The server acts as the sole computation hub, handling merges, rebases, blame attribution, and historical indexing. Clients retain lightweight responsibilities—maintaining a controlled local cache and projecting files onto disk—minimizing local data and compute footprints.
3. API-First Version Control: If CI tooling needs to know 'what changed between these two commits' or 'who wrote this line', it no longer needs to clone the repository to disk; it simply calls the server's metadata API to retrieve the answer directly.
4. End-to-End Horizontal Scalability, Eliminating Fully Materialized Clones: No single location in the system stores a fully materialized copy of the entire repository. Without Git's massive, complex packfiles, periodic repository repacking and compression maintenance are completely eliminated.
5. Minimalist Deltas and Lock-Free Changesets: Commits must be cheap and fast. Each submission only records the incremental list of modified files without scanning the entire repo; creating changesets is decoupled from advancing branch refs, minimizing coordination during creation.
6. Completely Optional Working Directories, Sparse and Virtualized by Default: Avoid writing to disk whenever possible. Checkouts support fetching only designated directories (sparse checkout) or projecting a virtual directory tree that streams file contents only when read (virtualized checkout).

How Changes Are Saved and Files Retrieved

To translate these six principles into practice, Scion adopted distinct designs for its data structures and network topology.

1. Recording Changesets First, Deriving Directory Trees Later

In Git's underlying architecture, a commit points to a root tree object representing the project root directory. Even if you modify just a single character, Git must reconstruct a hierarchy of directory tree hashes from the bottom leaf node up.

Scion's core recording mechanism is fundamentally different. Its core logical unit is a changeset written to a write-ahead log (WAL):

• What is stored: A changeset records metadata (author, message, parent pointers) along with a manifest of changed files relative to the first parent (e.g., the hash of modified guide.md, deleted legacy.rs). Raw file contents are compressed and written directly to cloud object storage keyed by content hash.

• What is omitted: Changesets do not store full repository directory trees. Submitting requires no multi-server repack coordination, nor does it update any global branch refs.

• Branch movement is a single-row database operation: Advancing the main branch ref is abstracted as an atomic compare-and-swap (CAS) update on a single row in Google Cloud Spanner. The commit workflow is thus fully decoupled, dramatically boosting throughput.

2. Derived Data Mechanism

While merely recording change manifests enables blazingly fast writes, how does the system quickly answer 'who wrote this line five years ago' or 'which commits touched a specific file'?

Scion utilizes a general computation framework known as derived data:

• File blame chains, path change histories, commit graph skip lists, and other auxiliary structures are all defined as derived data.

• Derived data is defined recursively: the derived value for a given changeset is computed from its parent changeset's derived value combined with changes in the current changeset.

• The server can independently choose which common indices to compute eagerly and which rare indices to defer lazily until queried. Because clients remain completely oblivious to underlying index details, the server can optimize indexing strategies without requiring any client-side changes.

3. Three-Tier Streaming Cache Architecture: How the scn Client Works

To support tens of millions of high-frequency reads daily, Scion established a hierarchically isolated physical caching network:

In conventional Git negotiation protocols, the client and server negotiate which objects are already present and which need to be transferred, with the server calculating the set difference. In ultra-large repositories, this handshake consumes massive CPU.

Scion fundamentally reshaped this negotiation flow: clients never report what they own to upstream; they only request the target trees and object hashes they are missing.

The operational tiers function as follows:

1. Local Daemon (scion-daemon): Runs in the background on every physical compute node. Multiple tasks on the same node share this daemon. Because code executed across tasks on the same host overlaps heavily, the vast majority of files hit the local daemon's cache directly.
2. Regional In-Memory Cache (scion-cache): When a node daemon misses, requests are routed to the regional cache cluster in that datacenter. These servers stream objects directly from memory in disk-native format, without having to compute the set of missing objects or redo delta compression for each request.
3. Authoritative Service Cluster (scion-server): Only when both cache tiers miss does a request reach the top-level authoritative nodes to fetch raw data from Spanner and object storage.

Anthropic reports cache hit rates exceeding 99% across each tier. All three layers expose an identical RPC interface, while strict hierarchical boundaries isolate failure domains, preventing regional cache disruptions from overwhelming the authoritative cluster.

How Much Faster? It Depends on the Operation

What quantitative improvements did this architecture deliver in production?

Following the full migration to production, performance gains varied significantly across workflows. Benefits were uneven across environments and commands. Below is a side-by-side comparison of equivalent Git and Scion operations.

In agent environments, the total version control overhead per change request plummeted from 34 minutes to 3.7 minutes—roughly 9.2x faster. This cumulative waiting time reflects the aggregate impact of repeatedly preparing code across a task's lifecycle.

Key performance dimensions include:

• Agent worktree initialization: Plunged from 7.1 minutes to 5.1 seconds—an 84x speedup. Agents no longer endure prolonged idle waiting.

• Status queries: On developer machines, scn status dropped from 3.9 seconds to 19 milliseconds (207x faster), reducing interactive wait time.

• CI checkout latency: Median checkouts within CI jobs dropped from 31 seconds to 3.5 seconds (8.8x); checkouts when launching compute jobs dropped from 175 seconds to 22 seconds (8x).

• Reduced agent wait time and compute hours:

  • The agent environment saves approximately 11,000 hours of version control wait time daily;
  • CI and compute clusters collectively free up roughly 280,000 machine hours daily;
  • CI speedups alone unlocked a 25% CPU capacity gain for the CI platform.

• Reduced source control infrastructure footprint: Compared to previously maintaining hundreds of Git mirrors, Scion servers reduced CPU and memory infrastructure requirements to roughly 1/200th of their prior footprint.

These savings in machine hours and agent time reflect Anthropic's internal workload estimates and cannot be equated to human engineer hours. The benchmark charts reflect median command latencies without specifying hardware specs, sample sizes, or caching conditions; every metric must be evaluated within its specific environment. For developer commits, the speedup was only about 1.3x: from 1.4 seconds to 1.1 seconds.

How Seven People Executed This Migration

A seven-person team built Scion, Antique, and related systems, migrating the entire repository in five months. Anthropic noted that projects of this scope historically required far larger engineering teams and multi-year phased rollouts; the compact team size was inseparable from having pervasive access to internal Claude models.

Claude simultaneously overwhelmed the legacy toolchain and empowered engineers to implement and optimize its replacement.

The migration also reshaped how the team operated:

1. Models Wrote Code; Engineers Said 'No'

Engineers on the project observed that Claude had already surpassed them at writing code; however, defining system goals, component boundaries, and architectural trade-offs remained firmly in human hands.

An early ingestion prototype for migrating historical data from Git to Scion was hand-written by human engineers and initially considered solid. When engineers handed this code to Claude without additional tuning prompts, the model refactored it into an implementation with 1/20th the memory usage and 4x the throughput, while rigorously preserving all implicit temporal invariants.

Yet this introduced new friction: agents occasionally violated systemic constraints to satisfy local requirements, or over-engineered implementations out of excessive defensiveness.

• Multiple model-authored helper scripts attempted to linearly walk commit logs just to check when a change merged into trunk, rather than calling existing review tool APIs.

• During internal adversarial reviews, the model—overly anxious about a downstream microservice's reliability—autonomously piled on redundant validation layers and defensive code, causing architectural complexity to balloon.

• Shift in review focus: The team still reviewed every change, but shifted focus toward underlying intent, establishing cross-system contracts and firmly vetoing changes whenever models risked violating architectural invariants.

2. Trunk Moved During Testing: Rethinking Verification

In traditional engineering workflows, merge queues with global locks are widely used to keep trunk buildable at all times: commit A must pass full testing and merge before commit B can queue against the latest head.

However, when daily merges reach tens of thousands and multiple commits land every minute, hundreds or even thousands of other changes can land while a test run is in flight. Maintaining a repo-wide merge queue lock was simply unworkable.

Consequently, the team shifted verification heavily toward post-merge testing and pre-deployment validation. While concurrent merges inevitably produce logical conflicts, Anthropic reported that Claude can typically remediate them rapidly. The trade-off is accepting that issues may surface at merge time and catching them via post-merge and pre-deploy suites—an approach that requires comprehensive verification capabilities and does not eliminate code review.

3. Operational 'Superfans' for Monitoring

For observability, the team used internal tooling with Claude Tag in Slack channels to assign Claude instances to continuously monitor core infrastructure components.

• Dedicated Claude instances watched the scion-daemon process, guarded the scion-cache memory pool, and monitored the code review merge queue.

• Having access to relevant telemetry and logs, they continually scanned for anomalies. The team reported that this caught subtle and novel issues that traditional alert thresholds often missed, while standard alerts remained in place.

4. Hermetic Simulation and Semantic Permissions: Maintaining Quality and Guarding Sensitive Code Under High Throughput

As agent write throughput surged, maintaining test coverage and controlling access and approvals for sensitive code became critical. The team built two key defenses leveraging Claude and Scion:

• Ensuring test coverage with hermetic simulations: Under tight migration deadlines, Claude helped the team rapidly construct hermetic simulations modeling complex infrastructure and source control interactions, coupled with fuzzing and granular rate limiting. This mechanism simulated extreme edge cases and malformed inputs within isolated environments, surfacing latent defects and race conditions amid skyrocketing throughput while preventing bursts from overwhelming underlying services.

• Governing sensitive code via path permissions and semantic review: Scion natively supports granular repository- and directory-level permission controls, protecting sensitive modules while preserving the collaboration benefits of a monorepo. Its companion review tooling evaluates expressive semantic conditions, distinguishing trivial comment updates from sensitive logic modifications. This focused human review on truly critical changes, prevented inconsequential edits from blocking workflows, and strictly enforced permission and approval policies on sensitive code.

What Can Typical Teams Take Away?

Observing this migration, the most natural question developers ask is: Is Git truly obsolete? Should our team abandon Git too?

Typical engineering teams can continue using Git; Scion's advantages only materialize under massive repositories and high-frequency, always-online workloads.

Scion is tailored for very specific workload profiles:

• High cost of proprietary toolchains: Scion is not an off-the-shelf CLI tool. It is deeply coupled with Antique (Anthropic's proprietary code review platform), custom code search, and internal IAM systems. Any team attempting to replace Git would need to migrate their entire ecosystem of review, search, and CI tooling.

• Unreplicable compute allocation: Anthropic's internal token expenditure for AI agents far exceeds the R&D tooling budget of typical commercial organizations.

• Divergent operating contexts: For standard teams, Git's offline resilience and mature ecosystem remain invaluable; Scion is engineered specifically for massive monorepos and large numbers of automated agents.

Anthropic hopes to contribute some of these architectural insights back to the Git ecosystem:

1. Git servers should stop mechanically mirroring clients: Code hosting platforms like GitHub and GitLab could adopt asymmetric architectures similar to Scion—delegating heavy recomputations to servers and exposing granular RPC query endpoints, rather than compelling clients to download massive packfiles locally.
2. Reshaping negotiation and checkout protocols: While the Git ecosystem has long featured sparse checkouts and promisor remotes (partial clones), substantial room remains for unified optimization. Standardizing lightweight negotiation protocols for on-demand object streaming could eliminate the redundant transfer and maintenance costs borne by large-scale workloads.

This migration demonstrates that as AI accelerates code generation, bottlenecks inevitably shift toward storage, distribution, review, and verification. For typical engineering teams, the most valuable takeaway is auditing which tasks only require a query result, which files are being transferred redundantly, and whether central servers can take on more shared computation. Scion remains an internal Anthropic system, with no general-purpose version available for external installation.