Why Anthropic Replaced Git With Scion — What Broke, What Changed, and What It Means for You

The Problem: AI Agents Outgrew Git

Anthropic's post opens with a claim that would have sounded strange a few years ago: writing code is no longer its bottleneck. As Claude made writing code dramatically faster, the bottleneck moved to the infrastructure around it — source control, builds, and CI — which was, in Anthropic's words, built for human scale.

Anthropic did not give up on Git easily. It used the tools Git offers for working with a slice of a repository — shallow clones, sparse checkouts, and promisor remotes (the mechanism behind partial clones) — and built more on top: several hundred internal Git mirrors to spread the load, and repository snapshots called seeds, kept in blob storage so jobs did not have to clone from scratch.

Each workaround bought time and added its own cost. The mirrors became harder to operate as the merge rate climbed. Seeds fell further behind the tip of main between refreshes. And history-based operations such as diff and blame needed extra care to keep working on partial clones.

Why Git's Design Worked Against Them

Git is a decentralized system. Every clone is a complete, self-contained repository with the entire history, so you can commit, branch, diff, and read the log on a plane with no network. That is exactly what makes Git so good for open source and for teams spread across the world.

Anthropic's situation was the opposite. It was, in its own words, using Git as a centralized system with one authoritative copy, and nearly all of its clients were agents and jobs that are online by definition. Every one of those clients paid for Git's offline-first promises — downloading and storing history, keeping a full repository on disk — without ever using them. The post's conclusion is blunt: the properties that make Git excellent for distributed, offline work were actively undermining its ability to scale as the repository grew.

What Anthropic Changed: Scion's Six Design Principles

A seven-person team built Scion around six principles. Each one reverses an assumption Git makes:

1. Clients are always online — so they can fetch data on demand instead of holding everything locally.
2. Client-server asymmetry — the server does most of the work; the client keeps only a bounded cache.
3. A comprehensive source control service can power many novel applications — every query is available as an API, so many jobs need no local repository at all.
4. Everything must be horizontally scalable — no packfiles and no repository maintenance.
5. Commits must be cheap, incremental, and lock-free — their cost scales with the size of the change, not the size of the repository.
6. The working copy is optional, and sparse by design — you only download what you read.

The next five sections show how those principles turn into concrete changes.

Change 1: The Server Does the Work

In Git, you commit locally and then push to share your work. Your clone does almost everything — commits, merges, rebases, log, blame — because it has the whole history. In Scion, every commit, rebase, or merge happens on the server, so there is nothing to push. The server also answers questions about file history and blame.

The trade-off is deliberate. The Scion client can compute very little on its own, but in exchange it needs far less data locally. And because the client's queries are also exposed as an API, many jobs don't need a local repository at all — a CI job that needs the diff between a commit and its merge base, for example, can simply ask the server for it.

Problem solved: millions of jobs no longer each download, store, and process history they never use.

Change 2: Changesets Instead of Whole-Project Snapshots

A Git commit points at a tree: a snapshot of the entire project at that moment. Git is smart about it — files that didn't change are shared between commits by their hash — but every commit still describes the whole project, and finding out what changed means comparing two trees. New to how commits, trees, and HEAD fit together? Start with our guide to Git's working directory, staging area, and HEAD.

Scion's unit of work is a changeset, an entry in a write-ahead log. A changeset stores most of what you would expect from a commit, but instead of a pointer to a full tree, it stores the list of files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created on the server and are available everywhere instantly.

Recording only the difference has a cost: on its own, a changeset can't quickly answer questions like "who last edited this line?" or "which commits touched this file?". Scion answers them with what it calls derived data — dedicated structures for blame and path history, and skip lists for walking the commit graph. Each type is defined recursively: its value for a changeset is computed from its values for that changeset's parents. That means the work for each new commit is small, and Scion can choose, per type, whether to compute it eagerly or only when someone asks.

Problem solved: creating a commit costs work proportional to the size of the change, not the size of a 100 GB history.

Change 3: Fetch Exactly What You Need — No Packfiles

When you run git fetch, your client and the server negotiate: the client describes which commits it already has, and the server builds a packfile — one compressed bundle containing everything the client is missing — and streams it back. For a normal repository that is efficient. For a repository this size, that single response can be enormous, and it is built specifically for that one request.

