Anthropic replaces Git with in-house source control for its monorepo

• Anthropic migrated its monorepo from Git to Scion in five months; its announcement puts daily merged changes at roughly 2,500 in May and more than 30,000 in September.
• Scion assumes always-online clients: the linked engineering post describes server-side commits, merges, and history queries, with lightweight clients fetching data on demand.
• Weekend merges gained share, rising from about 7% to 18% in scaling01's analysis of Anthropic's chart.
• Growth was heavily concentrated late in the period: scaling01's cumulative chart places half of January-to-September merges in the final 50 days.

No complete repository copy exists anywhere in Scion's architecture, even on the server. Anthropic also describes Slack “superfans” dedicated to individual infrastructure components, plus a Claude rewrite that made its Git ingestion pipeline 4x faster with 20x less memory.

Seven engineers built and migrated Anthropic to the new stack while daily merge volume increased more than tenfold, according to the engineering account. The work included:

• Scion: the source control system.
• Antique: the code review interface.
• Code search.
• Source control IAM.
• Workflows for managing and landing large volumes of reviewed code.

Anthropic's Git workload had reached:

• Almost 100 GB of history on the main branch alone.
• More than 25 GB for a compressed working copy.
• Roughly 25 million CI checkouts per day, excluding developer environments, agent sandboxes, and research jobs.
• More than 600 PB of daily traffic if those checkouts were fetched naively. That is a counterfactual calculation, not measured traffic.

The company had already tried Git's partial-repository mechanisms and operated several hundred internal mirrors. Repository snapshots fell further behind main between refreshes, while history-dependent operations such as diff and blame became harder to maintain on partial clones.

Scion follows six design principles:

1. Always-online clients. Agents and jobs fetch data from a reachable server when needed.
2. Client-server asymmetry. Servers perform history queries, blame, commits, merges, and rebases. Clients keep bounded caches and manage working-copy files.
3. Source control APIs. Tools can query ancestry or request diffs without maintaining local repositories; automated bisect and revert pipelines use this interface.
4. Horizontal scaling. Repository data is distributed across independently scalable components, without Git-style packfiles or whole-repository mirrors.
5. Cheap, incremental, lock-free commits. Work scales with the change size. Routine development discourages shared refs, except for main and release branches.
6. Optional working copies. Sparse checkouts contain requested directories; virtualized checkouts materialize files only when read. Some write workloads run entirely through APIs.

The client consequently depends on server access for operations that Git can perform offline. Anthropic cites Google's Piper and Meta's Sapling as prior art.

Scion's unit of work is a changeset in a write-ahead log. Its payload contains:

• The files changed relative to its first parent.
• Content-addressed pointers to compressed file contents in blob storage.

Creating or fetching changesets does not move a ref. When a ref does move, the update is a separate compare-and-swap on a single Spanner row.

Scion builds additional structures to answer queries that a file-change list cannot answer efficiently:

• Dedicated blame and path-history structures.
• Skip lists for the commit graph.
• Indices for copy detection and path-based file search.

Each type of “derived data” is defined recursively from its values for parent changesets. Anthropic can compute it eagerly or lazily, add new structures, and optimize their internals without changing the client.

The scn client requests specific missing trees and blobs, rather than telling the server everything it already holds. Requests identify immutable objects, making the fetch protocol cacheable and resumable without a multi-gigabyte packfile response.

The fleet uses three tiers:

1. scion-daemon: a node-local object store shared by jobs, initialized from a periodically refreshed snapshot.
2. scion-cache: regional servers streaming objects from memory in the daemon's disk format, without per-client delta compression.
3. scion-server: authoritative servers reading from Spanner or cloud storage when upstream caches miss.

All three implement identical RPCs. Anthropic nevertheless enforces the tiering to prevent a failed regional cache from flooding authoritative servers and causing a system-wide outage.

The company reports:

• Over 99% cache hit rates at each tier.
• 1/200 of the CPU and memory footprint of its previous Git mirroring infrastructure.
• Two orders of magnitude faster checkouts, taking seconds rather than minutes.
• A 25% CPU capacity win in CI.

An early internal snapshot of Claude Mythos Preview rewrote the largely handwritten Git-to-Scion ingestion prototype. Anthropic says the rewrite preserved implicit ordering and data-structure invariants while delivering the speed and memory improvements described above.

Engineers still review every change request to the system, but examine intent rather than every line, according to the team's account. Two recurring problems required human intervention:

• Agents scanned the commit log linearly to discover when a change merged, instead of asking the review tool.
• Adversarial review prompted excessive validation and complexity around a trusted internal service.

The team also built hermetic simulations of infrastructure and source control interactions, fuzzing, and rate limiting.

That review model drew skepticism from engineers outside Anthropic. In the Hacker News discussion, commenter duttish said that stopping review of Claude-generated code still led them to discover defects later.

Scion's access controls operate at both repository and individual-directory levels, allowing sensitive code to remain inside the monorepo.

Antique can express semantic constraints on approvals. Anthropic gives comment-only edits versus sensitive logical changes as an example of changes that can receive different review treatment.

Anthropic uses Claude Tag in dedicated Slack channels to follow component health, with access to telemetry and logs. Its “superfans” include agents focused on:

• scion-daemon.
• scion-cache.
• The Antique merge queue.

Traditional alerts remain in place. Anthropic says the agents additionally detect subtle or novel issues that fixed alerts miss.

The gutsiest change is in CI: Anthropic says it could not effectively reproduce a global repository lock on the merge queue at this scale.

Hundreds or thousands of changes can land while tests are running. The company has invested instead in post-merge and pre-deploy automated testing, accepting that concurrent changes can conflict; it says Claude can typically repair those conflicts faster than humans identify them.

Community analyst scaling01 digitized Anthropic's published chart and reported three patterns:

• Weekend share: roughly 7% → 18%, with Monday through Wednesday losing the most share.
• Doubling time for daily merges: 67 days in January–May → 41 days in May–July → 20 days in August–September.
• Launch timing: growth accelerated roughly five weeks before some public model launches, which scaling01 suggested could reflect earlier internal availability.

The public release dates in Simon Willison's annotated chart are explicitly distinguished from dates of internal access.

A separate cumulative reconstruction estimates approximately 861,000 changes through September 9: the first half took 202 days, and the second half took 50. These totals were digitized from the published plot.

scaling01 also estimated that automatic merges overtook human-supervised merges around July and reached roughly two thirds of the total by early September. The estimate assumes:

• Every weekend merge is automatic.
• Automatic merging runs at the same rate every day.

Under that model, automatic share equals weekend share multiplied by 7/2: an 18% weekend share implies about 63% automatic merges. The same analysis extrapolates to 100% around spring 2027; both the inferred share and projection depend on those assumptions.