Git Is Now the Bottleneck: Anthropic Just Built a Git Alternative for AI Agents

Anthropic's merge rate went from 2,500 changes a day in May 2026 to over 30,000 a day in September. That's 12x in about four months.

Git didn't survive it. So they built their own source control system, called Scion, and wrote it up on their engineering blog. It's sitting near the top of Hacker News with 700+ comments, and half of them say "so they reinvented SVN."

They didn't. But the argument underneath the post matters for anyone running coding agents at scale, so here's the useful part.

The numbers that broke git

From Anthropic's post:

• Main branch history: ~100 GB
• Compressed working copy: 25 GB+
• CI checkouts: 25 million per day
• Naive git traffic from those checkouts: 600+ PB per day
• Plus hundreds of internal git mirrors that someone has to keep alive

Check the arithmetic: 600 PB / 25M checkouts is about 24 GB per checkout. That's one full working copy, every time. Nobody was being sloppy. Git is just doing what it was designed to do, at a scale it was never designed for.

Why git's design fights agents

Git assumes a developer who works offline, owns a full local copy, and syncs occasionally. Every one of those assumptions is a feature for humans and a tax for agents:

• Offline-first means every client carries full history. Agents are always online, so they pay the cost and never get the benefit.
• Full local repo means a cold CI job or sandbox pulls gigabytes before it writes a line.
• Mirrors are how you scale git reads, and they're an ops burden that grows with the number of consumers.
• Git's partial tools (shallow clones, sparse checkout, promisor remotes) exist, but they're opt-in, fiddly, and bolted onto the model.

Anthropic's reframing: if we designed source control knowing agents are always online, what would it look like?

What Scion actually does

The design principles, paraphrased:

1. Clients are always online. No offline mode.
2. The server does the heavy work. History, blame, commits, rebases and merges all happen server-side. Clients keep a bounded cache.
3. API-first. Every query is an RPC. You don't need a local repo to ask a question about the repo.
4. Horizontally scalable. No single materialized copy of anything.
5. Lock-free, incremental commits. Cost scales with the size of the change, not the size of the repo.
6. Virtualized or sparse checkouts so you don't materialize files you don't need.

Under the hood, changesets are entries in a write-ahead log. They store file deltas against the parent and point at content-addressed blobs. Unlike git's tree objects, that lets the server create commits without cross-server coordination. Derived data (blame, path history, skip lists) is computed from changesets on demand or eagerly.

Reads go through a three-tier cache that all speak the same RPCs:

Tier	Role
scion-daemon	Per-node, bounded local cache, starts from snapshots
scion-cache	Regional, streams objects from memory
scion-server	Authoritative, backed by Spanner and cloud storage

Negotiation is based on "which trees and blobs do you want," not push/pull. So any tier can answer.

Results

• ~200x smaller infrastructure footprint (CPU and memory) than the git mirror setup
• ~100x faster checkouts: seconds instead of minutes
• ~25% CI capacity saved from faster code retrieval
• 99%+ cache hit rates across tiers
• Zero repository maintenance

These are Anthropic's own numbers on their own workload. Treat them as "what's possible when you own the whole stack," not a benchmark you'll reproduce.

The detail I keep thinking about

Seven engineers built Scion and its companion code review tool, Antique, in five months, while merge volume grew 10x underneath them.

They credit Claude Mythos Preview heavily. One example: the handwritten git-to-Scion ingestion prototype was rewritten by the model with no further instructions. The result used 20x less memory and ran 4x faster, while preserving the implicit ordering invariants. The engineers' role shifted to design decisions, reviewing intent, and telling the model "no" when it tried something that violated system constraints, like brute-force searching the commit log.

If you're skeptical, fair. That's a vendor describing its own tool. But it's also the part with the most practical lesson: the human value moved to constraints and review, not typing.

What the HN thread got right (and wrong)

"So they reinvented SVN." Superficially, server-authoritative with thin clients rhymes with SVN. But SVN had no content-addressed storage, no derived-data layer, and no cache hierarchy built for fleets of automated clients. Different animal.

"Local-first history is the point of git and jj." This is the best objection. Making tiny local commits, reworking them, and throwing them away is a real workflow, and Scion gives it up. That only works because Anthropic's agents are never disconnected. Most of us still are, sometimes.

"Is this shipping code with no human review?" The post doesn't claim that, and it describes intent review as the human job. But the question is fair, and 30,000 merges a day is a number that invites it.

Should you care if you're not Anthropic?

Mostly: no, not for Scion itself. The authors say it only makes sense for enormous monorepos with tens of thousands of engineers or agent swarms. Migrating means rebuilding code review, search and CI around it. They say they expect to push the ideas back toward git, with hosting platforms adopting server-side RPCs and new server architectures without abandoning the git model.

But three takeaways are free:

1. Measure your checkout cost. If your agents or CI clone fresh every run, you're probably paying for history you never read. Shallow clones and --filter=blob:none are the cheap first step:

git clone --depth=1 --filter=blob:none --sparse https://example.com/big-repo.git
cd big-repo
git sparse-checkout set services/my-service

1. Treat the repo as a service, not a folder. If agents need blame, history or search, an API beats a local clone.
2. Review is your bottleneck before git is. Anthropic built a code review tool alongside the VCS for a reason.

My take

The interesting claim isn't "git is dead." It's that git's defaults encode a human workflow, and agent workloads invert nearly all of them. Expect hosting platforms to respond with server-side operations and better partial-clone ergonomics, and expect a few more big shops to quietly build their own thing.

Git has survived two decades of "what comes after git" posts. It'll probably survive this one. It just won't be the layer your agents talk to directly for much longer.

Source: Redesigning source control at Anthropic and the Hacker News discussion.