Your merge queue is serial by design: one group of changes tests against main, lands, and only then does the next group start. That is safe, and it is fine, right up until the authors stop being human. Anthropic's monorepo went from about 2,500 merged changes a day in May 2026 to over 30,000 a day by September, most of that growth written by Claude agents, and Git, mirrors and all, stopped keeping up. So a team of seven built a new version control system called Scion and migrated the entire monorepo off Git in five months. This post is not a eulogy for Git. It is the math that shows where the serial wall actually stands, how Scion deleted it, and how far your team is from needing to care.

The numbers that broke Git

Start with the workload, because Scion makes no sense without it. Every figure in this section is Anthropic-reported, published in its October 13, 2026 engineering post and covered independently by InfoQ on October 27. Nobody outside Anthropic has audited them, so read them as a credible self-report, not a benchmark.

  • Merged changes: about 2,500 a day in May 2026, over 30,000 a day by September. A tenfold-plus jump in four months.
  • The main branch history alone is almost 100 GB. A compressed working copy is over 25 GB.
  • CI performs on the order of 25 million code checkouts per day, before counting developer environments, agent sandboxes and research jobs. Anthropic's own illustration: fetched naively, that is over 600 PB of Git traffic a day.
  • At peak, Anthropic operated several hundred internal Git mirrors to spread the load.

Anthropic did not skip the standard playbook. It used shallow clones, sparse checkouts, promisor remotes and repository snapshots kept in blob storage. The mirrors bought time, then became the problem: seeds fell further behind the tip of main between refreshes, mirrors strained against disk and memory limits, and history operations like diff and blame got fragile on partial clones.

The sentence in Anthropic's post that explains everything else is this observation: like most companies, it was using Git as a centralized system with one authoritative copy, but nearly all of its clients were agents and jobs that are online by definition. Git's great strengths, full local copies and offline work, had become pure tax. Every checkout dragged around a history nobody on that machine would ever read.

How Scion works: Git's assumptions, inverted

Scion is a client-server version control system built by Anthropic for its own monorepo. If Git assumes a smart client and a dumb store, Scion assumes the opposite.

The server does the work. In Scion, the server answers history and blame questions, creates commits, and performs merges and rebases. The client keeps a bounded local object cache, lays out the working copy files on disk and watches the filesystem for changes. It computes very little on its own, and in exchange it needs very little data locally.

The unit of work is a changeset, not a tree. A Git commit points at a full tree of the repository. A Scion changeset is an entry in a write-ahead log: it stores the list of files that changed relative to its first parent, plus content-addressed pointers to the compressed file contents in blob storage. Metadata lives in Spanner. There are no packfiles to build, no locking and no cross-server coordination in the write path, so changesets can be accepted at very high throughput. Branches (refs) barely feature: moving one is a compare-and-swap on a single Spanner row, and the workflow discourages refs except for main and release branches, because global state every server must agree on does not scale.

Derived data replaces stored history views. A changeset only knows what changed, so Scion computes everything else, blame structures, path history, skip lists over the commit graph, from the changesets through one generic recursive mechanism. Each derived type is computed from its parents' values, can be computed eagerly or lazily, and can be added without changing the client. When a new index would make an operation faster, Anthropic adds a derived type instead of shipping a new client.

Fetch means "what I want", never "what I have". Git fetch negotiation revolves around what the client already holds, so the server can build a packfile of the difference. A Scion client starts from a root tree and recursively requests the trees and blobs it wants. Every object is immutable and content-addressed, so any cache can answer any request. In production the path is a three-tier cache: a daemon on each node, a regional cache streaming objects from memory, and the authoritative servers reading Spanner or cloud storage only on a miss. Anthropic reports a cache hit rate over 99% at each tier.

The working copy is optional. Checkouts are sparse by design, containing only the directories the client asked for, and can be virtualized so files materialize only when read. Many jobs skip the checkout entirely: every query the client can make is also an API, so Anthropic's automated bisect and revert pipelines ask the server for diffs and merge bases directly, with no local repository at all.

