Anthropic outgrew git because its main users are agents. Here's the part that applies to your repo

Anthropic says the number of changes merged into its monorepo went from about 2,500 a day in May 2026 to over 30,000 a day by September, and that git stopped being a good fit along the way. In an engineering post , the company describes replacing git for that repo with an in-house system called Scion in five months, plus a new code review tool called Antique.

Nobody reading this can use Scion, and Anthropic says as much: it isn’t a general git replacement and only makes sense for very large monorepos. The reasoning is another matter. Git assumes people who work offline and want a full copy of everything. Anthropic’s clients are mostly agents and CI jobs, which are always online and each want a small slice. That mismatch shows up at much smaller sizes than 100 GB.

What Anthropic reports

The numbers in the post set the scale. Main-branch history is nearly 100 GB, a compressed working copy is over 25 GB, and CI does about 25 million checkouts a day. Scion’s design follows from those: clients are always online, the server handles history, blame and merges, and working copies are optional and sparse.

Anthropic reports about 200 times less CPU and memory than the previous setup of git mirrors, cache hit rates above 99% in every tier, and CI checkouts dropping from minutes to seconds. The post’s framing of the cause is that Claude’s coding speed moved the bottleneck to human-scale infrastructure: source control, builds and CI.

Two admissions are worth reading closely. Anthropic couldn’t replicate a global merge-queue lock, so it relies on post-merge and pre-deploy testing, which lets concurrent conflicts through. Claude typically fixes those quickly, the post says. And engineers still had to reject some agent-proposed designs, such as brute-force scans of the commit log.

Shrink the checkout to the task

The cheapest idea to borrow is “working copies are optional and sparse”. If an agent is fixing a bug in one service, it doesn’t need the other 39 on disk, and with parallel agents you pay for every extra copy.

Here’s the effect with plain git, on a synthetic repo of 40 service directories with 60 files each. The origin is a local bare repo with uploadpack.allowFilter enabled, and one clone is a normal clone while the other is a partial, sparse one:

git clone file:///tmp/demo/origin.git full
git clone --filter=blob:none --sparse file:///tmp/demo/origin.git slim
git -C slim sparse-checkout set services/svc03
git -C full worktree add ../wt-full -b a
git -C slim worktree add ../wt-slim -b a

Measured with du -sk (excluding .git) and a file count, run it and it prints:

full      48328 KB  2400 files
slim       1216 KB    60 files
wt-full   48328 KB  2400 files
wt-slim    1216 KB    60 files
full      24432 KB (.git)
slim       1364 KB (.git)

Every extra full worktree costs another full working tree. The sparse worktree inherits the sparse patterns of the clone it was added from and stays at 60 files. The .git directory shrinks too, because the partial clone never downloaded the blobs outside the slice. The sizes are for a synthetic repo of random text, so read them as a ratio, not a forecast for your codebase.

Per the git docs, sparsity is tracked per worktree, so changing it in one worktree leaves the others alone. For the partial clone half, missing blobs are fetched on demand from the remote. A checkout fetches what it needs in one batch, but one-at-a-time fetches are slow, and anything that touches file contents (blame, log -p, a diff against an old commit) needs the remote reachable. That’s the same bargain Anthropic made when it dropped offline support, and it’s a fine one for an agent running in CI. It’s a worse one on a train.

Let Claude Code do it for you

If your sessions start in worktrees, Claude Code has a setting for the sparse half. worktree.sparsePaths takes directory paths relative to the repo root, and each worktree Claude Code creates checks out only those plus root-level files:

{
  "worktree": {
    "sparsePaths": [".claude", "packages/api", "packages/shared"],
    "symlinkDirectories": ["node_modules"]
  }
}

A few details from the docs matter. Root-level files such as package.json and lockfiles always come along, but root-level directories don’t, which is why .claude is in that list: without it the worktree has no project settings or rules. All worktrees in a session share the same list, so if one subagent needs packages/web, add it. The setting is read from the directory you launched in, before the worktree exists. Git also turns on extensions.worktreeConfig in the shared .git/config while a sparse worktree exists.

symlinkDirectories handles the other big cost, dependencies, by linking node_modules back to the main checkout instead of duplicating it. The docs cover both settings on the large codebases page . This section is documented behaviour; it wasn’t run against a live session.

The honest limit: a sparse checkout is a bet that the task stays inside the slice. An agent that needs a type from a package you didn’t list hits a missing directory and either stops or goes hunting. Start with the one or two packages that agents touch most, and widen the list when you see that failure, not before.

Where the bottleneck went

Anthropic’s most useful claim is that agents moved the limit off the model and onto the plumbing around it. On a modest repo with one or two agents that plumbing is fine. As agent count grows, the symptoms turn up in places that don’t look like git problems: slow session startup, CI queues full of near-identical checkouts, merge queues that serialise every change.

One practical read of Anthropic’s no-global-lock decision (opinion, not Anthropic’s advice): decide deliberately which branch needs strict serial validation and which can tolerate fix-forward. A repo with a fast test suite and a good rollback path can accept occasional post-merge breakage that an agent repairs, as Anthropic does. A repo that ships to customers on every merge probably can’t.

A review prompt that doesn’t over-engineer

The post says adversarial review, where a model hunts for flaws in a change, is effective but can be myopic, and engineers sometimes had to steer Claude away from over-engineering against hypothetical concerns. Anyone running a reviewer subagent has seen that: a small diff comes back with a pile of findings, most of them about inputs no caller can produce.

A reviewer prompt that cuts that down asks for evidence instead of coverage:

Review this diff for defects. Report a finding only if you can name a
real caller or input that reaches it and say what goes wrong. Do not
report hypothetical concerns, style, or missing abstractions. If you
find nothing that meets that bar, say "no findings" and stop.
Order findings by how likely the triggering input is.

It won’t make the model right, but it makes wrong findings easier to spot, because each one has a path you can check in a minute.

The same instinct applies to design. Anthropic’s engineers rejected brute-force commit-log scans from an agent. If a proposed change adds a mechanism that scales with history or with repo size, ask for the cheaper alternative before approving it.

Try it this week

Pick the package your agents change most, add it and .claude to worktree.sparsePaths in .claude/settings.json, start claude --worktree try-sparse, and compare du -sk against a worktree from before the change.