Scion's client, scn, works differently. Its negotiation doesn't tell the server what the client already has. Instead, the client checks its own local store for missing trees and requests them, recursively, by their content hash.

Because all Scion data is content-addressed, a stored object never changes. Every request is for one specific, immutable object, so any cache can answer it. The process is efficient and resumable because there is no single multi-gigabyte packfile response, and there is no equivalent of packfiles at all.

The same design makes sparse and virtual working copies almost free. Sparse checkouts need no special support: the client simply doesn't ask for trees it doesn't want. Virtualized checkouts go further and materialize files only when they are read, so a job pays only for what it actually touches.

Problem solved: no more giant per-request downloads, and no more full working copies for jobs that read a handful of files.

Change 4: Layers of Caches That Scale Out

Instead of hundreds of full Git mirrors, Scion serves objects through three layers. On each machine, the client talks to a local daemon that stores objects for the whole node. The daemon talks only to regional cache servers that stream objects straight from memory. Only when the cache doesn't have something does the request reach the authoritative servers, which read from Spanner (Google's distributed database) or cloud storage as needed.

All three tiers respond to identical RPCs, so in principle any tier could talk to any other — but Anthropic strictly enforces the layering to isolate failures. A broken regional cache should never turn into a flood of traffic against the authoritative servers. Every component scales independently, the servers need little coordination, and there is no fully materialized copy of the repository anywhere, not even on the server.

Problem solved: capacity grows by adding servers, not by operating hundreds of full mirrors that each need maintenance.

Change 5: Lock-Free Commits and (Almost) No Branches

At 30,000 merges a day, any global lock becomes a traffic jam. Scion avoids them. Creating a changeset involves no packfiles to accept, no locking or cross-server coordination, and no refs to move.

That last point is the biggest cultural difference from Git. Scion's development lifecycle discourages refs — branches and tags — except for main and release branches. Refs still exist, but neither creating nor fetching commits involves them, and moving one is a single compare-and-swap on one database row, done separately from creating changesets.

Anthropic also moved away from the industry-standard merge queue with a global repository lock, which it hasn't been able to replicate effectively at agent scale. It relies instead on post-merge and pre-deploy automated testing. That does mean concurrent changes can conflict — but, as the post puts it, Claude can typically fix those conflicts faster than humans can even identify them.

Problem solved: landing a change no longer waits in line behind thousands of others.

Git vs Scion at a Glance

The Results

How a seven-person team pulled it off

A team of seven built Scion and a new code review tool called Antique, and fully migrated the monorepo off Git in five months — while daily merges grew more than tenfold. The post describes building Scion with Claude writing code, with engineers spending more of their time judging design intent and saying "no" to over-engineered solutions, and with AI-written code backed by heavy testing, fuzzing, and simulation.

Standing on the shoulders of Piper and Sapling

None of these ideas came from nowhere, and Anthropic says so. It credits Google's Piper and Meta's Sapling — in particular Sapling's server, Mononoke, which pioneered many of the techniques Scion uses, including its Bonsai data model. Large companies have run centralized, server-heavy source control for giant monorepos for years. What changed is that AI agents pushed a much younger company into that league in a matter of months.

What This Means for Git Users

For almost everyone: nothing changes. Anthropic is explicit that Scion "is by no means a suitable replacement for git for general use," and that its concepts really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents. Scion is not released, and Anthropic says it would be difficult to offer it in a form that is broadly useful to other organizations.

What Anthropic is sharing is the ideas. It suggests Git platforms could offer comprehensive server-side RPCs like Scion's — perhaps standardized across forges — and that Git's negotiation protocol and its sparse and shallow features could evolve, and says it hopes to partner with GitHub, GitLab, and the open-source community on this. Nothing concrete has been announced yet, but if it happens, it will arrive as improvements to Git rather than a replacement for it.

Working with a large Git repository today?

Git already ships with tools built on some of the same ideas — fetching less, checking out less, and deferring work until it is needed:

# Partial clone: download file contents only when they are needed
git clone --filter=blob:none <url>

# Sparse checkout: keep only the folders you work on in your working copy
git sparse-checkout set src/app docs

# Shallow clone: skip old history entirely (handy for CI)
git clone --depth 1 <url>

# Scalar (bundled with Git 2.38+): partial clone + sparse checkout + background maintenance
scalar clone <url>