The reported results, again Anthropic's own numbers measured against its own old setup: an infrastructure footprint 200 times smaller than its previous Git mirroring infrastructure in CPU and memory, checkouts two orders of magnitude faster for CI and research jobs (seconds instead of minutes), and a 25% CPU capacity win in CI alone. Directionally, that is what you would expect when 25 million daily checkouts stop dragging full histories around. Treat the exact multipliers as one company's internal before-and-after, because that is all they are.

One more piece of honesty, because it matters for how much of this is new: Anthropic credits Google's Piper and Meta's Sapling as prior art in the post itself, and after publication it expanded the credit to Meta's Mononoke, the server behind Sapling, whose data model Scion closely follows. Scion is an execution of ideas the industry has been developing for a decade, done fast, under pressure, with agents writing much of the code.

The real break: a serial merge queue cannot survive agent scale

The checkout storm is only half the story. The deeper break is in how changes land.

The industry-standard answer to a busy main branch is a merge queue: changes line up, each group is tested combined with everything ahead of it, and a global lock on main guarantees that what lands has passed. GitHub's merge queue, merge trains elsewhere, bors before them, all share the same shape. Safe, orderly, and fundamentally serial.

Now do the arithmetic, because the arithmetic is the whole argument:

  • 30,000 merges a day is one merge landing every 2.9 seconds, on average, around the clock.
  • A strictly serial queue running a 10-minute check per group lands at most 144 groups a day (1,440 minutes divided by 10). Batch five pull requests per group and you reach roughly 720 merges a day. Anthropic needed 30,000.
  • For a serial queue to land 30,000 changes a day, the complete check for each merge would have to finish in under 3 seconds. Forever. Including your slowest flaky test.

Batching and speculative parallel checks stretch the model a long way, which is why real queues work fine at dozens or a few hundred merges a day. But the ceiling is structural: whenever merges per day multiplied by CI minutes exceeds the 1,440 minutes in a day, a purely serial design is over capacity before you argue about hardware. At 100 merges a day with 15-minute CI, that product is already 1,500.

Anthropic's answer was to delete the lock. In its own words, a proper merge queue "doesn't make much sense at agent scale", and it could not effectively replicate the industry standard of a global repository lock. So changes land first, and the safety net moved: testing happens after the merge and before deployment. Concurrent changes do sometimes conflict, and Anthropic says Claude typically fixes those conflicts faster than a human can identify them. That trade only works when the fixer is an always-on agent and the cost of a briefly inconsistent main is lower than the cost of a queue that never drains.

Do not take my word for where your team sits on this curve. Run it:

Set the authors to engineers plus agents, and watch two things: the serial queue's backlog at the end of the day, and the exact author count where arrival rate passes service rate. That crossing point is the wall. Then use the step mode and walk the queue's failure modes one by one: a stale base, a rebase tax, and a red build at the front that stops every merge behind it. Switch to the parallel model and watch the same day play out without the lock, the same change landing in about twelve minutes instead of five hours and forty. The simulator is a simplified model: it assumes a constant 10-minute CI pass, no flaky tests, and a parallel model with six validators and no global lock. It is there to give you intuition for the shape of the problem, not to benchmark your pipeline.

What Scion is not

Three fences around the hype, all from Anthropic itself.

You cannot have it. Scion is internal. It is not open source, it is not sold, and Anthropic has announced no public release, waitlist or timeline. Anthropic says it would be difficult to offer in a broadly useful form: Scion diverges significantly from Git, so adopting it means migrating your whole development lifecycle, and it depends on companion systems (its code review tool Antique, code search, CI) that are highly bespoke.

It is not an indictment of your repository. Anthropic's verdict on its own system: "Scion is by no means a suitable replacement for git for general use." The concepts, it says, only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Anthropic is also unusually able to burn tokens on internal tooling, and it says so.

It is not the direction Anthropic recommends for you. Its stated hope is the opposite of replacement: that Git platforms absorb the successful parts, comprehensive server-side APIs like Scion's, better fetch negotiation, sparse and shallow features that compose well, and that it can partner with GitHub, GitLab and the open source community to get there. The company that left Git is telling you Git should evolve, not die.

