Anthropic Scion vs Git: Why It Is Actually About Scale

What Anthropic's Post Says

Everything in this section comes from Redesigning source control at Anthropic, published 13 October 2026 and updated 15 October. I read it on 2026-10-19. I did not run any of it, and Scion is not public.

• Volume. "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day."
• Size. "The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB."
• What got hard. It "took more and more care to keep operations that depend on history, like diff and blame, working on partial clones." Mirrors "became harder to operate as our merge rate increased."
• The big number. "Fetched naively, that would be over 600 PB of git traffic per day." Note the word naively. It is a what-if, not a measured bill.
• The caveat. "Scion is by no means a suitable replacement for git for general use."

Read together, the post describes a company with an unusual workload: thousands of agents merging code into one repository. Its fix is a server that answers history and blame questions itself, with tiered caches and sparse or virtual checkouts. That is a design for that workload.

What the Post Does Not Show

Four performance claims appear in the post. Here are the exact sentences and what I could find about how they were measured:

• "CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes)." No baseline or workload stated.
• "Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure." It says this is in CPU and memory, with no workload or period.
• "CI alone realized a 25% CPU capacity win." No baseline stated.
• A rewrite of the ingestion pipeline "consumed 20x less memory and was 4x faster", compared with the team's own earlier prototype.

These may all be true. They are Anthropic's measurements on Anthropic's systems, and nobody outside can repeat them. I am treating them as claims, not facts.

What I Measured With Stock Git

I built a synthetic bare repository with git fast-import: 102,006 files in 300 folders across 20 modules, 5,000 commits, and six random 8 MB blobs. It is about 111 MiB on the server side. Then I cloned it four ways, three times each, on Windows 11 with Git 2.52.0 and timed the commands from Node. Every number is a median of three runs on a local disk through file://, so there is no network in it.

clone type                        median    .git size   files on disk
git clone (full)                  26.6 s    123.4 MB    102,006
--filter=blob:none                42.0 s    87.7 MB     102,006
--filter=blob:none --sparse
  + sparse-checkout set --cone    2.8 s     15.5 MB     5,100
scalar clone, then --cone         3.1 s     13.8 MB     5,100

Two things stand out. The sparse partial clone was about 10 times faster and 8 times smaller than the full clone. And partial clone on its own was slower than a full clone, 42.0 against 26.6 seconds, because the checkout then had to fetch the contents of about 102,000 files on demand. The slice tools only pay off together.

Where Git Was Not Slow

operation (median, ms)        full clone   sparse clone
git status, warm              45           36
git log -- path               33           31
  with a commit-graph         15           15
git add, one file             50           51

At this size git was fast everywhere. Each figure includes about 25 to 30 ms of process start-up, so differences under 20 ms are noise. Turning on core.fsmonitor and the untracked cache gave no warm win and added about 150 ms to the first status. My guess is that Git for Windows already caches file-system data by default, but I did not test that guess properly.

Want more like this?

New posts in your inbox, a few a month.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.

Where the Slice Tools Cost Something

Partial clones fetch file contents on demand. git checkout -b x origin/topic, a branch that changed four files, took about 420 ms in the partial clones and 70 ms in the full one, because four blobs had to be fetched. On a local disk that is cheap. Over a network it is a round trip.

I did not measure blame or old-commit diffs on partial clones. Those are the operations the post says took "more and more care", so this is the gap in my test that matters most.

What I Would Do With a Big Repo

1. Run git clone --filter=blob:none --sparse <url>, then git sparse-checkout set --cone <folder>. Or try scalar clone, which did the same job here.
2. Time status, checkout and log -- path on your real repo before and after.
3. If history operations such as blame hurt on partial clones, that is the signal you are near the problem Anthropic describes. Not before.

The point is cheap: you can try the stock tools in an afternoon. Building a server-side version control system is a different project.

What the Hacker News Thread Argued

I read the top-level comments on the Hacker News thread (about 894 points when I looked). Most arguments were about design and history: that this looks like SVN or Perforce, whether an existing system could have been licensed, and whether Google's Piper tells us anything. One commenter from a source-control vendor said teams will hit git's limits with agents; they said so themselves, and they sell a product. Almost nobody cited git features, and nobody I read measured anything.

What I Did Not Test

• Scion, or any of its numbers. It is not public.
• A repository near 100 GB, or a network. My repo is about 111 MiB and my clones read from a local disk.
• Concurrent pushes, which one commenter said hurt git. My test had one user.
• blame and old-commit diffs on partial clones.
• Defender and antivirus effects. I did not control for them.
• The git config entries for core.fsmonitor and core.untrackedCache in the docs. I ran them but did not read those entries.

FAQ

What is Anthropic Scion?

Scion is the source control system Anthropic describes in its 13 October 2026 engineering post. It is server-centric, with tiered caches and sparse or virtual checkouts. The post says it is not a suitable replacement for git for general use, and it is not public.

Is git too slow for AI agents?

Not at ordinary large sizes, in my test. On a 102,006-file repository with 5,000 commits, a warm git status took about 45 ms. Anthropic describes almost 100 GB of history and over 30,000 merges a day, which is a different scale.

How do I speed up cloning a large git repository?

Use a partial clone together with sparse checkout. In my test, git clone with the blob:none filter and the sparse option, followed by a cone checkout of one module, took 2.8 seconds against 26.6 for a full clone. The partial clone alone was slower, at 42.0 seconds.

What is scalar in git?

Scalar is a repository management tool that ships with Git and applies settings for large repositories. In my test, scalar clone took about 0.9 seconds, and about 3.1 seconds in total with a cone checkout of one module.

Can I reproduce Anthropic's Scion numbers?

No. Scion is not public, and the post states no baseline or workload for its speedups. The only fair baseline I could test was stock git with partial clone and sparse checkout.

Related Articles

• One sentence, 198 pages: AI agents rewrote their reports
• Running Claude Code as an always-on agent on Windows
• XNDR work: projects built with AI agents.
• XNDR services: AI agents and automation.

Liked this one? Get the next in your inbox.

New posts and the odd product note, a few emails a month. Easy to leave.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.