Agent-Scale Source Control: What Anthropic's Scion Says About Git's Ceiling

On October 13, 2026, Anthropic's engineering team published something platform teams should read twice: they migrated their monorepo off git entirely. Not to a fork, not to a wrapper — to Scion, an in-house, server-authoritative version control system built in five months by a team of seven, because AI coding agents pushed their merge rate from ~2,500 changes per day in May to over 30,000 per day by September 2026.

The reflexive take is "Anthropic is exotic, this doesn't apply to me." The correct take is more uncomfortable: agents are now the fastest-growing class of source-control client in the industry, the failure modes Anthropic hit are structural properties of git (not Anthropic bugs), and every organization running agentic coding at volume is somewhere lower on the same ladder. This piece walks the ladder — with the numbers Anthropic published, the git behaviors we reproduced ourselves on synthetic repos, the cost math for the mirror-fleet pattern that breaks first, and the honest verdict on what you should actually do this quarter. (Spoiler: almost none of you should build a VCS.)

The Numbers That Broke Git

Anthropic's own figures from the post, in one place, because each one represents a distinct scaling wall:

Do the arithmetic on the naive-fetch number, because it frames everything else: 25 million checkouts × 25 GB working copy = 625 PB/day if every checkout fetched full history. Anthropic's "over 600 PB" claim checks out exactly. No optimization of git's wire protocol survives that multiplication — you have to change what a checkout is.

And the growth curve is the actual story. 12x in four months, driven by agents that merge autonomously. As the post puts it: "the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase." If your organization is at 50 merges a day today and agents take you to 500, you will feel the same walls — at one tenth the scale — because git's costs are superlinear in repo history, and agent fleets multiply checkout counts in a way human workflows never did.

Why Git Breaks Here — Structurally, Not Accidentally

The important claim in Anthropic's post is that git's design properties — the ones that made it win — are the ones failing:

• Git is decentralized; agent clients are always online. Every clone carries complete history and can answer every question offline. That's the right design for humans on airplanes. But Anthropic's clients are agents and CI jobs that are online by definition — paying full-repo data locality for clients that never need it. "The properties that make git excellent for distributed, offline work were actively undermining our ability to scale."
• History-dependent queries scan history. Blame, path-filtered log, pickaxe search — the operations that answer "who changed this line" — get slower as history grows, no matter how good your packfiles are. We reproduced this ourselves below: at just 50,000 commits, path-filtered log already costs ~4 seconds.
• Refs are global state. Every branch and tag is a pointer every server must agree on. At Anthropic's scale, ref movement becomes a distributed-consensus tax on every operation. Scion discourages refs almost entirely — a branch tip is a compare-and-swap on a single Spanner row, done separately from commit creation.
• Packfiles are per-server materialized state. Git servers compress objects into packs; that means server-side maintenance, lock contention, and cache invalidation. Scion has no packfile equivalent — everything is content-addressed and immutable, so any cache can serve any object without coordination.
• The merge queue is a global lock. Anthropic states plainly they could not replicate "the industry standard of a global repository lock on the merge queue." At 30,000 merges/day with hundreds of changes landing while tests run, the industry's pre-merge gating model stops being a queue and becomes a parking lot. Their answer: post-merge and pre-deploy automated testing, accepting that concurrent changes can conflict — because "Claude can typically fix these conflicts faster than humans can even identify them."

That last bullet is the one to sit with. It's not a git limitation — it's a redefinition of CI itself, and it's the part most transferable to teams that will never touch Scion.

What Scion Actually Is (Architecture in One Pass)

Scion's design, as published:

• The changeset, not the commit. The unit of work is a changeset — a write-ahead-log entry storing the files changed relative to its first parent, plus content-addressed pointers to compressed file contents in blob storage. Created server-side, available everywhere instantly, no locks, no cross-server coordination.
• Client-server asymmetry. The server answers history questions, creates commits, performs merges and rebases. The client keeps a bounded object cache, lays out the working copy, watches the filesystem — and computes almost nothing locally.
• Derived data. Changesets alone can't answer blame or path history. Scion builds derived data structures (file blame, path history, skip lists for the commit graph) recursively — each changeset's value computed from its parents' values — with per-type eager/deferred computation. New index types get added without touching clients.
• Tiered content-addressed caches. The checkout path is a three-tier cache hierarchy with >99% hit rates at every tier.

