30,000 Merges a Day: Why Anthropic Replaced git With Scion

Anthropic published an engineering post this week that starts with an admission most companies are still avoiding: writing code stopped being their bottleneck. Agents write the code now. The bottleneck is everything built for human-scale work, source control first among them. In May 2026 the company averaged around 2,500 code changes merged per day. By September, the number passed 30,000. So they built Scion, an in-house version control system, and migrated their entire monorepo off git in five months.

The post landed at the top of Hacker News, and the discussion is worth reading alongside it, because half the thread is engineers asking the question the post dances around: isn't this just centralized version control again? Short answer from a commenter: "Feels more like perforce, but effectively, yes." The interesting part is why that trade makes sense now and did not make sense ten years ago.

The numbers that forced the move

Anthropic's main branch history alone is close to 100 GB. A compressed working copy is over 25 GB. CI, agent sandboxes, and research jobs perform around 25 million code checkouts per day, and fetched the naive git way that would be more than 600 PB of traffic daily. At peak, the team operated several hundred internal git mirrors just to keep up, and the mirrors kept falling further behind the tip of main as the merge rate climbed.

None of these numbers are normal, and the post says so plainly. Anthropic writes software with Claude far more than any other company, so they hit the walls first. But walls that get hit at 30,000 merges a day tend to show up at 3,000 a day not long after, which is the whole reason they published the design.

What Scion changes

git assumes clients are offline. Every clone carries the full history so anyone can diff, blame, and branch without a network. That assumption made git, and Scion drops it on purpose. Nearly every client at Anthropic is an agent or a CI job, online by definition, so the system is built around a server that is always reachable.

The consequences stack up fast. Commits become server-side entries in a write-ahead log: a changeset stores the files that changed relative to its first parent, plus content-addressed pointers into blob storage. There is no push step and no packfiles. Moving a branch is a compare-and-swap on a single Spanner row, and refs are discouraged outright because global state that every server must agree on is exactly what stops scaling. Blame, path history, and commit-graph lookups are derived data, computed recursively from each changeset's parents, and the client never sees the internals.

The client itself is thin by design. It keeps a bounded cache, lays out working-copy files, and asks the server for everything else. Checkouts are sparse or virtualized, so a job only materializes what it actually reads. Tools that used to clone the repo to ask it questions, like automated bisect and revert pipelines, now just call the API.

The results, per the post: every cache tier holds a hit rate above 99%, the infrastructure footprint is 200x smaller than the git mirroring setup it replaced, CI checkouts dropped from minutes to seconds, and CI alone freed up a 25% CPU capacity win.

The part Claude played

The scale is the story on the surface. The more interesting story is who wrote the system, because a team of seven built Scion, the Antique code review tool, and half a dozen related systems, then migrated to all of it in five months while merge volume grew 10x under them.

One example from the post went around the thread all day. Early in the year, engineers handwrote the first version of the git-to-Scion ingestion pipeline and thought it was good. Then an internal snapshot of Claude Mythos Preview arrived, they asked it to rewrite the whole thing with no further instructions, and the rewrite used 20x less memory and ran 4x faster while preserving the implicit invariants around ingestion ordering. The author confirmed in the HN thread that the pipeline ran for months during the split git/Scion period, so the win was not hypothetical.

The engineers' own description of their changing role is blunt. Everyone on the team now rates Claude as better at writing code than they are. What they still own is the decision layer: which constraints matter, which designs are allowed, and, in their words, telling Claude "no" when agents optimize for a pattern that should never have been allowed. They review every change to the system, but they review the intent of the change, not each line.

Even their idea of process got rebuilt. A merge queue with a global repo lock is industry standard at human scale and incoherent at agent scale, when hundreds of changes can land while your tests run. Anthropic gave up on the lock and invests in post-merge and pre-deploy testing instead. Concurrent changes do conflict, and Claude typically resolves those conflicts faster than a human could spot them.

The pushback

Two criticisms in the thread deserve to be taken seriously. The first is the SVN question: this is a centralized system with a thin client, the exact architecture the industry spent two decades moving away from. That reading is correct, and the post mostly agrees, with the argument that the distribution git offers only pays off when clients work offline. Agents never do. Whether you buy that depends on how much you trust "our clients are all online" as a permanent condition rather than a current one.

The second is skepticism about the whole framing. One commenter advised taking corporate engineering posts "with a lot of grains of salt," and that is a fair default for any post that doubles as a model demo. The numbers are specific and check out internally, but nobody outside can audit them, and Anthropic has obvious reasons to show Claude building impressive infrastructure. Treat it as a well-documented data point from the most extreme workload in the industry, not as proof your team needs this.

Also worth noting what the authors themselves rule out: Scion is not a product, not suitable as a general git replacement, and they say a public version that tries to please everyone would not be useful. What they offer the rest of the world instead is a direction: server-side RPCs for repo questions, smarter fetch negotiation, and the existing sparse and shallow features made to compose properly, ideally as standardized forge behavior.

What transfers

The transferable claim is narrow but real. git's design is a set of bets about workload: repos at human scale, clients that go offline, merges in the dozens per day. Agent-heavy teams violate all three bets, and the pressure shows up as mirrors, seeds, and bespoke workarounds long before anyone rewrites source control. blog.codecora.dev covered the output-volume side of that same curve in September in Coding agents are drowning in their own output; Scion is what the storage side of the curve looks like when one company pushes it to the limit.

Repro notes: the merge-rate, repo-size, checkout, and performance figures come from Anthropic's engineering post. HN numbers came from the Algolia API on October 14: 766 points, 760 comments, story dated October 13. The quoted replies are from users bradfa, nickg-anthropic, and vvpan in that thread.

The Anthropic post is at anthropic.com/engineering/redesigning-source-control and the discussion is on Hacker News.