
Coding agents need a source-control budget
In short: Agent-scale source control is a capacity problem: track checkout bytes, repository operations and CI CPU per accepted change before migrating.
Anthropic said on 13 October 2026 that its merged changes rose from about 2,500 per day in May to more than 30,000 in September. The company replaced Git for its monorepo after source control became its biggest development bottleneck.
The useful lesson is not that coding agents have killed Git. Coding agents need a source-control budget: track how much repository and CI work each accepted change creates before you add mirrors, buy more capacity or attempt a migration.
Anthropic's source-control budget broke at checkout scale
1/ Anthropic's Scion engineering account describes a workload most teams do not have. Its main-branch history was nearly 100 GB, a compressed working copy exceeded 25 GB and CI performed roughly 25 million checkouts per day.
The often-repeated 600 PB figure is a naive transfer envelope: what those checkouts would fetch if every one pulled the compressed working copy. It is not reported network traffic. That distinction matters because a dramatic upper bound is useful for architecture, but dishonest as an observed bill.
2/ Git's strength became part of the cost. A clone can hold history, compute diffs and blame, and work offline. Anthropic says most of its clients were agents and jobs that were online by definition, so repeatedly carrying offline capability into short-lived workers amplified data movement and maintenance.
3/ Scion changed the unit of access. Clients keep a bounded cache, working copies are sparse or optional, and jobs can ask server APIs for diffs, ancestry and blame without materialising a repository. Each cache tier reportedly exceeded a 99% hit rate.
This is not merely faster cloning. It moves repository questions to a service and makes local materialisation something a task earns by reading files.
Three ratios reveal source-control amplification
4/ My proposed source-control budget has three ratios: bytes fetched per accepted change, source-control operations per accepted change, and CI CPU consumed per accepted change. Measure the ratios by repository, workflow and agent pool. Generated lines are a vanity denominator; accepted changes are closer to delivered work.
5/ This is labelled editorial judgement from platform reviews, not a Scion deployment I have run. I would start with one week of existing telemetry: clone and fetch bytes, checkout count, cache hit rate, CI CPU, merge count and changes that survive review. The first intervention should target the ratio growing fastest.
If bytes dominate, try a narrower checkout. If repeated history queries dominate, expose a cached service. If CI CPU grows while accepted changes stay flat, the expensive boundary is verification rather than source control.
6/ Git already has an intermediate path. Its official partial-clone documentation supports omitted objects and demand fetching, while sparse checkout limits the working tree. The same documentation warns that one-at-a-time dynamic fetches can be slow and require the remote to remain available.
That gives a practical gate: exhaust measured partial and sparse strategies before concluding the source-control model is wrong. A bespoke system transfers cost into migration, code review, search, identity, CI and operations.
Anthropic's result is evidence, not a default architecture
7/ Anthropic reports that Scion used 200 times less CPU and memory than its previous Git mirroring infrastructure, made CI and research checkouts two orders of magnitude faster and returned 25% of CI CPU capacity. These are internal, first-party results. Scion is not public, and I did not reproduce its performance or reliability.
8/ The surrounding scale is equally unusual. Anthropic separately reported about 30,000 concurrent research and engineering agents on its most-used internal platform in August 2026. The company itself says Scion is not a general Git replacement and would require the rest of the development lifecycle to migrate with it.
So steal the accounting, not the architecture. When agent throughput rises, ask which read, review and verification costs rise faster than accepted output. Replace a tool only when the measured amplification and its trend justify replacing the surrounding system too.
What's in it for you
- Put checkout bytes, repository calls and CI CPU beside accepted changes on the same weekly chart.
- Test partial clone, sparse checkout and shared caches against the largest ratio before funding a migration.
- Keep vendor-reported speedups separate from the capacity evidence in your own estate.
Code became cheaper at Anthropic; the scarce resource moved to reading, reviewing and integrating it. Budget that boundary before adding another agent.
Sources
- Anthropic — Redesigning source control at Anthropic, 13 October 2026.
- Anthropic — Measurements for understanding the pace of AI development inside frontier labs, accessed 15 October 2026.
- Git — Partial clone documentation, accessed 15 October 2026.


