Anthropic replaces Git with Scion as daily merges surge

Anthropic says it migrated its monorepo from Git to Scion in five months. Its October 13, 2026 engineering account reports about 2,500 daily merges in May and over 30,000 in September. Seven engineers built Scion, its Antique review interface and related systems.

For teams adopting coding agents, the useful question is how quickly verified work reaches users. Generating more changes also creates more work for the systems that distribute code, run tests and control releases. Measuring that whole path is essential before deciding which part to replace.

What the infrastructure numbers measure

Scion handles commits, merges and history queries on servers. Clients retrieve needed files through shared caches. It records changed files with pointers to their contents, then derives history indexes. Anthropic reports a 200 fold smaller CPU and memory footprint than its Git mirrors, roughly 100 times faster checkouts, and a 25 percent CPU capacity gain in continuous integration. These are internal results.

A merge count alone cannot establish how many changes were autonomous, how much review each received or how many defects escaped. Faster checkout is useful operational evidence, but a team evaluating its own workflow also needs release lead time, failure rates and the cost of repairing bad changes.

Anthropic says its engineers review each Scion change request for intent. The disclosure describes specialized review, search and testing infrastructure and announces no public release of Scion.

Git already separates downloading from checkout

Two existing Git features address different parts of the data problem. Partial clone can leave out objects during the initial transfer and retrieve missing objects later. A promisor remote supplies those deferred objects. That reduces what has to arrive before work begins, but a later request for missing content still requires a reachable remote. Partial clone can also be used alongside shallow history rather than replacing it.

Sparse checkout controls which tracked files appear in the working directory. Git’s default cone mode selects directories. A sparse index can also reduce index size, although the manual warns that external tools may not understand it and some commands may behave differently. A smaller checkout and a smaller initial download therefore solve related but distinct problems.

A practical trial should exercise the whole job. Run the build, tests, dependency discovery and any history queries against the reduced checkout. Record subsequent network fetches as well as startup time. Otherwise a faster initial clone can hide waiting that has merely moved to a later stage.

A different server can preserve Git

Cursor’s August 18, 2026 engineering account of Continuity describes another approach. It persists pushes to a log in S3 while keeping normal Git repositories on local disks. Replicas can reuse compacted data instead of repeating the same maintenance. Cursor reports up to 120 pushes per second on S3 Standard and over 300 on S3 Express One Zone. Those are the company’s results for its own system, with different storage configurations.

The comparison needs discipline. A push is not necessarily a reviewed merge. Repository size, change size, read traffic, hardware and durability requirements all affect the work being measured. These disclosures do not establish a winner from their headline throughput figures.

Meta’s Sapling documentation shows another distinction. Its public command line client can work with Git repositories, while its large scale internal setup combines the client with a server and virtual filesystem that the introduction says are not publicly available. Adopting a familiar interface and obtaining an entire company’s internal infrastructure are different commitments.

Test the exact revision you intend to release

GitHub’s merge queue documentation describes testing a proposed change together with the current target branch and earlier queued changes. For GitHub Actions, required workflows must handle the merge_group event. A workflow that runs only for a pull request or push can leave the queue waiting for a required result that never arrives. The queue also exposes build concurrency and merge limits as separate settings.

That distinction matters when agents submit work concurrently. A passing test result is evidence about a particular combination of code. Before changing where tests run, define which revision may enter production, how failures block deployment and who owns a rollback. A faster queue is valuable only if the release process still knows what it has checked.

What to measure before changing systems

ByteForward’s practical recommendation is to run a bounded infrastructure experiment before planning a source control migration. Use a representative repository and a realistic mix of human and agent jobs, then compare the same workload before and after each change.

• Separate the waiting. Record time spent fetching objects, creating working files, waiting for a runner, executing tests and waiting for review. A single total duration conceals the cause.
• Measure repeated work. Count bytes downloaded per job and repeated reads across jobs. Compare a fresh runner with one that has already processed the same revision.
• Keep correctness checks. Exercise history lookup, change detection and rollback tooling. Confirm that reduced repository data does not silently alter their answers.
• Test a degraded service. In an isolated test environment, observe what happens when the source control service is slow or unavailable. Establish how jobs fail and recover.
• Price the whole migration. Include engineering time, hosting, support, review integrations and recovery procedures. Savings in one subsystem can create costs elsewhere.

The decision should turn on a measured bottleneck and a recoverable plan. A team that spends most of its time waiting for reviews will get little from optimizing file transfer. A team repeatedly moving the same large repository may have a much clearer experiment to run. Start with the operation that is consuming the time, prove the improvement and keep the evidence attached to the decision.