What your team can steal today

You cannot adopt Scion, but every pressure it answers has a shipping answer at normal scale.

If your main branch is busy, turn on the merge queue you already have. GitHub's merge queue is built into the platform for organization repositories. It merges first-in-first-out, builds temporary merge groups containing the base branch plus every pull request ahead of yours, and lands the group only when required checks pass on the combined result. A failing pull request is removed and the groups behind it are rebuilt automatically. Two settings matter most: merge limits, which let the queue batch several pull requests per group (that batching is exactly the multiplier the math above says you need), and build concurrency, which caps how many merge group checks run at once so the queue does not melt your CI budget. The one setup gotcha: your CI must trigger on the merge_group event, not just pull_request, or the queue will wait forever for checks that never report.

If clones and checkouts are the pain, take Git's slice tools seriously. Partial clone with sparse checkout is the same mitigation Anthropic itself ran before Scion, and it ships in the Git you already have. For a growing monorepo, a blobless partial clone plus sparse checkout of the directories a job actually touches removes most of the download and disk cost without changing anyone's workflow.

If review throughput is the drag, stack your changes. Graphite's whole product is stacked pull requests on top of GitHub, with automated merging that lands a stack one pull request at a time and restacks everything above it. Small, stacked changes review faster than one mega pull request, and the queue at the end gets smaller units to batch.

If rebases and restacking eat your senior engineers' afternoons, try jj as a front end. Jujutsu runs on top of your existing Git repository, so it is an afternoon experiment, not a migration. Its working copy is itself a commit that amends automatically as you edit, every change carries a stable change ID that survives rewrites, and conflicts are recorded inside commits instead of blocking every other operation. For developers who live in stacked, constantly rewritten history, which is exactly the shape agent-assisted work takes, it removes a category of pain Git makes you pay daily.

And keep Sapling in mind as the proof of pattern. Meta's Sapling is the open source relative in this family: a client you can install today that works on Git repositories and with GitHub, with stacks and restacking built in. Its own documentation is upfront that the server and virtual filesystem that let it scale to tens of millions of files inside Meta are not yet public. That split is the honest map of 2026: the client side of the post-Git future is testable now, the server side is what the forges will ship next.

I have seen this progression from the other end, on ordinary team repositories: first the queue is a convenience, then it is load-bearing, then someone checks the wait time graph and realizes landing code, not writing it, is the team's real sprint bottleneck. Anthropic just hit that wall at a scale where the only way through was to rebuild the floor.

My verdict

Keep Git. Anthropic did not leave Git because Git is badly designed; it left because its author count effectively became thousands of always-online agents landing a change every three seconds, and no serial system survives that. Your repository is not there, and the honest evidence is that almost nobody's is: Anthropic itself expects this class of problem to become commonplace over the next six to twelve months, which is a forecast, not a description of your Tuesday.

Here is the pick I would defend for a normal team, in order:

  1. Measure two numbers this week: merges per day on your busiest branch, and full CI minutes. Multiply them. Well under 1,440, your queue has headroom and Scion is a fascinating article, nothing more. Anywhere near it, batching stops being optional.
  2. Turn on your forge's merge queue before you feel you need it, with batching enabled. Queues are cheap to adopt early and miserable to adopt under pressure.
  3. Watch the author mix, not the tool announcements. The day agents open most of your pull requests, your bottleneck moves from writing code to landing it. That shift, not Scion itself, is the thing to prepare for.

Not sure which side of the line your team is on? Answer four questions and I will place you:

If your numbers came back closer to the wall than you expected, and you are wiring agents into a Next.js and NestJS codebase that still has to land code safely every day, that is precisely the layer of the stack I build for teams. Tell me about your project and I will tell you honestly whether you need a merge queue, a pipeline rebuild, or nothing at all.

Related reading: Cloudflare, Deno and the Workers deployment reshuffle, another case of platform infrastructure being rebuilt around a workload it was not designed for.