Anthropic Replaced Git With Scion: What Agent-Scale Source Control Changes

On 13 October 2026 Anthropic's engineering blog published Redesigning source control at Anthropic, and within a day one number was everywhere: 30,000 merges a day. The post on X that travelled furthest put it in one line, “anthropic getting bottlenecked by git so they wrote their change-list based version control system called scion”. The number that stopped me sat two paragraphs further down: about 25 million CI checkouts a day, before a single developer environment, agent sandbox or research job touched the repository.

This post reads the primary source closely, using Anthropic's own six figures, and cross-checks it against five pieces of coverage, git's protocol documentation and the Hacker News thread of more than 600 comments. I run Claude Code agents headless against my own repositories, so I read it for what changes for teams that will never merge 30,000 changes a day. Every Scion number below is company-reported, and none has been independently verified.

The numbers that broke git: merges are writes, checkouts are reads

Anthropic's first figure tells most of the story. The monorepo merged roughly 1,000 changes a day in January, about 2,500 in May, and peaked at 30,401 on 9 September. The colour change matters as much as the height: blue pull requests give way to orange change requests in Antique, the code review tool Anthropic built alongside Scion, through June and July. By August almost every merged change went through the new system.

The headline is the merge rate, but the cost driver is the read side. Main-branch history is almost 100 GB and a compressed working copy is over 25 GB. Anthropic counts about 25 million CI checkouts a day and writes that “fetched naively, that would be over 600 PB of git traffic per day.” That figure is not hyperbole. 600 PB divided by 25 million is 24 GB, almost exactly one compressed working copy per checkout.

Writes and reads also compound. At 30,000 merges a day, main moves about every three seconds, so any cached copy of the repository is stale almost as soon as it is refreshed, and every job that needs main's tip has to fetch the difference. Anthropic's opening line is the thesis of the whole post: “At Anthropic, coding is no longer the bottleneck to building systems or doing research.” The infrastructure that moves code around became the bottleneck instead.

What Anthropic tried first: the standard git scaling playbook

Before building anything, Anthropic ran the playbook any large git shop would recognise: shallow clones, sparse checkouts, promisor remotes for partial clone, internal git mirrors, and seed snapshots kept in blob storage so a new node starts warm. At its peak it ran several hundred mirrors. Here is that playbook as commands, the same ones I would reach for on a large repository today.

# The standard git scaling playbook. Every line still assumes the client
# is a full git peer that merely holds less of the repository.

# Shallow: truncate history. Cheap to clone, but blame and log stop early.
git clone --depth=1 https://git.example.com/monorepo.git

# Partial (blobless): fetch commits and trees, defer file contents.
# The server becomes a "promisor remote" that sends missing blobs on demand,
# and git fetches them one object at a time when a command trips over one.
git clone --filter=blob:none --sparse --no-checkout \
  https://git.example.com/monorepo.git
git -C monorepo sparse-checkout set services/billing libs/shared
git -C monorepo checkout main

# Seeds: start new nodes from a bundle in blob storage, then fetch the delta.
# The delta grows with every merge since the bundle was cut.
git clone --bundle-uri=https://blobs.example.com/seeds/monorepo.bundle \
  https://git.example.com/monorepo.git

# Mirrors: replicate the whole repository closer to the jobs reading it.
git clone --mirror https://git.example.com/monorepo.git /srv/mirror.git
git -C /srv/mirror.git remote update --prune

Each technique works, and each keeps the same assumption: the client is still a full git peer that happens to hold less. Anthropic names the two places that assumption failed. Seeds drifted further from main between refreshes as the merge rate rose, and diff and blame on partial clones became harder to keep working. Git's own partial-clone documentation explains the second one. Dynamic fetching invokes fetch-pack once for each missing item and tends to be slow because objects arrive one at a time. Blame walks history and needs old versions of a file, which on a blobless clone are exactly the objects that are missing.

The diagnosis: git is decentralised, and Anthropic's clients never were

The sentence the whole design follows from is in the growth section of the post: Anthropic was “using git as a centralized system with one authoritative copy”, while almost every client was an always-online agent or job. Git's offline-first model, where every clone is a full peer, is a feature for a maintainer working on a train. For an agent in a sandbox that exists for twenty minutes, it is a cost paid on every start. Anthropic credits Google's Piper and Meta's Sapling as prior art, and the change-list description on X points at the same lineage: units of change kept on a central server rather than snapshots copied to every client.

Read down the right-hand column and one rule falls out, which Developers Digest put better than anyone: assume the client is online and ask the server. Every row moves work and state from many clients to one service. That is the trade git was designed to avoid in 2005, and it only pays off when the clients are machines that never go offline.

