Agent-scale source control starts with a checkout amplification budget

Anthropic’s 13 October engineering account describes an internal migration from Git to Scion, a service designed for enormous repositories and online agents. It reports roughly 2,500 daily merges in May and more than 30,000 in September, alongside around 25 million daily CI checkouts. Those are company-reported workload measurements, not a representative sample of software teams.

The interesting design change is where work happens. Scion moves history queries, commits and merges to a service; clients request the content they need. Anthropic says its cache tiers are deliberately isolated so a regional failure does not overwhelm upstream services. It explicitly warns that Scion is not a general Git replacement and that its internal token budget is unusually large.

Measure the amplification before selecting the architecture

For another engineering organisation, the first decision should be diagnostic. Define checkout amplification as the relationship between repository content actually needed by a job and the bytes transferred to make it available. Record both quantities rather than announcing a universal acceptable ratio. A test that only times a warm developer checkout could miss the dominant cost of fresh agent sandboxes.

Segment the measurement by workload: interactive development, short-lived CI, research jobs and agent tasks. Capture cold and warm starts, history depth, file coverage, cancellation and retries. Count wasted transfers for jobs abandoned before using the files. These are proposed local measurements, not results established by Anthropic’s post.

The baseline must include simpler options. Git’s sparse-checkout documentation describes reducing the working-tree file set, while noting that its interaction with other Git features can be complex. Sparse checkout is not itself a promise of equivalent network savings. Compare the exact shallow, partial, sparse and caching configuration your jobs would use; otherwise a new architecture may win against an unnecessarily expensive baseline.

A practical pilot would replay a fixed, representative set of jobs against the current setup and one constrained alternative. Keep test inputs, region and concurrency comparable. Measure startup latency, network transfer, compute, cache warm-up and total operator effort. Report distribution tails as well as averages. A small improvement in ordinary jobs may not offset a rare repository-wide stall.

Moving less data can move more responsibility

An online source-control service changes the recovery question. Instead of asking only whether a developer has a complete local repository, ask which operations remain possible when the service, cache or regional network is unavailable. Enumerate reading a file, reviewing a diff, identifying a release, applying an emergency revert and reconstructing history. The answer can differ for each operation.

Test a cold cache during an upstream incident, not merely the loss of one healthy cache. Predeclare request limits, back-pressure and a controlled restart order. Preserve an independently recoverable release identity and demonstrate restoration from backups. These are engineering acceptance criteria proposed here; they do not allege an undisclosed Scion incident or certify an alternative design.

The skills implication is specific. Platform engineers must be able to reason about content-addressed storage, workload traces, dependency boundaries and degraded operation. Producing more code does not remove the need to explain which invariants a migration preserves. This extends the newsroom’s earlier discussion of integration evidence for parallel agents into an infrastructure purchasing and build decision.

Anthropic’s account is useful because it exposes an unusual workload and its architectural response. It does not independently establish general cost savings, migration safety or productivity. Keep the existing source-control system unless a representative pilot shows that a named bottleneck is material, simpler mitigations are insufficient, and the recovery burden remains acceptable. The decision is not whether agents make Git old-fashioned; it is whether your measured workload justifies operating a different system.