Technology & Research · · Team LATENT
Why Anthropic moved from Git to Scion
Supporting more than 30,000 daily merges takes more than faster coding. Scion changes how code changes are recorded, history is queried and files are fetched, reducing the work done by development infrastructure.
Scion changes where the work of source control happens. Instead of making each client manage a large repository, Anthropic moved change recording and history queries to servers. Clients request the data their work needs. The aim is to make fetching and checking code keep pace with AI-generated changes.
In its October 13, 2026 announcement, Anthropic reported that daily merges rose from about 2,500 in May to over 30,000 in September. A merge integrates separately developed changes into shared code. That count is different from the number of commits recording changes or deployments to production.
Source: Anthropic’s Scion announcement
Key takeaways
- Distributing a huge codebase and its history across test environments became costly. Scion moves source-control work from clients to servers.
- Scion separates records of changed files from data used for fast history queries. Clients fetch only needed files and reuse nearby caches.
- Inexpensive history APIs also support automated investigation and reversal. Human review still addresses design constraints, and Scion is not offered as a public Git replacement.
Fetching code 25 million times a day
Anthropic uses a monorepo, a single repository holding many development projects. The history of main, its shared development line, approached 100 GB; a compressed working copy exceeded 25 GB.
CI automatically builds and tests changes. Before a job can inspect or execute files, it needs the right revision in its workspace; materializing those files is called a checkout. Anthropic reported about 25 million checkouts a day for CI alone.
Git manages code and history. With a normal full clone, a client can inspect past changes locally, even offline. That independence is useful. But repeatedly preparing a huge repository for short-lived test environments adds retrieval and maintenance work to every round of testing.
Background: Git’s distributed version-control model
The company already used partial retrieval, internal mirrors and prebuilt repository snapshots. Faster changes made snapshots fall behind more quickly. Maintaining correct comparisons and line history in partially populated repositories also became harder.
Move source-control work to servers
Scion is designed around agents and jobs that are already online. Clients do less repository management and ask servers to perform commits, merges and history queries. Because commits are created on the server, there is no later push step to share a locally created commit.
An API lets one program call another program’s functions. A job asking which files changed can receive an answer instead of first preparing a working copy. This separates jobs that need to execute files from jobs that only need repository information.
The distinction is where computation happens and how much data travels to the client. Git-based services can offer history APIs too. Scion extends that division of work into the client’s basic operating model.
Source: online clients and server-side APIs
Separate change records from history queries
Moving work to servers would accomplish little if every write became expensive there. Scion separates accepting change records from maintaining data that makes history queries fast.
A Git commit points to a tree describing the files at that revision. Trees connect names to file contents or other directories. Unchanged contents are reused; a commit does not copy every file again.
Scion’s changeset records changed files and references to their contents, relative to its first parent. For a merge with multiple parents, that first parent defines the comparison.
Git snapshots and Scion change records
Conceptual example: only file B changes
Git commit
Tree → A, updated B, C. Reuse the unchanged contents of A and C.
Scion changeset
Difference from first parent → record B and a reference to its new contents.
Derived query data
Build file-history and line-history data from change records.
Reading change records one by one would make a query increasingly expensive as history grows. Separate query structures avoid that repeated traversal. Scion can compute derived data in advance or when needed, rather than requiring every possible query structure to be materialized immediately.
Creating a changeset and updating what main points to are separate operations. Recording a change is therefore distinct from integrating it into main. The low-coordination write path described in the announcement concerns accepting change records at scale.
Fetch needed files from nearby caches
Jobs that need files still need not retrieve the whole repository. Scion clients request missing directory and file objects that their work requires. Unrequested directories stay unfetched, and files can be materialized when read.
Git can bundle objects into compressed packfiles for efficient storage and transfer. Scion requests particular objects instead. An object’s contents do not change under the same identifier, making copies reusable across jobs. Content-based identification also exists in Git; Scion’s retrieval protocol lets caches answer these individual object requests.
Find requested data through caches
Go to the next tier only on a cache miss
1 Reuse on the same node
Client → scion-daemon. Jobs on the same machine reuse downloaded objects.
2 Reuse within the region
Ask scion-cache for objects shared within the region.
3 Read authoritative storage
Scion servers read backing storage when needed and return the requested data.
For example, two tests reading the same file at the same revision can reuse the same object. Changed contents have a different identifier, so they remain distinguishable from the old contents. Reuse and selective retrieval reduce repeated work across many checkouts.
Bug investigation and design constraints
The API design also helps tools investigate regressions. Bisect tests revisions between known good and bad states to narrow the candidate change. Revert records a new change that reverses an earlier one. Both involve history operations, so reducing the work of maintaining repositories makes large-scale automation more practical.
Anthropic explicitly links its automated bisect and revert pipelines to inexpensive source-control APIs. This makes history easier for investigation and reversal tools to use; it does not make Scion a judge of program correctness. The announcement supplies no repair-success rate.
Source: APIs supporting automated bisect and revert
Testing strategy changed too. The team says it could not effectively reproduce a globally locked merge queue while hundreds or thousands of changes arrived during tests. It invested in post-merge and pre-deploy testing. Concurrent conflicts remain, with Claude reported to handle fixes.
Human engineers still enforce design constraints. One reported example concerns finding when a change entered main: agents tried scanning the commit log instead of asking the review system. Engineers redirected them. The design issue is that an answer obtainable from the responsible service should not require work that grows with the entire history.
The team says it still reviews every change request for this system, focusing on intent rather than every line. More automation is combined with human judgment about how components should work together.
Source: What we learned building Scion
LATENT’s ReviewBench article examines what code review can detect. Scion highlights another part of the problem: more code also creates more infrastructure work to run checks and investigations repeatedly.
Related: ReviewBench and code-review evaluation
Measured gains and migration costs
Anthropic reports the following outcomes. Each measures a different resource or stage, so they should not be combined into a single development-speed figure.
| Measured area | Reported change |
|---|---|
| Source-control CPU and memory | About 1/200 of the previous Git-mirroring infrastructure. |
| CI and research checkouts | Roughly two orders of magnitude faster: minutes to seconds. |
| CI CPU capacity | A reported 25% capacity gain. |
Source: performance report in Scaling Scion
The gains concern distributing code, preparing working copies and accessing history. They do not mean that every test runs 100 times faster. As agents generate more changes, the work done before a test can even begin becomes consequential. Scion redesigns that work.
The tradeoff is dependence on reachable servers and bespoke infrastructure. Scion gives clients less of Git’s local independence, and migration also involves review, search and CI. It is not offered as a public Git replacement. These results do not establish that the same migration would benefit a small project.
The lesson is about the unit of work: growing code generation can require changes to how code is fetched, integrated and checked. Anthropic shifted work from individual clients to services and organized it around changes and the files a job actually needs.
Sources
Checked against the announcement and official Git documentation on October 14, 2026. Figures are LATENT conceptual illustrations based on those sources, not complete internal architecture diagrams. Performance figures are Anthropic’s reports, not independent measurements.