After Anthropic swapped git for Scion: should agent-era teams change their VCS?

On 13 October 2026, Anthropic confirmed in its engineering post “Redesigning source control at Anthropic” that the company had fully replaced git with a homegrown version control system called Scion, migrating the entire monorepo with seven engineers in five months. The driver was scale: daily merges rose from about 2,500 in May to over 30,000 by September, CI ran roughly 25 million code checkouts a day, and — in the post’s own words — git had become “our biggest development bottleneck.”

This article is not about what Scion is. It is about a practical question: when coding agents raise the speed of writing code by an order of magnitude, should your team change its version control system? The short answer, for almost every team, is no — but the reasoning behind that no is more useful than the list of things Anthropic built.

Key points

• The migration was done by a seven-person team in five months while daily merges grew from about 2,500 to over 30,000; CI checkouts dropped from minutes to seconds (the post says roughly 100x faster), freeing about 25% of CI CPU capacity, with an infrastructure footprint 200 times smaller than the old git mirror fleet.
• Scion is online and centralized: the write path lives entirely on the server, the commit unit is a changeset that lands directly in a write-ahead log, and there is no push. The read path has three tiers — developer daemon, regional cache, authoritative server — with cache hit rates above 99% at every level. It is explicitly not open source and not positioned as a general git replacement.
• Built alongside it were about six supporting systems including the review system Antique with semantic approval constraints and a merge queue, code search, per-directory IAM, and automated bisect/revert pipelines — this was a development-stack migration, not a git command swap.
• None of the official or community numbers have third-party verification; the Hacker News objections that “git wasn’t actually at its limit” and “30k merges may not equal useful output” both stand.

Where the bottleneck actually is

The most informative thing in Anthropic’s post is the curve, not the architecture diagram: every Claude model release is marked on the timeline — Opus 4.6 in February, Mythos Preview in April, Fable 5.1 and Mythos 5.1 on 1 September — and the curve steepens after each one, peaking at 30,401 merges on 9 September. Nick G., one of the post’s authors, confirmed on Hacker News that the ability to delegate large chunks of code to Claude took a “step change” after Mythos Preview.

How to read that curve split the HN discussion, and both sides are worth reading. The skeptics ask whether a surge in code changes means the software got better: one widely upvoted comment calls the nearly 100 GB main-branch history “absurd” and suspects Anthropic is using git history as a message queue; others ask why requirements are changing faster, and whether merge volume can grow indefinitely. The engineering counter is that at Anthropic’s scale, checkout traffic is itself the cost — per the post, continuing with native git would mean over 600 PB of daily CI checkout traffic, and at that magnitude “a minute per checkout” burns thousands of machine-hours a day.

The lesson for readers: merge volume, checkout volume and repository size are three independent metrics, and they need measuring separately. A team can merge rarely with a huge repo (uncleaned history), or merge constantly with a small one (microservices with shallow history). Anthropic hit all three at once — that is why it had to act. If you want to see the git-side answer to parallel agent work, alphaXiv’s OpenResearch puts each research direction in its own worktree, and agent-skills constrains how agents behave in the first place.

What Scion actually changed

Scion’s architectural choice, in one sentence, is: give up offline capability and move everything server-side. Three design decisions explain why it does not fit you.

The write path has no push. In git, commits happen locally and push synchronizes them; Scion’s commit unit is a changeset that lands directly in the write-ahead log, and creating one does not require moving any reference — a reference update is a compare-and-swap on a single Spanner row, with main and release branches among the few references kept. The cost is obvious: no local history means no offline commits. The benefit is that a commit is globally visible immediately, the server is the single source of truth, and conflict arbitration does not wait for clones to sync.

The read path has three cache tiers. A scion-daemon on the developer machine, a regional scion-cache, and the authoritative scion-server expose the same RPC; clients request only the trees and blobs they need, and content-addressed immutable objects are cacheable, with the post claiming hit rates above 99% at every tier. Sparse and virtualized checkouts materialize files on demand — which solves “check out a 25 GB working copy to edit one file.”

Why offline could be dropped. Simon Willison’s independent analysis quotes the engineering explanation: Claude is by far Scion’s heaviest user, “and is necessarily online.” That sentence is the premise of the whole design — Anthropic’s workload has no “write code on a plane” scenario. Your team probably does.

Willison also reads Scion as “a reinvention of centralized version control along Subversion lines,” and notes that its derived-data design was heavily influenced by Mononoke, the server component of Meta’s Sapling. The lineage matters: Scion is not the first system to do this — Google’s internal Piper and Meta’s Sapling are both credited as prior art. The difference is that the first two served “tens of thousands of people in one monorepo,” while Scion serves “tens of thousands of agent sessions in one monorepo” — the density of concurrent writers went up another order of magnitude.

Dimension	Native git (before the migration)	Scion
Commit model	Local commits plus push	Server-side changesets, no push
Offline capability	Full	None (explicitly dropped)
Checkout model	Full or sparse (cone mode)	Sparse/virtualized, materialized on demand
Conflict arbitration	Negotiated between clones	Single server-side authority
Supporting systems	Self-built (mirror fleet)	Built at the same time (Antique and five more)
Open-source status	Open ecosystem	Not open source, not a general replacement

