# Git Breaks at Agent Scale. Anthropic’s Replacement Took Five Months and Ships to No One. > Source: > Published: 2026-10-22 13:07:44+00:00 In May 2026, Anthropic averaged roughly 2,500 code changes merged per day. By September, that figure had climbed to over 30,000 per day, a 12-fold increase in four months, according to company-reported data. That surge is a structural breaking point, and the company names what broke in its [redesigning source control](https://www.anthropic.com/research/redesigning-source-control) post: coding is no longer the bottleneck, and the constraint is the developer infrastructure built for human scale, namely source control, builds, and CI. That is the same bottleneck the [four-layer stack report](https://forkast.news/tgvp-infrastructure-not-model-quality-is-the-primary-bottleneck-to-enterprise-ai-agent-adoption/) identified: infrastructure, not model quality, limits enterprise agent adoption, across memory, execution, tooling, and governance. What breaks is git’s design assumption. Git was built for distributed, offline work, and, as the company puts it, nearly all of its clients were agents and automated jobs, online by definition: “The properties that make git excellent for distributed, offline work were actively undermining our ability to scale.” The company-reported math shows the scale: on the order of 25 million code checkouts per day for CI alone, before developer environments, agent sandboxes, and research jobs, and over 600 petabytes of git traffic per day if fetched naively. The standard workaround held for a while; at peak the company operated several hundred internal git mirrors, which “bought us time, but they became harder to operate as our merge rate increased.” The inversion that follows is simple to state: assume clients are always online, and let the server carry the work. Anthropic’s internal replacement, Scion, runs on that inversion. The server answers file history and blame, creates commits, and performs merges and rebases; the client keeps only a bounded local object cache. The unit of work is a changeset, an entry in a write-ahead log created server-side, and the company reports there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Branches and tags are deliberately discouraged, because global state every server must agree on is a scaling problem. Checkouts are sparse and virtualized, materializing files only on demand. Company-reported results: each cache tier sustains a hit rate over 99%, the infrastructure footprint is 200 times smaller than the old git mirroring setup in CPU and memory, checkouts run two orders of magnitude faster (seconds rather than minutes), and CI alone recovered a 25% CPU capacity win. The build story carries the same shift. A team of seven migrated the monorepo off git in five months while also building a code review tool, code search, source control access management, and roughly half a dozen related systems, as merge volume grew tenfold around them. An early internal snapshot of Claude Mythos Preview rewrote the hand-written git-to-Scion ingestion pipeline with no further instructions into a version that consumed 20 times less memory and ran 4 times faster, company-reported. Engineers moved up a layer: as the post puts it, “the role of the engineers was to tell Claude ‘no,’” reviewing the intent of a change rather than every line of it. This is the same division of labor this desk has watched emerge across developer tooling, where [the review ratio](https://forkast.news/google-handed-its-agent-framework-to-an-agent-the-2-of-6-review-ratio-is-the-real-story/) became the story: agents explore and generate at speed, humans decide what survives. The sharpest expression of the breaking point is what happened to the merge queue. In the post’s words: “A proper merge queue, for example, doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running?” The company could not replicate the industry-standard global repository lock on the merge queue and invested instead in post-merge and pre-deploy testing; concurrent changes can conflict, but “Claude can typically fix these conflicts faster than humans can even identify them.” None of this is for sale. Scion is internal and not open-sourced, and the company states plainly that it is “by no means a suitable replacement for git for general use,” making sense only for truly enormous monorepos with tens of thousands of engineers or swarms of agents writing code prolifically. For builders, what ships is the diagnosis and the design patterns, not the product. The company anticipates “this class of problems will become more commonplace over the next six to 12 months,” and its suggestions run to git servers with different internals, server-side RPCs exposed “perhaps even in a standardized way across forges,” and partnership with GitHub, GitLab, and the open-source community. Its own lineage is worth noting: the post credits Google’s Piper and Meta’s Sapling as prior art, both of them also internal systems that never shipped to anyone else. The pattern the [tooling layer keeps following](https://forkast.news/bifrost-and-cloudflare-both-replaced-tool-catalogs-with-code-generation-the-agent-tooling-layer-is-standardizing-on-a-pattern-nobody-named/) is that infrastructure built for agent scale is first built in-house by whoever hits the wall first, and the open question is whether the forge ecosystem standardizes the interfaces before the next swarm hits the same ceiling. Until it does, teams running agents at commit velocity are being handed a map, not a bridge.