Git vs Scion: Why Anthropic Moved Off Git, and Whether You Should Care

"Anthropic replaced git."

That headline went around earlier this month, and it is easy to read it the wrong way. It sounds like a new tool is coming for the one every developer touches daily.

It isn't. The engineering post behind the headline is much more careful than some of the headlines about it.

Anthropic built Scion for one unusual workload, and it says plainly that Scion is not meant for everyone.

Still, the post is worth your time. The reasons git strained, and the tricks Scion uses to get around that, say a lot about where source control is heading when AI agents write a large share of the code.

So here is the plain version: what happened, how Scion differs from git, what is solid and what needs a pinch of salt, and which git features get you part of the way there.

What actually happened

On October 13, 2026, Anthropic published an engineering post called "Redesigning source control at Anthropic."

The short story: in May 2026 the company merged around 2,500 code changes a day into its monorepo. By September it was merging more than 30,000 a day.

Anthropic says source control became its biggest development bottleneck. So a team of seven built Scion, an in-house version control system, and moved the whole monorepo off git in five months.

The same team also built a code review tool called Antique, plus code search and an access-control system, in that same window.

The repo itself was enormous too:

⚠️ Name clash alert There is another project called Scion, from Google. It is an experimental testbed for running many AI agents in containers, and it actually uses git (each agent gets its own git worktree). It is not a git competitor, and it has nothing to do with the system in this post. If you searched "git vs scion" and landed on a GitHub repo about agent containers, that is why.

Why git started to struggle

Git is decentralized. Every clone is a full, self-contained copy of the repo. It can show history, run blame and check out any revision with no network at all.

For almost every project, that is exactly the right design. The post says as much, and it is a big reason git became the standard.

Anthropic's monorepo just doesn't fit that design anymore. And here is the part that made me stop and think: almost every client hitting the repo is an agent or a CI job. Those are online by definition.

Git does have tools for working with a slice of a big repo: shallow clones, sparse checkouts and partial clones (promisor remotes). Anthropic used all of them. It also ran internal mirrors and kept repo snapshots, which the post calls seeds, in blob storage.

That bought time, but it got harder to operate as merges piled up. Seeds drifted further behind the tip of main between refreshes. Keeping diff and blame working on partial clones took more and more care.

Roughly, the git-at-scale setup looks like this:

flowchart LR
    A["Central git server"] --> B["Mirror 1"]
    A --> C["Mirror 2"]
    A --> D["...several hundred mirrors"]
    B --> E["CI jobs"]
    C --> F["Agent sandboxes"]
    D --> G["Developer environments"]

💡 The core idea Anthropic was running git as a centralized system with one authoritative copy, but still paying the cost of a distributed one. Scion starts from the question: what if we design for clients that are always online?

Scion's approach: six ideas that flip git's assumptions

Anthropic lists its design principles in the post. I find it easiest to read them as a flip of something git assumes:

A few of these deserve a closer look.

Source control as an API. In git, a CI job that wants to know who last touched a line, or how two commits relate, needs a local clone or a vendor-specific API. In Scion, those questions go straight to the server. Anthropic says its automated bisect and revert pipelines would not be practical at scale without this.

No packfiles. Scion has nothing like git's packfiles, so there is no repository maintenance to run. For a team that was running several hundred mirrors, that alone is a big deal.

Fewer refs. Scion discourages branches and tags other than main and release branches. The reason is that global state every server must agree on becomes a scaling problem.

Under the hood (the short version)

Changesets instead of commits. In Scion, the unit of work is a changeset, an entry in a write-ahead log. A git commit points to a full tree. A changeset instead lists the files that changed compared with its first parent, plus content-addressed pointers to the compressed file contents in blob storage.

Changesets are created on the server and are available everywhere instantly. Creating one takes no locks and moves no refs.

Derived data. A changeset only records what changed, so it can't answer "who last edited this line?" quickly on its own. Scion builds extra structures from changesets for that, such as blame, path history and skip lists for the commit graph. Anthropic calls this derived data, and each type can be computed eagerly or deferred.

Everything is content-addressed. Data never changes once it is stored, so any server can cache it without asking anyone else. That is why the servers behave a lot like big caches.

A different fetch protocol. The scn client does not tell the server what it already has. It starts from a root tree, finds which trees it is missing, requests them, then does the same for blobs.

Every request is for one specific, immutable object, so any cache can answer it. There is no single multi-gigabyte pack to download, and sparse or virtual checkouts need no special support because the client just doesn't ask for what it doesn't want.

The fleet is tiered:

flowchart LR
    J["Job or agent using scn"] --> D["scion-daemon, one per node"]
    D --> C["scion-cache, regional"]
    C --> S["scion-server, authoritative"]
    S --> P["Spanner and cloud storage"]

All three tiers speak the same RPCs, but Anthropic strictly enforces the tiering. The goal is to isolate failure domains, so a broken regional cache can't crush the servers behind it.

The results (and a caveat)

These are the results Anthropic reports:

🔍 Keep in mind These are Anthropic's own numbers about its own infrastructure. They are not independent benchmarks, and the headline 200x figure compares footprint against Anthropic's earlier git mirroring setup, not a plain git repo on a laptop. Treat them as a case study, not a scoreboard.

A few more differences at a glance

The earlier table covers the big design flips. These are the other differences worth knowing:

The line everyone skips: it's not a git replacement

This is the most important sentence in the whole post, and a lot of the hot takes skipped it. Anthropic says Scion is "by no means a suitable replacement for git for general use."

Their reasons:

• The ideas only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents writing code nonstop.

• Anthropic can spend far more on tokens internally than other companies would ever want to.

