On 13 October 2026, Anthropic published Redesigning source control at Anthropic. Its monorepo no longer runs on Git. A team of seven built an in-house version control system called Scion, plus a code review tool called Antique, and finished the migration in five months, with Claude writing a lot of the code.
The Hacker News thread passed 895 points and 1,000 comments. I read the post, the two Mononoke posts that followed it, and the biggest sub-threads. Here's how Scion works, where Claude actually fit, the credit fight, and what plain Git already gives you.
TL;DR
- Anthropic went from about 2,500 merged changes a day (May 2026 average) to a record 30,401 (9 September), and says Claude's code is why. Another Anthropic page says Claude authored more than 80% of the code it merged as of May 2026.
- Scion moves the work to the server: commits, merges, rebases, blame and history. Clients are thin and assumed to be online.
- Anthropic reports a 200x smaller CPU and memory footprint than its old Git mirror fleet and a 25% CPU capacity win in CI. Its text says checkouts got two orders of magnitude faster; its own chart shows a median CI checkout going from 31 s to 3.5 s (x8.8).
- An early Claude Mythos Preview snapshot rewrote the Git importer with no further instructions: 20x less memory, 4x faster.
- Much of the design has prior art in Meta's Mononoke and Google's Piper. Anthropic expanded its credit to Mononoke on 15 October.
- Anthropic's own verdict: Scion "is by no means a suitable replacement for git for general use." It isn't open source.
The scale that broke Git
The numbers from the post:
| What | Figure |
|---|---|
| Main branch history | almost 100 GB |
| Compressed working copy | over 25 GB |
| CI checkouts | on the order of 25 million a day |
| Naive Git traffic for that | over 600 PB a day |
| Git mirrors at peak | several hundred |
The 600 PB line took heat. HN user nh2 pointed out that it assumes a full clone per checkout, "which of course nobody should do". The author agreed: "The point is that it is a non-starter to operate this way but git doesn't hold your hand to do the right thing here."
The real story is the pile of workarounds: shallow clones, sparse checkouts, promisor remotes, mirrors, and repo snapshots ("seeds") in blob storage. Seeds drifted further from main between refreshes. Diff and blame on partial clones needed more and more care.
Then came the observation that changed the design: "nearly all of our clients were agents and jobs that are online by definition." Git's best property, a complete offline repo in every clone, had turned into dead weight.
How Scion works
The server does the work
In Git, every clone can act as a full server. Scion is deliberately asymmetric. The server answers history and blame questions, creates commits, and performs merges and rebases. The client keeps a bounded object cache, lays out files and watches the filesystem.
Every query the client can make is also an API. A CI job that needs the diff against its merge base just asks for it, with no checkout at all. Anthropic says its automated bisect and revert pipelines "wouldn't be practical at scale without this cheap, programmatic access to source control."
There's no local commit and nothing to push. Refs exist, but the workflow discourages them except for main and release branches, because global state that every server has to agree on doesn't scale.
Changesets, not trees
A Git commit points at a full tree. A Scion changeset is an entry in a write-ahead log. It lists the files changed relative to its first parent, with content-addressed pointers to compressed contents in blob storage.
That makes writes cheap: no packfiles to accept, no locks, no cross-server coordination. Moving a ref is a compare-and-swap on a single Spanner row, separate from creating changesets.
Derived data
A changeset only knows what changed, so on its own it can't answer "who last touched this line". Scion computes derived data for that: blame structures, path history, skip lists over the commit graph. Each type is defined recursively from a changeset's parents, can be computed eagerly or deferred, and is invisible to the client. So the team keeps adding new indexes without touching the client.
On HN, the post's author also cited Martin Kleppmann's Turning the database inside out as an inspiration, alongside Mononoke. That essay describes indexes, caches and materialized views as data derived from the original.
A fetch protocol made for caches
This is the part I'd steal. Git's fetch negotiation revolves around what the client already has, so the server can compute a packfile of what's missing. Scion's client only says what it wants. It starts from a root tree, checks its local store, then requests missing trees and blobs recursively.
Every request names an immutable, content-addressed object, so any cache can answer it:
job -> scn client -> scion-daemon (per node) -> scion-cache (per region) -> scion-server -> Spanner / cloud storage
All tiers answer identical RPCs, so the client doesn't care about topology. Each tier keeps a cache hit rate over 99%. Sparse and virtualized checkouts need no special support, because the client simply doesn't ask for trees it doesn't want. Transfers are resumable too, since there's no multi-gigabyte packfile response.
Anthropic's results: a 200x smaller footprint than the Git mirror fleet, checkouts "two orders of magnitude faster", and a 25% CPU capacity win for CI.
Read the post's own median-time chart before you repeat the middle one, though. Git vs scn:
| Command | git | scn | Faster |
|---|---|---|---|
| Checkout in a CI job | 31 s | 3.5 s | x8.8 |
| Checkout at the start of a compute job | 175 s | 22 s | x8.0 |
| New worktree, agent environment | 7.1 min | 5.1 s | x84 |
| Status, developer environment | 3.9 s | 19 ms | x207 |
| Commit, developer environment | 1.4 s | 1.1 s | x1.3 |
| Total source control time per change request, agents | 34 min | 3.7 min | x9.2 |
Big wins everywhere, but "two orders of magnitude" holds for a few commands, not for CI checkouts. Same caution for the merge chart: its callout reads "30,401 merged on Sep 9". The "over 30,000 per day" in the text is the record day, and the 7-day average line sits well below it.
Where Claude fit (and where it didn't)
Seven people built Scion and Antique, "not to mention half a dozen related systems," in five months, while merge volume grew 10x. What the post and the author's HN comments say about Claude:
- The importer. The first Git-to-Scion ingestion pipeline was "largely handwritten". An early internal snapshot of Claude Mythos Preview rewrote it "with no further instructions": 20x less memory, 4x faster, with the ordering and data-structure invariants preserved.
- Before that model, the author says, the code was "only moderately assisted by Claude with a lot of human-still-typing-things-in-an-editor." Mythos Preview brought "a noticeable, step function increase."
- Engineers said no. Everyone on the team "would now rate Claude as better at writing code than them." But very often "the role of the engineers was to tell Claude 'no.'" One example: systems that worked out when a change merged by linearly reading the commit log instead of asking the code review tool. Adversarial review also pushed Claude toward over-engineering.
- Review changed. Humans still review every change request, but they check its intent instead of reading every line.
- Operations. Claude instances nicknamed "superfans" each sit in a Slack channel, through Claude Tag, watching one component's telemetry and logs.
- No global merge lock. Hundreds or thousands of changes can land while tests run, so testing moved post-merge and pre-deploy. Conflicts happen, and "Claude can typically fix these conflicts faster than humans can even identify them."
Two caveats. Mythos-class models are limited to a small set of vetted organizations, so most of us can't reproduce that rewrite. And the 20x and 4x numbers come with no benchmark, which HN noticed.
The Mononoke question
Here's the timeline, from primary sources:
- 13 October. Anthropic's post credits Google's Piper and Meta's Sapling as prior art.
- 14 October. Rain, who worked on Mononoke at Meta, publishes Anthropic's Scion is heavily inspired by Mononoke on sunshowers.io (426 points). Mononoke is Sapling's server, and its Bonsai changesets look a lot like Scion's changesets. The charge: Meta's team "came up with many of the insights that Claude dutifully applied almost a decade later."
- 15 October. A second post, More on Anthropic's Scion ripping off Mononoke (254 points), makes the point explicit: "The problem is attribution, not copying." It also notes that "Scion" reverses the syllables of "Bonsai" and drops the "B", adding: "This might be a coincidence, or might not." On HN, citing private correspondence, Rain writes that "Claude was pointed directly at Mononoke and asked to re-engineer it." Nobody outside can verify that.
- 15 October, 17:59 UTC. Nick G., the Anthropic post's author, replies. Sapling was credited because that's how Meta refers to the whole system. "We also did not just tell Claude to build us a version control system." A footnote gets added. Asked what share of the codebase was directly inspired by Mononoke: "Very little, overall."
- Same day. The post now reads "Updated October 15", with a footnote saying Mononoke "pioneered many of the techniques we use in Scion, in particular the Bonsai data model." Rain replies: "I now believe the attribution is sufficient."
The best exchange came next. durhamg, "the longest serving and most senior member (now ex-member) of the Facebook source control team", wrote: "I had no problem with your post." Rain answered that "this belief is not unanimous among the current source control team at Meta."
Why not just run Mononoke? HN user fcarraldo had tried: "Open source Mononoke and EdenFS don't really work outside of Meta."
For context, here's who got here first:
| System | Who | Since | The idea Scion shares |
|---|---|---|---|
| Piper | 2012 | A central repo. The toolchain "requires developers to be online" (CACM, 2016) | |
| Mononoke and EdenFS | Meta | 2017 and 2018 | Sapling "transitioned to a client-server architecture" (Sapling docs) |
| VFS for Git, then Scalar | Microsoft | Scalar in Git 2.38 | Git "slightly more coupled to a central server for missing objects" (Microsoft, GitHub) |
That same 2016 paper counts 16,000 human changes and 24,000 automated ones on a typical workday in Google's monorepo. So the scale isn't new either.
My read: the ideas came from people who solved this a decade ago, and since 15 October the post says so plainly. What Claude changed is the cost of rebuilding those ideas around your own infrastructure. That's a smaller claim than "Claude designed a VCS". I think it's also the more useful one.
Other pushback worth reading
- "Perforce already did this." mike_hearn, who was at Google before Piper, says commit rates there "were comparable to what Anthropic report", on "a 16 core box with a few replicas". adonovan adds that the box had "over $1m of DRAM".
- "Merges per day is a vanity metric." devin calls it "absolutely meaningless unless you know the nature of those changes." tintor noticed the chart dips on weekends, "which means people are driving at least 50% of commits."
- "I want my local history." amluto argues that Git and Jujutsu let you "build up a history entirely locally", and server-only commits give that up. The author's answer to a similar question: "Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn't important to do."
What Git already gives you
Anthropic isn't asking anyone to leave Git. It wants forges to offer server-side RPCs for history and diffs, and it wants Git's sparse and shallow features to "compose well".
GitLab answered the same day with Scaling Git for the agentic software factory. It quotes Nick G.: "We see room to expand what Git servers can do for these workloads without departing from the overall Git model." The two have been collaborating since GitLab's June event, where Nick G. joined them on stage.
On the client side, a lot already ships:
# Blobless clone: full history, file contents fetched when needed
git clone --filter=blob:none https://github.com/your-org/your-repo.git
# Only materialize the directories you work in (cone mode is the default)
git sparse-checkout set services/api packages/ui
# Or let Scalar do it: commits and trees only, a sparse checkout,
# and background maintenance. The worktree lands in your-repo/src
scalar clone https://github.com/your-org/your-repo.git
Before any of that, measure:
git rev-list --count --since=30.days.ago HEAD
Divide by 30. My own side project's two repos hold 1,273 commits on main in total, with 30 on the busiest day. At its record pace, Anthropic merges that many in about an hour. Git is not my bottleneck. HN user chris_money202 put it bluntly: "I have had zero issues using git with agentic coding."
What the headlines got wrong
The coverage ran ahead of the post in a few places:
- AI Weekly shows an "Original headline: Anthropic Open-Sources Scion". The post never says that, and AI Weekly's own body says "it will not be open-sourced".
- AlphaSignal: "Anthropic says Claude produced most of Scion's implementation". The post gives no share at all.
- SecurityOnline: CPU and memory down "to a mere 0.05% of previous levels". 200x smaller is 0.5%.
- Arize: "With traditional code review gone". The post: "Our team members still review every change request for the system".
- The Register: these problems spread "over the next few months". The post says "over the next six to 12 months".
The part that applies to everyone
The post opens with the real takeaway: at Anthropic, "coding is no longer the bottleneck". When code gets cheap, the pressure moves to whatever comes after it: review, CI, deploys. Anthropic expects this "class of problems" to become more common "over the next six to 12 months".
So if you run agents in parallel, watch your review load and your CI queue before you worry about your VCS. Scion is what that pressure looks like on a 30,401-merge day.
Drafted with AI assistance (Claude). Every quote and number links to its source.
Top comments (0)