Anthropic’s Source-Control Problem: What 30,000 AI-Assisted Merges a Day Requires

FuturPulse analysis · 14 October 2026

On 13 October 2026, Anthropic disclosed that its main repository exceeded 30,000 merged code changes daily in September, up from about 2,500 in May, and that it had replaced Git with its Scion system after a five-month migration.

What did Anthropic actually ship?

Anthropic shipped an internal source-control stack, not merely a faster Git server. Its core is Scion, a client-server version-control system for the company’s monorepo, or single repository containing much of an organisation’s code. The accompanying systems include Antique for code review, code search, access controls and new methods for landing reviewed changes, Anthropic said.

The important distinction is architectural. Git normally gives each clone the whole repository history, which makes offline work and local inspection possible. Git’s own documentation says distributed clients fully mirror a repository, including its history, rather than only fetching the latest files.

Scion instead assumes most clients are continuously connected. That fits Anthropic’s stated workload because many clients are automated jobs and coding agents, rather than laptops expected to work without a network. The server creates commits, performs merges and answers history queries; the client keeps a limited cache and lays out the requested files locally, the company’s engineering account says.

This does not mean Git has failed for ordinary teams. Anthropic explicitly says Scion is not a general Git replacement. Its design trades away a full offline repository in return for less repeated data movement and central APIs that automated workers can query directly.

When did the promise become a shipped system?

Anthropic did not publish a public product roadmap for Scion before its 13 October account. The timeline therefore separates the workload it reported from design commitments and the system it says was already in production. “Promise” here means a stated technical goal, not a customer delivery date.

Our calculation

Using Anthropic’s stated figures and treating “over 30,000” as exactly 30,000, the minimum increase was 27,500 merged changes per day. That is a conservative floor, not an estimate of the true September total. The same arithmetic puts September at at least 12 times May’s reported rate.

Source: Anthropic’s published merge-rate figures; arithmetic by FuturPulse.

Why did Git become the bottleneck?

The problem was not that Git cannot merge code. It was the cost of repeatedly distributing a huge repository to automated workers that often needed only a few files or a narrow answer. Anthropic says a naive fetch pattern at its scale would move more than 600 PB of Git traffic each day.

That figure follows from a repository with almost 100 GB of main-branch history, a compressed working copy above 25 GB, and about 25 million CI checkouts daily, Anthropic said. For a developer, the practical consequence is simple: a build worker should not need a full project copy merely to compare two revisions or locate a changed line.

Anthropic had used shallow clones, sparse checkouts, promisor remotes, snapshots and several hundred internal Git mirrors. Those measures deferred the problem but created new work: mirrors needed capacity, snapshots became stale, and tools requiring history had to operate against partial repository copies.

Large companies have faced versions of this problem before. Meta says its Sapling system supports massive monorepos through a server component and a virtual filesystem that only materialises files when workers access them. Sapling’s public project describes its goal as making operations depend on the files a developer uses, not the full repository size.

Anthropic’s added pressure is agent volume. A human can tolerate a slow checkout occasionally. Thousands of automated workers turn the same delay into a capacity bill, a queue and an infrastructure failure risk.

How does Scion make 30,000 merges workable?

Scion makes a changeset, rather than a conventional Git commit, its unit of work. A changeset records files altered against its first parent and points to compressed file contents stored by content address, meaning the data’s identifier is derived from its contents. Because immutable content can be cached safely, servers need less coordination, Anthropic says.

That enables a useful split. Scion servers answer questions about history, diffs, merge bases and blame, which identifies who last modified a line. Automated tools can ask through an API without first creating a local repository.

Checkouts use three tiers: a local daemon, regional cache servers and authoritative servers. Anthropic says each layer maintains a cache-hit rate above 99%, while snapshots seed the daemon and regional caches stream objects in the disk format the daemon consumes. This avoids repeatedly computing missing objects or performing delta compression for every client.

There is still coordination where it matters. Anthropic says moving a ref, a pointer such as a branch or tag, is a compare-and-swap operation on one Google Spanner row. Google’s Spanner documentation explains that read-write transactions execute atomically, while conflicting writes can require retries.

The design choice is to avoid making refs the centre of routine work. In Scion, creating and retrieving changesets does not require a ref move. That reduces global state, which becomes costly when many workers concurrently try to advance the same visible branch.

Does faster merging solve AI code review?

No. Faster source control removes a transport and coordination constraint; it does not prove each merge is useful, safe or correct. Anthropic says every system change request is still reviewed, but engineers increasingly assess the intended change and system-level constraints instead of manually reading every generated line.