flowchart TD
    A["scn client<br>(agent / CI job / engineer)"] -->|"socket RPC, asks only for<br>trees + blobs it wants"| B["scion-daemon<br>(per-node object store,<br>periodic snapshot seed)"]
    B -->|"miss: recursive tree/blob request,<br>resumable, no packfile"| C["scion-cache<br>(regional, streams objects<br>from memory, disk format)"]
    C -->|"miss: authoritative read"| D["scion-server<br>(compute derived data,<br>write back to storage)"]
    D --> E["Spanner<br>(changesets, refs as CAS)"]
    D --> F["Cloud storage<br>(content-addressed file blobs)"]
    style A fill:#1e293b,stroke:#475569,color:#e2e8f0
    style B fill:#1e293b,stroke:#475569,color:#e2e8f0
    style C fill:#1e293b,stroke:#475569,color:#e2e8f0
    style D fill:#1e293b,stroke:#475569,color:#e2e8f0
    style E fill:#0f172a,stroke:#475569,color:#e2e8f0
    style F fill:#0f172a,stroke:#475569,color:#e2e8f0

Three details platform engineers should steal regardless of scale:

1. Negotiation by "what I want," not "what I have." Git's fetch protocol makes the server compute what the client lacks (hence delta compression, packfile assembly, CPU per request). Scion's client recursively requests specific missing trees and blobs — every request is for an immutable, content-addressed object, so any cache tier can answer it with zero coordination. The result is a cache hierarchy that scales like a CDN, not like a database.

2. Sparse is the default, virtualization is the escape hatch. CI jobs that only need a diff ask the server; jobs that need files on disk get sparse checkouts containing only requested directories, or virtualized checkouts that materialize files on demand. Anthropic checks out code "tens of millions of times a day" precisely because a checkout became a cache-miss pattern instead of a data transfer.

3. Source control as a queryable service. Every query the client uses is exposed via API — so Anthropic's automated bisect and revert pipelines don't maintain local repos at all. This is the single most adoptable idea in the piece, and GitHub/GitLab can implement it without breaking git: server-side RPC for blame, ancestry, and diff, so tooling stops cloning to ask questions.

We Ran the Numbers Ourselves: Git's Cost Curve

Anthropic's post is honest but it's still a vendor of its own narrative. So we reproduced the underlying behavior on synthetic repos on this host (Ubuntu 24.04 VM, cloud virtual disk, git 2.43.0):

First, the baseline — this site's own repo:

$ git rev-list --count HEAD
330
$ git count-objects -vH | grep size-pack
size-pack: 1.31 MiB
$ git clone (local, hot cache)   0.06 s
$ git status / log / diff        0.00 s each

Git at ordinary scale is effectively free. Keep that in mind as the denominator.

Then we generated a 50,000-commit monorepo — 2,000 files, each commit touching 8 files, i.e. the shape of a small agent PR — via git fast-import, ran git gc, and timed the history-dependent operations that Scion's derived data exist to accelerate:

operation                                   time
─────────────────────────────────────────────────
clone (local, hot cache)                    0.07 s
git blame src/f1.txt (one file, 50k hist.)  0.83 s
git log --oneline -- src/ (path-filtered)   3.93 s
git log -S 'rev 400' (pickaxe, full hist.)  7.89 s
git merge-base HEAD~20000 HEAD~10000        0.02 s

Read the last three lines against Anthropic's scale. Their main-branch history is ~100 GB — roughly three orders of magnitude beyond this synthetic repo — and they execute these query classes ~25 million times a day from CI alone. Path-filtered log at 4 seconds per invocation at one-thousandth of their history, multiplied by their query volume, is not a tuning problem. It is an architecture problem, which is why derived-data indices (server-side, shared, incrementally maintained) are the load-bearing idea — the same one Google's Piper and Meta's Sapling converged on years ago. Google's single-repository paper and Meta's Sapling post are the primary sources; Scion is the third entry in a genre, not an anomaly.

One measurement cuts the other way and deserves the honesty: merge-base at 20k-deep ancestry was 0.02 seconds. Git's commit-graph machinery is genuinely good at the graph-walk subset of the problem. The wall is specifically the content-scanning queries — blame, path history, pickaxe — and the wire economics of 25M checkouts/day. Your repo's graph walks are fine; your history scans and your fetch bill are what age badly.

The Merge-Queue Wall — With the Math