Inside Scion: changesets in a log, trees derived on demand

Scion's unit of work is a changeset, an entry in a write-ahead log. A git commit points to a tree, a full snapshot of the repository at that moment. A Scion changeset instead lists the files that changed relative to its first parent, each with a content-addressed pointer to a compressed blob. Anthropic's figure shows the split: metadata in Spanner, file contents in Cloud Storage, immutable and deduplicated by hash.

That is an inversion worth noticing. Git stores snapshots and computes diffs; Scion stores diffs and computes snapshots, deriving root and directory trees on the server when someone asks. Recording changes against the first parent only is, in Anthropic's own words, a stylistic choice: in trunk-based development people mostly care about history along the trunk. The difference is easiest to see side by side.

# git: a commit names a complete tree. The diff is computed when asked.
$ git cat-file -p HEAD
tree e3a1c07f...            # a snapshot of the entire repository
parent 9a1f03b2...
author Jane Dev <jane@example.com> 1757899509 +0000
committer Jane Dev <jane@example.com> 1757899509 +0000

fix: retry blob fetch on timeout

# Scion: a changeset names only what changed against its first parent.
# Fields as drawn in Anthropic's "Shape of a Scion changeset" figure.
changeset      9f2c...7ab0
parents        d41c...88e2
author         Claude <noreply@anthropic.com>
committer      Scion <noreply+scion@anthropic.com>     # optional
message        scion-cache: serve blobs from the memory tier
file_changes
  docs/guide.md    3e1f...a2c4    regular file
  src/legacy.rs    deleted
  tools/build.sh   9b07...5d18    executable

# No tree field. The root tree (5c0e...d1a9) is derived by the server
# when a client asks for it, and file contents live in Cloud Storage,
# immutable and deduplicated by hash.

Everything else, including blame, path history and commit-graph skip lists, is derived data built by one generic mechanism. Each value is defined recursively from its parents' values and can be computed eagerly or deferred. Anthropic has since added copy-detection indices and path-based file search the same way, without clients noticing. Refs sit outside the hot path entirely: creating and fetching commits never touches them, and the post's reason is blunt, “global state that every server has to agree on is a looming scaling problem.”

The checkout path: three tiers that answer the same RPCs

In git's fetch negotiation, as the protocol v2 documentation describes it, the client sends have lines for objects it already holds and want lines for what it needs, and the server answers with a packfile built for that conversation. Scion turns the conversation around. The client does not describe what it has. It names the trees and blobs it wants, starting from a root tree, and requests missing objects recursively. There is no multi-gigabyte packfile, so transfers are resumable, and sparse or virtual checkouts need no special support: the client simply never asks for trees it does not want.

The figure separates a control plane from an object plane. Branches, history and diffs go straight to scion-server for every client. Trees and file contents flow through caches: a scion-daemon on each node, shared by every job on that node and seeded from a periodic snapshot, then a regional scion-cache that streams objects from memory in the daemon's on-disk format, then scion-server reading from Spanner or Cloud Storage. All three tiers answer the same RPCs, so a client cannot tell which one it is talking to.

Two properties make this cheap to run. Content-addressed objects never change, so any tier can cache them without coordination and there is nothing to invalidate. And the tiering is strictly enforced, so a failed regional cache cannot stampede the servers above it. Anthropic reports a hit rate above 99% on every tier, with no long-lived state in any of them.

The results, command by command

Anthropic's headline results are a CPU and memory footprint about 200x smaller than the git mirror fleet, CI and research checkouts two orders of magnitude faster, and a 25% CPU capacity win for CI alone. The more useful evidence is the chart of median times per command. The agent and CI half is reproduced below, and the table lists every row of the original.

The pattern in the table is the design principle showing through. The biggest wins are on operations whose cost in git grows with the size of the repository: status on a developer machine (×207), where git checks the whole working tree while Scion's client watches the filesystem, and a fresh agent worktree (×84). The smallest is a developer commit (×1.3), which in git was already proportional to the change. Scion did not make everything fast. It made every operation cost what the change costs.

The annotations also reconcile with the rest of the post, which is a good sign. Saving 27.5 seconds on each of 25 million CI checkouts a day comes to about 191,000 hours, close to the chart's ≈195,000 machine hours a day. Saving 30 minutes per change request against ≈11,000 agent hours a day implies roughly 22,000 change requests a day, the same order as the merge chart. These are still Anthropic's own medians. Both explainx and Developers Digest point out that none of them has been independently audited, and the 200x is measured against a mirror fleet most teams never built.

No global merge lock, intent review, and Claude on the team

