Git Became the Bottleneck? Anthropic Built Scion to Rearchitect Version Control for AI Agents

Anthropic's merge volume grew 12x in four months, and Git became the bottleneck. They built their own version control system called Scion: server-authoritative, API-first, incremental commits, with infrastructure reduced by 200x. This article breaks down its design, data, and controversies.

Anthropic's merge volume surged from 2,500 changes per day in May to over 30,000 per day in September—a 12x increase in just four months. Git couldn't handle this scale, so they built their own source code control system called Scion, and published it on their engineering blog. The post racked up over 700 comments on Hacker News, half of which said "isn't this just reinventing SVN?" They didn't, but the debate behind the post is worth a serious look for anyone running coding agents at scale.

The Numbers That Crushed Git

Anthropic shared this data in their blog post:

• Main branch history: approximately 100 GB
• Compressed working copy: 25 GB+
• CI checkouts per day: 25 million
• Raw Git traffic generated by these checkouts: 600+ PB per day
• Plus hundreds of internal Git mirrors that someone has to continuously maintain

Do the math: 600 PB divided by 25 million checkouts equals roughly 24 GB per checkout. In other words, every single checkout is a full working copy pull. No one is being lazy—the problem is that Git is doing exactly what it was designed to do, at a scale it was never designed to support.

Why Git's Design Fights Against Agents

Git assumes the user is a developer working offline, holding a complete local copy, syncing occasionally. These assumptions are features for humans but burdens for agents:

• Offline-first means every client carries the full history. Agents are always online, paying the cost for a feature they never need.
• Full local repository means a cold-start CI job or sandbox has to pull several GB before writing its first line of code.
• Mirrors are the mechanism for scaling Git reads, but they're an operational burden that grows with the number of consumers.
• Git's partial clone tools (shallow clone, sparse checkout, promisor remote) do exist, but they're optional, fiddly to configure, and feel like patches bolted on.

Anthropic reframed the question: What would source control look like if we designed it assuming agents are always online?

The shallow clone, sparse checkout, and promisor remote mentioned above are the three partial clone mechanisms Git offers to mitigate the cost of "full history + full working copy," but their maturity and usability vary widely.

Shallow clone (--depth=N) only pulls the most recent N commits, truncating history, so blame, log traversal, or merges based on older commits won't work properly—many CI scenarios will immediately hit problems.

Sparse checkout addresses redundancy at the working copy level: it only materializes specified directories, but the repository object store remains complete, so disk and network overhead aren't reduced.

Promisor remote is the closest mechanism to "fetch on demand" among the three. Combined with --filter=blob:none, it can defer blob downloads, but it requires server-side support for the filter protocol and degrades when the network is unstable or offline. It's essentially still a patch on Git's original model.

The common problem with these tools: they're off by default, cumbersome to configure, and don't have semantics fully consistent with a complete clone, making them hard to use as reliable first-class citizens in large-scale automation scenarios—which is exactly the motivation behind Scion's decision to rebuild from scratch with different default assumptions.

What Scion Actually Does

Its design principles can be summarized as:

1. Clients are always online. No offline mode.
2. The server does the heavy lifting. History, blame, commits, rebases, and merges all happen server-side; clients keep only bounded caches.
3. API-first. Every query is an RPC. No local repository needed to ask questions about the repository.
4. Horizontally scalable. No single materialized copy of any data.
5. Lock-free, incremental commits. Cost is proportional to change size, not repository size.
6. Virtualized or sparse checkout, without materializing unused files.

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

Reads go through three cache layers, all using the same RPC:

Layer	Responsibility
scion-daemon	Bounded local cache per node, bootstrapped from snapshots
scion-cache	Regional cache, streaming objects from memory
scion-server	Authoritative layer, backed by Spanner and cloud storage

Negotiation is based on "which trees and blobs do you need" rather than push/pull. This means any layer can respond.

The term "content-addressable" that appears throughout the article is a key concept for understanding the difference between Scion and Git. Its core idea is: the storage location of data is determined by the hash of the data itself, not by filename or path. Git's blob and tree objects are content-addressable—the same file content, regardless of which commit it appears in, is stored only once.

