Git handled Anthropic’s commit volume fine in May. By September it couldn’t. In Redesigning source control at Anthropic, the company’s engineering team explains why it spent five months replacing git across its entire monorepo with an in-house system called Scion, and why it doesn’t expect to be the last company to hit this wall. The post reached the Hacker News front page and pulled over 900 comments, and the thread is where the real argument happens.
Table of Contents
- What actually broke
- What Scion does differently
- This isn’t a new idea
- The pushback: is this even necessary
- What I’d actually take from this
- FAQ
- Sources
What actually broke
The numbers tell the story on their own. In May 2026, Anthropic averaged about 2,500 code changes merged per day. By September, that number passed 30,000, and the company says it doesn’t expect the growth to slow down. The main branch’s history alone runs to almost 100GB, with a compressed working copy over 25GB, and CI performs around 25 million checkouts a day. Fetched the normal way, that’s over 600 petabytes of git traffic daily.
Anthropic didn’t jump straight to building a replacement. It tried the standard playbook first: shallow clones, sparse checkouts, promisor remotes, and, at peak, several hundred internal git mirrors just to spread the load. The mirrors bought time but became harder to run as the merge rate kept climbing.
The root issue, as Anthropic frames it, is a mismatch between git’s design and how its repo is actually used now. Git assumes clients work offline and need a full local copy. Anthropic’s clients are almost entirely agents and automated jobs that are online by definition, so the property that makes git excellent for distributed, offline work was working against the company as the repo grew.
What Scion does differently
Scion flips git’s central assumption: clients are always online, so the server does the work. In git, every clone can compute diffs, read history, and create commits on its own. In Scion, the server handles commits, merges, rebases, and history queries, while the client keeps only a bounded local cache and lays out files on disk.
A few design choices follow from that. Commits happen server-side and are available everywhere instantly, with no packfiles to accept and no local git-style repository maintenance. Checkouts are sparse and virtualized by default, so a CI job that just needs a diff between two commits can ask the server directly instead of materializing a full working copy.
One detail from the article stands out: early on, a human-written prototype of the git-to-Scion ingestion pipeline was handed to an internal preview of a newer Claude model with the instruction to rewrite it, no further guidance given. The result used 20 times less memory and ran four times faster while preserving the same ordering guarantees.
This isn’t a new idea
Anthropic is upfront about this: centralized source control for huge monorepos has prior art. Google built Piper for the same reason years ago. Meta built Sapling. Both are centralized, server-backed systems built around the same observation Anthropic landed on independently: once a monorepo and its traffic outgrow what a distributed, offline-first design can handle, you end up wanting a server that holds the truth and clients that ask it questions.
That’s the real story here, underneath the AI framing. A new kind of client (coding agents running constantly, merging tens of thousands of times a day) pushed a company into a scaling problem that giant human-scale engineering orgs had already solved, and the solution looks a lot like theirs. The trigger changed. The shape of the fix didn’t.
The pushback: is this even necessary
The strongest objection in the discussion came from a developer who argued the article doesn’t make a convincing case that git itself was technically incapable of the workload, pointing out there’s a long way between “stock git” and “build your own version control system from zero.” If you’re an investor, they asked, why would you want your engineering team spending months reinventing source control instead of shipping product.
A separate, more pointed thread of skepticism was about the 30,000-merges-a-day number itself. Commenters asked what kind of churn actually needs that volume, and whether it reflects lasting work or just the fact that, as Anthropic writes, “the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.” One commenter warned other companies will likely chase this pattern out of FOMO, assuming they need Anthropic-scale infrastructure when they don’t have Anthropic’s scale or its unusual incentives: as the post notes, its “ability to spend tokens for internal use far exceeds what any other business would realistically want to spend.”
There’s also a sharper thread about what this does to engineering as a job. One commenter quoted a line from the article: very often, the role of the engineers building Scion was to tell Claude “no.” Another developer who’s used recent Claude models agreed that’s become a real pattern: the model proposes a valid but unlikely fix for an edge case and, left unchecked, will happily triple the codebase and cut performance tenfold chasing it.
What I’d actually take from this
Anthropic says this plainly, and I’d take it seriously: Scion is not a general git replacement, and it isn’t trying to be one. It’s a fix for a specific kind of pain: a monorepo with tens of thousands of engineers and agents, checked out tens of millions of times a day, where git’s offline-first design stops paying for itself. If that’s not your workload, replacing git is almost certainly the wrong move, whatever the headlines about Anthropic’s version make it sound like.
What’s worth watching instead is the earlier signal: mirrors that get harder to keep in sync, CI that gets slower every quarter, diff and blame operations that degrade on partial clones. Anthropic ran several hundred git mirrors before it built anything new, which means the warning signs showed up long before the rewrite did. If your team is seeing the early version of that pattern, the lesson isn’t “build your own VCS.” It’s “notice the bottleneck before it becomes the whole roadmap.”
FAQ
Did Anthropic actually stop using git?
Yes, for its main monorepo. Anthropic migrated fully from git to Scion, an in-house version control system, over about five months, along with a new code review tool (Antique), code search, and a source-control access control system.
Why couldn’t Anthropic just keep using git with better tooling?
It tried. Anthropic used shallow clones, sparse checkouts, promisor remotes, and at peak ran several hundred internal git mirrors to handle the load. These bought time but became harder to operate as merge volume grew from about 2,500 to over 30,000 changes a day between May and September 2026.
Does this mean other companies should replace git too?
Almost certainly not, and Anthropic says so directly: Scion is built for huge monorepos with tens of thousands of engineers and AI agents, not as a general-purpose git replacement. Developers in the Hacker News discussion warned this kind of migration mainly makes sense at Anthropic’s unusual scale.
Sources
- Article: Redesigning source control at Anthropic, Anthropic Engineering.
- Discussion: Hacker News thread, for the counterpoints on whether this was necessary, the FOMO warning for smaller teams, and the discussion of what it means for engineers to review AI-written code at this volume.