Contents
Git was built for people with laptops and intermittent connections: you cloned once, worked offline, and pushed when you reconnected. Anthropic’s engineering post on redesigning source control describes the inversion: nearly all of its clients are “agents and jobs that are online by definition.” The useful question is not whether git survives that, but which costs of a fetch recur on every connection, and what a different design does instead.
Two costs recur on every fetch at agent scale
A git fetch has two per-connection costs: the ref advertisement (what the server has) and a pack computed for what the client lacks. Anthropic’s own figures imply about 24 GB per naive checkout: 600 PB of naive git traffic per day divided by roughly 25 million CI checkouts per day (our arithmetic on Anthropic’s two numbers, not a figure the post states). The payload is the one term Anthropic lets us size. The advertisement is a per-connection cost that multiplies with client count and refs, but nothing published quantifies it.
Anthropic publishes no negotiation latency, round-trip count, or bytes-on-wire figure, so the cost breakdown here is analysis drawn from the documented protocol and the post’s published counts, not a measurement.
How git’s fetch negotiates today
The pack protocol documentation states the goal: the server tells the client “what is currently on the server, then for the two to negotiate the smallest amount of data to send in order to fully update one or the other.” Upload-pack runs on the server, fetch-pack on the client, over ssh, git, http, and file transports.
Protocol v2 turns this into named commands: ls-refs, fetch, and object-info. Its server-option, session-id, and object-format entries are capabilities, not commands. ls-refs accepts a ref-prefix argument so a client can ask for a subset of refs. The doc calls the prefix “purely for optimization” and says a server may still show refs that do not match. object-info exists “to allow a client to make decisions based on this information without having to fully fetch objects,” and currently reports only object size.
Why agent clients change the arithmetic
Anthropic reports about 2,500 code changes merged per day in May 2026, over 30,000 by September, a main-branch history of almost 100 GB, and a compressed working copy over 25 GB (Anthropic).
Analysis: a developer laptop accumulates objects over months, so its later fetches are small and its haves set is large. An agent sandbox often starts with an empty object store. It has little to offer the server, so it gets none of the amortisation a long-lived clone enjoys, while still paying for the advertisement and the transfer on every connection. Multiply that by millions of short-lived clients and the number of cold connections becomes the cost to watch.
Partial clones shrink the pack; sparse checkout narrows the working tree
Git’s documented options reduce what is transferred or checked out. A shallow clone (--depth) limits history, and partial clone filters such as --filter=blob:none defer blobs to later promisor fetches (git-clone, partial-clone). Sparse checkout in cone mode narrows the working tree and uses “faster hash-based algorithms to compute inclusion” (git-sparse-checkout).
The partial-clone doc draws a useful line. A lazy fetch “sends a request with the hashes of all requested objects, and does not perform any packfile negotiation.” But the doc also records that dynamic object fetches currently use pack protocol v0, where “the server will send a full set of info/refs when the connection is established,” and it lists investigating protocol v2 to avoid that broadcast under Future Work. So the advertisement cost persists on lazy fetches today. The same document rejected a single list of missing objects because “if there are 100M missing blobs, this file would be at least 2GiB on disk,” which shows missing-object bookkeeping was a real constraint inside git.
Anthropic ran the same ladder: shallow clones, sparse checkouts, promisor remotes, and “several hundred internal git mirrors.” Its seeds “fell further from the tip of main between refreshes,” which makes staleness a cost that grows with merge rate.
What Scion does instead: request trees and blobs, not history
Anthropic describes a different client protocol. In its words, “Scion’s negotiation doesn’t tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs.”
That drops the haves exchange rather than tuning it. Because every request names an immutable object, “any cache can answer it,” and the cache servers “don’t need to spend time computing the client’s missing objects or performing delta compression.” Sparse and virtualized checkouts need no special support, because “the client simply doesn’t ask for trees it doesn’t want.”
Anthropic’s reported results, all internal and unreplicated: its Scion infrastructure footprint is “200x smaller than our previous git mirroring infrastructure” in CPU and memory, each cache tier holds a hit rate “over 99%,” CI and research checkouts run in seconds rather than minutes, and CI alone “realized a 25% CPU capacity win.”
| Approach | Haves/wants exchange | Ref advertisement | Payload | Source |
|---|---|---|---|---|
| Full clone | Protocol v2 notes negotiation may “not even begin if performing a clone” | Omitted unless requested via ls-refs on v2; full on v0 | Everything the client lacks | protocol-v2 |
Shallow clone (--depth) | Negotiation still runs; history depth is capped | Same as full clone | Recent history only | git-clone |
| Blob-filtered clone | Initial clone negotiates; lazy blob fetches do not (per partial-clone doc) | Lazy fetches use v0, which sends full refs on connection | Trees and commits now, blobs on demand | partial-clone |
| Sparse checkout | Unchanged | Unchanged | Working tree narrows; fetch unchanged | git-sparse-checkout |
| Mirror or seed | Still negotiates against the mirror | Depends on mirror | Shorter network distance; staleness cost | Anthropic |
| Scion client (per-object requests) | No haves sent; requests missing trees, then blobs | Not described in the post | Per-object and cacheable | Anthropic |
The git rows are analysis drawn from the cited docs; Anthropic does not describe Scion’s advertisement path.
Caveats before copying any of this
Anthropic states that “Scion is by no means a suitable replacement for git for general use,” and says its internal tools are bespoke. The post does not claim Scion replaces git’s wire protocol. It says only that “the negotiation protocol doesn’t have to look exactly like it does today.” None of Scion’s results has been independently reproduced.
Anthropic’s footnote identifies Mononoke as “the server component of Sapling,” which “pioneered many of the techniques we use in Scion.” Sapling’s home page says its client “supports cloning and interacting with Git repositories” (Sapling). That is a client-side compatibility claim, worth testing against your own forge, and not a benchmark.
Practical moves for git-based teams
- Ask the forge for the answer. A job that needs one diff against a merge base may not need a repository at all. A forge diff or contents API avoids the fetch entirely. This is analysis: it applies only if your forge exposes that endpoint.
- Fetch one ref, filtered and shallow.
git fetch --filter=blob:none --depth=1 origin <ref>shrinks the pack. It does not remove the ref advertisement, so it helps payload more than per-connection cost (git-fetch documents both flags). - Do not rely on v2 ref-prefix for correctness. Where your client negotiates protocol v2,
ls-refswithref-prefixcan trim the advertisement, but the doc treats the prefix as optimization only. - Budget for mirror drift. Anthropic’s seeds fell behind main between refreshes. Refresh cadence is a cost to plan, not a detail.
FAQ
Does agent scale break git’s bandwidth or its negotiation first?
The measurable term is bandwidth: dividing Anthropic’s 600 PB/day estimate by roughly 25 million daily checkouts gives about 24 GB per checkout (our arithmetic). The per-connection ref advertisement is the second cost and grows with client count and refs, but no published figure measures it, so neither ordering can be settled from public data (Anthropic).
Do sparse checkouts and partial clones solve the negotiation problem?
Partial clones remove the packfile negotiation for lazy blob fetches, but the partial-clone doc says dynamic fetches still receive a full set of refs on connection under v0. Sparse checkout narrows only the working tree (sparse-checkout).
Should my team abandon git for agent workloads?
No. Anthropic says Scion is “by no means a suitable replacement for git for general use” (Anthropic). For agent jobs, use filtered and shallow fetches and forge APIs for single diffs, and keep full clones for jobs that need history.
The Bottom Line
Git’s fetch assumes a few human clients with local history that makes each connection worthwhile. Agents break that assumption: they start empty, they die young, and there are very many of them. The per-connection ref advertisement and the per-client pack both recur on every fetch. Git’s documented partial options shrink the pack without removing the advertisement. Anthropic’s Scion drops the haves exchange for its own workload by having clients request immutable trees and blobs that any cache can serve. That is an internal result, not a general recommendation.
How This Guide Was Built
This review is based on Anthropic’s engineering post (full text fetched; key sections checked against the saved copy), git’s pack protocol, protocol v2, and partial-clone documentation, the sparse-checkout, git-clone, and git-fetch pages (flags and sections checked in the saved copies), and Sapling’s home page. We did not run the tools hands-on. No negotiation latency, round-trip, or bytes-on-wire numbers appear because none are published; the 24 GB per-checkout figure is our arithmetic on Anthropic’s two numbers, and architecture reasoning is labelled analysis throughout.