Scion follows this approach but places the addressed objects at the delta layer of changesets: each changeset is a record in a write-ahead log, storing file deltas relative to parents and pointing to content-addressable blobs. This contrasts with Git's tree objects—Git's trees are hierarchical snapshot structures, and creating a commit often requires reading and writing across multiple objects, making coordination hard to avoid on a distributed server.

The direct benefits of content addressing are deduplication and coordination-free operation: identical content is naturally shared, and the server can generate commits independently on any node without a global lock—this is the underlying basis for Scion's claims of "lock-free, incremental commits" and "horizontal scalability."

Experimental Data

Anthropic reported these results:

• Infrastructure footprint (CPU and memory) reduced by ~200x
• Checkout speed ~100x faster: from minutes to seconds
• Faster code acquisition saved CI approximately 25% of capacity
• Cache hit rates across layers at 99%+
• Zero repository maintenance

These are self-reported benchmarks on Anthropic's own workload and should be treated as "the upper bound achievable when you fully control the stack," not a baseline you can directly reproduce.

When interpreting Anthropic's data, note one methodological premise: these numbers almost all come from end-to-end comparisons on their own workload, their own hardware, their own stack, and the baseline is "a Git mirror cluster at uncontrolled scale" rather than an ideally configured Git.

Specifically, "infrastructure footprint reduced by ~200x" measures the total CPU and memory needed to support equivalent checkout traffic, not the resource consumption of a single operation. "~100x faster checkout" is wall-clock time from cold start to usable working copy, which naturally favors any approach that avoids full pulls. The 99%+ cache hit rate also depends on highly repetitive workload—the same trees and blobs requested repeatedly by large numbers of agents.

In other words, these numbers show "how high the theoretical ceiling is when you fully control the client, server, and cache layers," not "any team will get a 100x speedup after migrating." Treating vendor self-reported benchmarks as directional evidence rather than reproducible baselines is the prudent approach when reading engineering blogs like this.

The Most Intriguing Detail

Seven engineers built Scion and its companion code review tool Antique in five months, while merge volume was still growing 10x over the same period.

They spoke highly of Claude Mythos Preview. One example: a hand-written prototype for Git-to-Scion data migration was rewritten by the model without additional instructions, resulting in 20x lower memory usage and 4x faster execution while preserving implicit ordering invariants. The engineer's role shifted to design decisions, reviewing intent, and saying "no" when the model tried to violate system constraints (like brute-force searching the commit log).

Skepticism is reasonable—this is a vendor describing its own tools. But this is also the most practically valuable part: human value shifts to constraints and review, not typing.

What the Hacker News Discussion Got Right and Wrong

"So they reinvented SVN." On the surface, server-authoritative plus thin client does resemble SVN. But SVN has no content-addressable storage, no derived data layer, and no cache hierarchy designed for large numbers of automated clients. It's a different species.

"Local-first history is the whole point of Git and jj." This is the best counterargument. Making tiny local commits, amending repeatedly, discarding and starting over—these are real workflows, and Scion abandons them. This only works because Anthropic's agents never go offline. And most of us, sometimes, still do.

"Is this shipping code without human review?" The blog post doesn't claim this and describes intent review as a human responsibility. But the question is fair, given that the 30,000 merges per day figure itself invites it.

If You're Not Anthropic, Should You Care?

Broadly: no, at least not about Scion itself. The author states it only makes sense for very large monorepos with tens of thousands of engineers or agent fleets. Migrating means rebuilding code review, search, and CI around it. They expect to push some ideas back into the Git ecosystem, letting hosting platforms adopt server-side RPC and new server architectures while keeping the Git model.

But three things are free:

1. Measure your checkout cost. If your agents or CI do a fresh clone every run, you're likely paying for history you'll never read. Shallow clones and --filter=blob:none are the lowest-cost 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

2. Treat the repository as a service, not a folder. If agents need blame, history, or search, APIs beat local clones.

3. Before Git becomes your bottleneck, review is your bottleneck. It's no coincidence that Anthropic built a code review tool alongside a version control system.

My Take

The genuinely interesting claim isn't "Git is dead"—it's that Git's defaults encode a human workflow, and agent workloads overturn nearly every one of them. Expect hosting platforms to respond with server-side operations and better partial clone experiences, and expect more large companies to quietly build their own solutions.

Git has survived twenty years of "what comes after Git." It will likely survive this too. It's just that its role as the layer agents talk to directly may not last much longer.

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