That is a different operating model from “let agents merge freely.” Anthropic says Antique can apply semantic approval rules, including rules that distinguish comment-only edits from sensitive logic changes. Scion also supports repository and directory-level access control, allowing sensitive code to receive narrower permissions.

The company’s own account is unusually direct about the human role. It says agents can satisfy a local pattern while violating a core constraint, and that adversarial model review can become too focused on hypothetical risks. Engineers had to reject over-engineered agent proposals and stop inefficient solutions, such as linear scans of a commit log.

Broader evidence points to the same limit. In a study of roughly 200 million engineering work events across 100,000 engineers at 500 firms, Fiona Chen and James Stratton found AI coding tools increased code output but did not show a corresponding effect on task output, composition or employment. Their January 2026 paper examined Copilot and Cursor, so it is not a measurement of Anthropic’s internal system.

A later report on the research frames code review as the downstream bottleneck. Anthropic’s response is more structural: put review policy, source permissions, automated tests and post-merge detection into the delivery system that agents use.

What changes for teams using coding agents?

Most teams do not need Scion. Anthropic says its approach makes sense for enormous monorepos with tens of thousands of engineers or swarms of prolific agents. A small team usually benefits more from disciplined Git practices, narrow agent permissions and reliable tests than from replacing version control.

But the design yields four practical lessons for organisations whose agents are already producing many changes:

• Measure merges and checkout demand separately. Code generation can rise before repository traffic becomes visible as a cost.
• Expose repository facts through APIs. A bot that needs a diff, blame result or merge base should not always clone an entire repository.
• Classify risk before review. Treating a documentation edit and an authentication change as identical review events wastes scarce human attention.
• Test after merge as well as before it. Anthropic says hundreds or thousands of changes can land while tests run, making a global merge lock impractical.

The final point is the sharpest break from a human-scale workflow. Anthropic says it has invested in post-merge and pre-deployment testing because it cannot effectively reproduce a traditional global repository lock at agent scale. Concurrent changes can conflict, but the company says Claude often fixes conflicts faster than a person can first identify them.

What does the public merge chart add?

Anthropic’s article gives only the headline endpoints and an image. Independent developer Simon Willison published a reconstruction using values extracted from Anthropic’s chart for 1 January through 9 September 2026, with markers for public Claude releases. The accompanying code repository says some readings are flagged as uncertain.

That reconstruction is useful because it makes the shape of the rise inspectable, but it does not establish causation. Willison explicitly notes that the release markers are public dates, not dates when models became available internally. The safe conclusion is that merge volume rose sharply during 2026, not that any one public model launch caused the increase.

Willison’s analysis also highlights a consequence often missed in coverage: Scion is a centralised service built for clients that are presumed online. That is rational for agent sandboxes and CI, but it is a real trade-off for developers who need full offline history and independent local recovery.

What could break in an agent-scale merge system?

The main risk is moving a bottleneck rather than removing it. Faster commits can create more review work, more flaky tests, more deployment conflicts and more demand for privileged repository access. A source-control service must also withstand cache failures without overwhelming its authoritative tier, which Anthropic says it addresses by enforcing strict cache-to-server tiering.

There is also an organisational risk. Central APIs make automation easier, but they concentrate power in the source-control service and its permissions model. An incorrect directory rule, weak approval policy or overly broad agent credential could now affect changes at a scale that a slow local workflow once limited.

Anthropic’s answer is layered: directory permissions, semantic approvals, fuzzing, rate limits, simulations and agent “superfans” that watch logs and telemetry. Those controls are described by Anthropic, but its post does not publish incident rates, false-positive rates, security-test results or the frequency with which automated monitors prevent a production failure.

What we could not verify?

Anthropic has not publicly released Scion’s source code, its protocol, its pricing, a migration guide or a supported product plan for outside organisations. It has also not published the exact September peak, the proportion of changes authored by agents, or the rate at which merges later needed reverts.

The company could settle those questions through a technical specification, anonymised reliability data and a clearer account of review outcomes. Until then, Scion is best understood as evidence of Anthropic’s internal operating scale, not as an off-the-shelf alternative to Git.

Sources

• Anthropic — Redesigning source control at Anthropic
• Pro Git — About Version Control
• Meta Sapling — source-control project
• Google Cloud Spanner — Transactions overview
• Chen and Stratton — Artificial Intelligence in the Firm
• Ars Technica — AI coding agents generate more code, but not more software
• Simon Willison — Changes merged per day reconstruction
• Simon Willison — Redesigning source control at Anthropic