The first wall most agent-heavy teams hit isn't blame — it's the merge queue. The standard model (GitHub's merge queue batches PRs, runs CI on the batch, lands it only if all checks pass) is a serialization point. Its throughput ceiling is arithmetic:

CI time   batch size   max merges/day (single lane)
────────────────────────────────────────────────────
 5 min        1                  288
 5 min        5                1,440
10 min        1                  144
10 min        5                  720
20 min        1                   72
20 min        5                  360

At Anthropic's September rate — 30,000 merges/day — a 10-minute-CI queue would need roughly 208 parallel landing lanes to keep up, and every one of those lanes still contends for the same ref tips. This is why the post's most radical statement is operational, not architectural: they abandoned the global-lock merge-queue model entirely for post-merge, pre-deploy testing, and accept concurrent-landing conflicts because agents resolve them faster than humans notice them. If your agents are merging hundreds of times a day and your queue is your bottleneck, that trade — weaker pre-merge gating, stronger post-merge detection and revert automation — is available to you without touching git at all. GitHub's merge-queue configuration docs are the batch-size knobs; the post-merge strategy is yours to build.

The Mirror-Fleet Pattern — and What It Costs Before It Fails

Anthropic ran "several hundred internal git mirrors" before Scion. That's the standard industry ladder rung, so price it. A read-only git mirror serving clone traffic wants memory for page cache; a reasonable shape is r6i.2xlarge (8 vCPU / 64 GiB). Illustrative sizing at AWS us-east-1 on-demand rates (r6i.2xlarge $0.504/hr, Vantage EC2 dataset checked 2026-10-13):

Label this what it is: an illustrative shape, not Anthropic's bill — they don't publish instance counts or cloud. But the direction matters. The mirror fleet is the pattern that fails second — Anthropic's mirrors "no longer scaled once the repo outgrew the mirrors' disks or memory limits," and every mirror must be kept convergent on a repo whose tip moves every ~3 seconds. Scion's 200x footprint reduction claim is CPU/memory, not dollars — but at 300 mirrors you are paying six figures a month for a workaround whose failure mode is a race between repo growth and disk size.

The Ladder: What You Should Actually Do

Anthropic says it plainly: "Scion is by no means a suitable replacement for git for general use," and they are not open-sourcing it. So here is the actionable ladder by merge volume — every rung verified against current tooling:

Two footnotes to the ladder. First, jj (32,019 stars, Git-compatible, pre-1.0) is the most credible client-side modernization — conflict-first data model, no working-copy mutation — but it solves the human ergonomics layer, not the server throughput wall; don't confuse the two. Second, Graphite's stack tooling and its peers solve the review-latency rung (2,000/day zone) — fast for humans, orthogonal to the agent-merge flood.

When NOT to Chase Any of This

• If your merge rate is human-shaped, this is a solution to a problem you do not have. The entire Scion story is contingent on agent-authored change volume. A 50-developer org with 20 merges a day that re-platforms source control is doing resume-driven infrastructure.
• The migration cost is the whole SDLC, not the VCS. Anthropic had to rebuild code review (Antique), code search, source-control IAM, and its CI gating model in the same five months. They could because a 7-person team had agents writing most of the code — the post credits Claude with a 20x memory / 4x speed rewrite of the ingestion pipeline on first ask. Your org's 5-month budget buys you a partial clone config file and, if you're lucky, a Scalar rollout.
• Don't fork git into a "Scion-lite." Anthropic's own closing point: a git server doesn't have to work like a git client. The durable industry outcome they're betting on is server-side RPCs and smarter negotiation inside git platforms — a path that requires partnering with the forges, not around them.
• Skip the hype about "post-git." Nothing here is transferable pressure on git's dominance. The HN thread's most useful signal is who showed up: a tiny startup validating the server-first thesis, Pijul partisans relitigating patch theory, and working engineers doing back-of-napkin sanity checks on the 600 PB figure (it holds — 25M × 25 GB = 625 PB/day).

The Bottom Line

Scion is the third company (after Google's Piper and Meta's Sapling) to prove the same thesis: past a certain change volume, source control wants to be a server-authoritative service with derived indices, and git's decentralization becomes a cost you pay for capability nobody uses. What changed in 2026 is the client — agents took Anthropic past the threshold in four months instead of a decade. Your move, in order: instrument merge rate (trend, not level), exhaust git's own scaling features plus queue batching, move queries server-side, and only then think about the architecture. And if you ever get to the last rung — congratulate yourself, because you'll have an AI fleet problem most platform teams would kill for. We cover that fleet side in our AI fleet architecture guide; for the control-plane scaling cousins of the same disease, see where GitOps hubs actually break, and for the review layer that has to absorb 12x merge growth, our AI code-review agent analysis and the AGENTS.md adoption story are the adjacent reads.

References & Further Reading

• Anthropic Engineering — Redesigning source control at Anthropic (Oct 13, 2026) — the primary source for every Scion figure in this piece.
• Hacker News discussion of the Anthropic post — industry reaction, including East River Source Control and Pijul threads.
• Meta Engineering — Sapling: source control that's user-friendly and scalable — the prior art Anthropic names.
• Google — Why Google Stores Billions of Lines of Code in a Single Repository (CACM) — the Piper paper.
• Git docs — partial clone and sparse checkout — the rung-2 features.
• Microsoft Scalar — large-monorepo git tooling, now maintained in the microsoft/git fork.
• GitHub Docs — Managing a merge queue — the batch model and its knobs.
• Sapling, jj, Gerrit, Pijul, East River Source Control — the ecosystem's non-git and git-adjacent options, all verified live October 2026.
• Pricing sources: Vantage EC2 dataset (instances.vantage.sh) mirroring AWS us-east-1 on-demand rates, checked 2026-10-13 — r6i.2xlarge $0.504/hr. Synthetic git measurements: this article's test rig (git 2.43, local NVMe), repos generated with git fast-import; scripts described in the text.