Dev Breakfast · 2026-10-14

Anthropic's monorepo main branch history is nearly 100 GB, the compressed working copy is still over 25 GB, with 25 million checkouts a day feeding CI — and in the end they simply stopped using git, switching to their in-house Scion, a migration that took five months. My first reaction: this pit will reach us sooner or later, so before rushing to praise how fast it is, take a look at how far your own repo is from that scale.

Those rules in .gitignore — Anthropic no longer uses git

Last time we talked about Anthropic's daily merge volume climbing to 30,000; today's piece is the follow-up they disclosed themselves: to cope with that volume, they migrated the entire monorepo off git, replacing it with their in-house Scion, and the migration took only five months. The timeline: in May 2026, about 2,500 merges per day on average; by September, more than 30,000 — a tenfold-plus increase, while the bottleneck shifted from writing code to source control, builds, and CI, the infrastructure "designed for human-scale." If you've ever typed git clone on a moderately large repo on your own machine, you know what pressure in that direction looks like.

Let's lay out the cost first. The main branch history approaches 100 GB, the compressed working copy exceeds 25 GB, and there are roughly 25 million checkouts a day feeding CI — a naive fetch would generate more than 600 PB of git traffic. They tried shallow clone, sparse checkout, promisor remotes, internal mirrors, and snapshot seeding; at peak they ran several hundred git mirrors, but as the merge rate climbed, the seeds drifted further and further from main, and history-dependent diffs and blames became increasingly hard to maintain. Scion's core changes are three: the client is always online, fetching data from the server on demand; the client keeps only a limited object cache, with all commits, merges, and reboots done server-side; and repo data is stored distributed, with no complete materialized copy anywhere and no packfiles requiring periodic maintenance. The optimizations git made for offline, distributed use turn into a liability when the clients are all always-online agents. Alongside this came the code review interface Antique, code search, and a set of source control IAM, all shipped in the same period.

A noteworthy point of comparison: source control for very large monorepos has precedent — Google's Piper and Meta's Sapling both walked this road, and Scion was built carrying that experience. Another detail is that refs are deliberately weakened: apart from main and release branches, branches and tags are discouraged, because global state requiring agreement across all servers is itself a scalability problem. For most teams, this stuff isn't applicable yet — the original post itself admits that not many organizations will hit the same problem soon — but they judge that anyone using AI coding tools will run into the same pressure point sooner or later. What's really worth remembering isn't "time to change version control systems," but that when your clients shift from humans to agents, many default assumptions made for human usage habits start to leak.

💡 Chef's take: Scion isn't worth copying right now, but that line "the bottleneck shifted from writing code to source control" is worth remembering — first look at your own team's CI and review process, and ask which step was designed for human speed.

Sources:

• Redesigning source control at Anthropic

Janas: running a 48 GB MoE on a 32 GB laptop, 62 tok/s prompt reading

An inference engine called Janas has been open-sourced. Written purely in C, it runs on CPU or GPU alike. What it does is very direct: the expert weights of a MoE model don't stay resident in memory but are streamed in from an NVMe SSD, so a laptop with 32 GB of memory can run the 48.4 GB Qwen3-Next-80B. The author's numbers are 37 tok/s for writing and 62 tok/s for prompt reading, versus 2.8 and 16 for llama.cpp on the same machine. The repo also lists comparisons for 13 Q4_K_M quantized models, claiming each one is faster than llama.cpp.

For claims like "N times faster than llama.cpp," my first reaction is to check the conditions it was measured under — single machine, single model, Q4_K_M; the 37 with speculative decoding versus 24 without the draft differ quite a bit, and change the machine or the quantization and the multiple may not hold. But the direction itself is interesting: when memory is short, rather than dropping parameters, treat the SSD as a second layer of VRAM — the cost is the latency of the first read of the experts and SSD wear. Worth pulling down and verifying for anyone who wants to run large MoE models on their own machine.

Sources:

• Janas - GitHub

One hour of audio transcribed in 13 seconds, at the cost of a 5% error rate

Someone turned Google's EmbeddingGemma 2 into speech-to-text: the audio encoder left untouched, training only a small reader that moves audio slices into the text space, picking the nearest match from roughly 229,000 English words, plus a small model to restore punctuation and capitalization. On an 8 GB M3 MacBook Air, one hour of audio is transcribed in 12.6 seconds, running entirely on the Neural Engine, with the audio never leaving the machine. The cost is stated plainly: a word error rate of about 5%, versus 2–3% for mainstream speech models. The speed is genuinely fast, but doubling the error rate means you still have to proofread the result yourself.

Sources:

• hackernews · amrrs

Anthropic builds its own source system: daily merges from 2,500 to 30,000

Anthropic said in an engineering blog post that they built their own source control management system. In May, about 2,500 code changes merged per day; by September that number grew to more than 30,000 — more than a tenfold increase. Their explanation: the original developer infrastructure was built at human scale, and it has now been blown apart and become the bottleneck.

What's worth pondering is the scale itself. 30,000 merges a day can't be written by hand; behind them must be a large number of agents submitting. In other words, the entire chain of code hosting, CI, and review is shifting from "built for humans" to "built for agents." If your pipeline is still designed to a human-cadence rhythm, you'll hit the same wall sooner or later. Don't rush to envy the number — first ask whether your review process can still make sense of these commits.

Sources:

• @AnthropicAI

After hitting the HN front page, the site was dragged down by AI crawlers

The post made it onto HN and picked up a hundred-odd upvotes, which should have been cause for celebration. But the author found the site getting slower and slower over the following days: the logs showed only a small handful of genuinely active logged-in users, while server load was absurdly high. Only once URL-path-level logging was added did the picture become clear — most requests never even fetched the news article, purely sweeping the APIs. The traffic source wasn't readers, it was crawlers. This matters to you directly: as long as your site is publicly accessible, being targeted by AI crawlers is only a matter of time. Figuring out early which paths to rate-limit and which to block outright is much cheaper than firefighting afterward.

Sources:

• hackernews · sammy0910

---

This issue selected 5 items out of 59 pieces of information from X / Hacker News / GitHub Trending over the past 24 hours (collected and written hourly throughout the day, fact-checked, and then compiled in the morning). Content is LLM-assisted, each item comes with a link to its original source, and important decisions should be cross-verified.