The middle path git already offers

Reading Anthropic’s choice as “git can’t cope” is a misreading. Two capabilities in git’s own documentation map exactly onto the problems Scion solved, and most teams have never used either to its limit.

partial clone targets repository size: clone and fetch accept --filter, telling the server to omit unneeded trees or blobs, with missing objects fetched on demand. The documentation is equally clear about the cost — it requires network access and a promisor remote, dynamic fetching can be slow (it may fetch objects one at a time over protocol V0), and fetching one object also fetches the objects it references. So partial clone trades “on-demand network round trips” for “local disk and time”: fine for working locally in a large repo, not something to build an entire CI farm on.

sparse-checkout targets working-copy size: cone mode is the default and recommended, and once you name directories, Git stops populating files outside the selection while they stay under version control; the sparse index improves commands like status and add, though the docs mark it experimental. This is the git-side counterpart of Scion’s virtualized checkout — the difference is that Scion built it into the protocol and the server rather than shipping it as a client option.

There is a third path in the community: Meta’s Sapling can act as a git frontend (cloning, pushing and pulling still go through git) and supports local commits, amends and undos; but the official documentation states plainly that the server and virtual filesystem that support its tens-of-millions-of-files scale are “not yet available publicly,” and that git compatibility “may have some remaining kinks to be worked out.” For teams that want a centralized workflow gradually, this is a more realistic starting point than writing your own — and Anthropic itself credits Piper and Sapling, suggests the community improve git’s server side (server-side diff/merge, smarter protocol negotiation, combining sparse and shallow clones), and says it is willing to work with GitHub and GitLab.

The real cost: a whole stack

The most easily missed fact about Scion is that it never traveled alone. The post lists about six supporting systems built in the same period, including the review system Antique with semantic approval constraints and a merge queue, code search, per-directory IAM, and automated bisect/revert pipelines. The authors are blunt: adopting such a system elsewhere means migrating the entire development lifecycle — review, search, CI — and without one of those pieces, a new VCS is a half-finished tool.

That is what makes the HN objection — why rewrite instead of improving git — a fair one. A widely upvoted comment counts the rungs between “vanilla git” and “a bespoke VCS”: server mirrors, partial clone, sparse checkout, Git LFS, monorepo tooling — and notes most teams solve their problem by rung one to three. The counter-argument is equally strong: seven people over five months may genuinely be cheaper than improving the git ecosystem at Anthropic’s scale, and the system’s data ingestion pipeline was itself rewritten by Claude Mythos Preview — the post says it used 20x less memory and ran 4x faster than the engineers’ hand-written prototype. Once the loop of “use Claude to build tools for Claude” starts turning, the marginal cost of “rewrite it” keeps falling.

Both camps point at the same conclusion for readers: the break-even point between “build” and “adopt” is moving, but which way it moves depends on the team. Teams with agent infrastructure and the budget for custom maintenance see the balance tip toward building; small teams without a platform group should touch it even less — you have not even configured your git mirrors yet.

A decision framework for ordinary teams

If your CI runs more than ten thousand checkouts a day, or a clone takes minutes, work through this list in order — most teams stop bleeding in the first two steps:

1. Measure before changing. Collect a week of data: daily CI checkout count, P95 checkout time, checkout transfer volume, mirror cache hit rate, CI CPU usage. Without those numbers, “git is slow” is a feeling. Anthropic’s decision rested on a computable fact — 600 PB per day.
2. Use what git already has. Narrow the working copy with sparse-checkout (cone mode), fetch blobs on demand with partial clone, pin CI to shallow clones plus mirrors; if history is bloated, evaluate truncation or a migration strategy — the HN suggestion of “semantically truncating history” is rude in tone but right in direction.
3. Fix the surroundings, not just the VCS. Slow checkouts are often not git’s fault: CI cache strategy, artifact registry location and test selection (running only affected tests) usually pay off more.
4. Only when the first three are exhausted, evaluate a centralized VCS. Then screen candidates with three questions: do we need offline, who maintains it, and what does migrating review and CI cost. git-compatible options like Sapling come before writing your own.
5. Do not copy Anthropic’s timeline. The post expects these scale problems to spread to more organizations “in the next six to twelve months” — but what spreads is the checkout-pressure problem, not the build-your-own-VCS answer.

An honest close: every performance number in this analysis — 100x faster checkouts, 25% CPU freed, 200x smaller footprint — comes from Anthropic’s own account, with no third-party remeasurement, and Scion is not open source, so outside teams cannot verify it either. What it proves is that “this design holds at Anthropic’s scale,” not that “it is optimal at yours.” git is not dead; this looks more like an infrastructure revaluation forced by the pace of agentic development: when the marginal cost of writing code approaches zero, the bottleneck moves up the pipeline — review first, then checkout, and whatever comes next is worth watching. For the news write-up of the event itself, see our earlier entry Anthropic ditches git for Scion; this piece adds the architecture tradeoffs and the decision framework.