• Scion differs a lot from git, so a company would have to migrate every piece of its development lifecycle. Scion needs its own code review, code search and CI.

• Anthropic's internal versions of those pieces are bespoke, which makes them hard for others to adopt. The post also worries that a public version trying to please everyone would not be very useful.

So no, there is no download button waiting for you.

What Anthropic suggests instead is to take the best ideas and bring them to git without leaving the git model. A git server doesn't have to work like a git client does.

Git platforms could offer rich server-side RPCs like Scion's, maybe even standardized across forges so the git client can learn to talk to them. The negotiation protocol could change, and the sparse and shallow features could be made to work better together.

The post also gives credit where it is due. Google's Piper and Meta's Sapling are named as prior art, and the server side of Sapling (Mononoke) pioneered many of the techniques Scion uses, including the data model. And Anthropic acknowledges that the git community has spent close to two decades scaling git for millions of developers.

🧪 Want to poke at it? There is an unofficial community project on GitHub (CarterT27/scion), described as an independent, clean-room Rust implementation inspired by the post. Its README says it is not affiliated with Anthropic, that it targets one monorepo on Linux and macOS, and that production performance at Anthropic's scale has not been established.

Its own small benchmarks are mixed too, with Scion ahead on some workloads and git ahead on others. I haven't run it myself, so treat it as a learning project.

What you can use in plain git today

You can't install Scion, but a few git features already cover part of the same ground. They won't turn git into Scion, but they cut the cost of working in a big repo.

Fetch only what you need, and check out only one folder:

git clone --filter=blob:none --sparse https://example.com/big-monorepo.git
cd big-monorepo
git sparse-checkout set services/payments

The --filter=blob:none part makes it a partial clone, so file contents are downloaded on demand. The sparse checkout keeps your working directory down to the folders you ask for.

Give each task or agent its own working directory without a second clone:

git worktree add ../feature-x -b feature-x

Shallow clone for CI jobs that only need the latest state:

git clone --depth 1 https://example.com/big-monorepo.git

Scalar, which ships with git, turns on the large-repo settings for you:

scalar clone https://example.com/big-monorepo.git
# the working tree ends up in a src/ folder inside the new directory

✅ Tested All four commands were run on git 2.43.0 against a local test repo. scalar clone set up a partial clone with sparse checkout, and it put the working tree in a src folder. Whether scalar is available can depend on how git was installed on your machine.

Notice the pattern. Each of these is git trying to behave less like "everyone copies everything." That is the same direction Scion went, just much further.

The AI side of the story

A good part of the post is about how a small team pulled this off, and that is where the AI angle comes in. Everything below is Anthropic's own account of its own workflow.

• A rewrite that beat the original. The first git-to-Scion ingestion pipeline was mostly handwritten as a prototype. When the team asked an early internal snapshot of Claude Mythos Preview to rewrite it, the new version reportedly used 20x less memory and ran 4x faster, with the ordering rules intact.

• Engineers as the people who say no. The engineers on the project say Claude now writes code better than they do. Their value was in the design tradeoffs, and often in telling Claude no. One example: several systems tried to find when a change merged by reading the commit log line by line, instead of asking the code review tool.

• Reviewing intent, not lines. The team still reviews every change request, but they look at what the change is meant to do instead of reading every line.

• Rethinking the merge queue. At agent scale, a proper merge queue doesn't make much sense, and Anthropic couldn't replicate the usual global lock. They lean on post-merge and pre-deploy automated testing instead. Concurrent changes can conflict, but Claude can usually fix those faster than a person could even spot them.

• Superfans. The team set up Slack channels where Claude watches the health of one component, such as the daemon or the cache. They call these Claudes superfans, and they run alongside the normal alerts.

I would read all of this as a field report, not a recipe. It tells us what one AI-heavy team did, and it is still too early to say how well it carries over to other teams.

So, should you care?

Here is my rough rule of thumb, drawn from the post's own caveats:

flowchart TD
    A["Is your repo huge, with thousands of engineers or swarms of agents?"] -->|No| B["Stay on git"]
    A -->|Yes| C["Are mirrors, checkouts or clone times your real bottleneck?"]
    C -->|No| B
    C -->|Yes| D["Try git's own scaling tools first: partial clone, sparse checkout, Scalar"]
    D --> E["Still stuck? Look at server-centric monorepo designs"]

For almost everyone reading this, the answer is simple. Stay on git. Your repo is not 100 GB of history, and you are not running tens of millions of checkouts a day.

What I would do is keep an eye on the direction.

If Anthropic is right that these pressure points will show up for other teams using AI coding tools within the next six to twelve months, then the realistic payoff for most of us is not a new VCS. It is git hosting platforms and git itself picking up some of these ideas, like server-side queries, smarter negotiation and better sparse support.

That is my guess, not a promise. But it matches the path Anthropic itself describes in the post.

Wrapping up

Git vs Scion isn't really a fight.

Scion is a case study in what happens when a workload gets so big, and so full of always-online clients, that git's best feature becomes its biggest cost. The takeaways are the design ideas: thin clients, server-side everything, content-addressed caching, sparse by default.

If you work with a big repo, try the git commands above this week. They are small changes with a real payoff.

Sources

• Anthropic Engineering, "Redesigning source control at Anthropic," October 13, 2026: https://www.anthropic.com/engineering/redesigning-source-control

• Google's Scion (the agent orchestration testbed, a different project): https://github.com/GoogleCloudPlatform/scion

• InfoQ, "Google Open Sources Experimental Multi-Agent Orchestration Testbed Scion": https://infoq.com/news/2026/04/google-agent-testbed-scion

• Unofficial community implementation, not affiliated with Anthropic: https://github.com/CarterT27/scion