The most contested decision is not inside Scion at all. Anthropic writes that a proper merge queue “doesn't make much sense at agent scale”. Hundreds or thousands of changes can land while one test run executes, and the team could not replicate the industry standard of a global repository lock. It invested in post-merge and pre-deploy testing instead, and accepts that concurrent changes will sometimes conflict, because “Claude can typically fix these conflicts faster than humans can even identify them.”

Review changed shape to match. Engineers still review every change request, but for its intent rather than every line, and semantic approval rules can separate a comment-only change from one that touches sensitive logic. Claudes that each focus on one component, which the team calls superfans, watch telemetry and logs for the scion-daemon, the scion-cache and the Antique merge queue, alongside ordinary alerts. The engineers' most frequent job, in their words, was to tell Claude “no”: when it read the commit log to find out whether a change had merged instead of asking the review tool, or when adversarial review pushed defensive validation against an internal service that was already trusted.

The thread is worth reading for the counter-case. One commenter estimated around ten pull requests per engineer per day and said Anthropic had “crossed the rubicon of not gating PRs on tests”. Another argued that Perforce-era companies served tens of thousands of engineers and that “30k CLs per day isn't much.” Both points are fair, and neither touches the narrower claim: at this rate, any design that serialises merges behind a full test run falls behind. AI Weekly's round-up notes that The Register framed the engineers as gatekeepers rather than code authors, which is close to how the post describes the job itself.

Claude also built much of the system it was outgrowing. The scm and antique directories received 12,257 changes between January and September, for a team of seven. When an early internal snapshot of Claude Mythos Preview was asked to rewrite the hand-written git-to-Scion ingestion pipeline with no further instructions, it produced a version that used 20x less memory, ran 4x faster and kept the implicit ordering invariants. The engineers say they would now rate Claude as better at writing code than themselves, and call Scion one of the best-tested codebases they have worked on, thanks to hermetic simulations, fuzzing and rate limiting.

What to copy if you will never merge 30,000 changes a day

Anthropic is explicit that “Scion is by no means a suitable replacement for git for general use.” It only makes sense for very large monorepos with tens of thousands of engineers or large agent swarms, the company's internal token spend is not one most businesses would choose, and adopting it would mean migrating code review, search and CI along with it. There is no release to download, whatever some headlines implied. AI TLDR's summary names the right audience, platform and developer-infrastructure engineers, who can borrow server-side commits and on-demand fetching without the code. Most of the ideas work on plain git today.

1. Measure before you change anything. Time a fresh agent worktree, a status and a pull on your largest repository. Developers Digest's test is the right one: if agent checkouts already take seconds, Scion's problem is not yours yet.
2. Give each agent a blobless, sparse clone and its own worktree, using the commands in the playbook above, so it pays for the directories it touches rather than for the whole history.
3. Answer repository questions on the server. A job that only needs a diff, a merge base or a file at a commit can ask your forge's API instead of cloning, which is the cheap version of Scion's service principle.
4. Keep refs few. Short-lived branches per agent are fine, but git's partial-clone documentation lists a large ref count as a source of significant overhead on every connection, and an agent fleet multiplies refs quickly.
5. Move human review up a level before the volume forces you to. Decide which paths need line-by-line review and which can be approved on intent plus green tests, and write the rule down where both people and agents read it.

# 1. Measure what an agent pays for source control before it writes a line.
#    If all three finish in seconds, Scion's problem is not yours yet.
time git worktree add ../agent-1 -b agent/1 origin/main
time git -C ../agent-1 status
time git -C ../agent-1 pull --rebase origin main

# 2. Ask the server instead of cloning. A job that only needs to know what
#    changed can read it from the forge's API with no local repository:
#    GitHub's "compare two commits" endpoint takes BASE...HEAD.
gh api repos/acme/monorepo/compare/main...agent/1 \
  --jq '.files[] | [.status, .filename] | @tsv'

# 3. Keep refs few. Every fetch has to reckon with them; count before
#    an agent fleet multiplies them.
git ls-remote --heads origin | wc -l

Two caveats before you take any of this to a planning meeting. As explainx points out, the post describes a success and says almost nothing about failed approaches or migration incidents, so treat five months as the version that worked. And the things Anthropic asks of the git community are the likely route by which any of this reaches the rest of us: comprehensive server-side RPCs that forges could standardise, a new negotiation protocol, and sparse and shallow features that compose well. That path runs through GitHub, GitLab and git itself, not through Scion.

The lasting lesson of Scion is not that git failed. It is that git's defining assumption, a client that is a full and independent peer, stopped matching who the clients were. When most readers of a repository are always-online agents, the cheapest design keeps state on the server, names content by hash so every cache can serve it, and makes each operation cost what the change costs. Measure what your agents pay for source control before you plan around anyone else's numbers.