Git Breaks at Agent Scale. Anthropic’s Replacement Took Five Months and Ships to No One.

In May 2026, Anthropic merged about 2,500 code changes per day on average. By September, that number had risen to more than 30,000 per day, a twelvefold increase in just four months, according to data reported by the company. This rapid growth revealed a basic limit in the company’s systems. In its post about redesigning source control, Anthropic explained what went wrong: writing code was no longer the main obstacle. Instead, the systems that support developers were holding things back. These included source control, software builds, and continuous integration (CI), which automatically tests code changes. This is the same problem described in the four-layer stack report: infrastructure, rather than model quality, is limiting the use of AI agents in businesses. The four areas involved are memory, execution, tools, and governance.

The problem comes from how git was designed. Git was built to let people work across different computers, even when they are offline. But Anthropic said that almost all its git clients were agents and automated jobs, which are online by definition. The company explained: “The properties that make git excellent for distributed, offline work were actively undermining our ability to scale.” Figures reported by the company show the size of the problem. CI alone required about 25 million code checkouts per day, even before counting developer environments, agent sandboxes, and research jobs. If every checkout downloaded all the data it needed in the usual way, git traffic would exceed 600 petabytes per day. For a while, the company managed this by running several hundred internal git mirrors, which are copies of repositories kept on separate servers. But Anthropic said these “bought us time, but they became harder to operate as our merge rate increased.” The new approach turns the old model around: assume every client is always online and let the server do more of the work.

Anthropic’s internal replacement, called Scion, uses this new approach. The server handles file history and blame, creates commits, and carries out merges and rebases. Blame shows who changed particular lines of code and when. The client keeps only a limited local cache of repository data. The main unit of work is a changeset, which is an entry in a log that records changes before they are fully applied. The server creates these entries. According to the company, this design means there are no packfiles to receive, no locks or coordination between servers, and no references that need to be moved around. Branches and tags are discouraged on purpose because they create shared information that every server must agree on, making the system harder to scale. Checkouts use a sparse, virtual setup, so files are loaded only when needed. The company reports that every cache level achieves a hit rate above 99%, meaning more than 99% of requests can be served from the cache. The system uses 200 times less CPU and memory than the old git-mirroring setup. Checkouts are 100 times faster, taking seconds instead of minutes, and CI alone gained back capacity equal to 25% of its CPU use.

The company changed its build process in a similar way. A team of seven moved its main code repository, called a monorepo, from git to Scion in five months. During that time, they also built a code review tool, code search, a system for controlling access to source code, and about six other related systems. The number of merges grew tenfold while they worked. In an early internal test, Claude Mythos Preview rewrote a manually created pipeline for moving data from git into Scion without receiving any further instructions. The new version used 20 times less memory and ran four times faster, according to the company. Engineers were able to focus on higher-level decisions. As the company’s post explains, “the role of the engineers was to tell Claude ‘no,’” meaning they checked whether the changes were appropriate instead of examining every line of code. This reflects a wider pattern in developer tools that this publication has been tracking. As described in its article about the review ratio, agents quickly explore options and produce code, while people decide which work should be accepted.

The clearest example of the limits of the old system is what happened to the merge queue. As Anthropic wrote: “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 reproduce the industry’s usual approach of using a single shared lock on the repository’s merge queue. Instead, it focused on testing changes after they are merged and before they are deployed. Changes made at the same time can still clash, but Anthropic said that “Claude can typically fix these conflicts faster than humans can even identify them.” The system is not available for purchase. Scion is used internally and has not been released as open-source software. Anthropic also makes clear that it is “by no means a suitable replacement for git for general use.” It is useful only for extremely large code repositories with tens of thousands of engineers or large groups of agents producing code at high speed.

For people building software, the useful things that are available are the explanation of the problem and the design ideas, not Scion itself. Anthropic expects “this class of problems will become more commonplace over the next six to 12 months.” The company suggests using git servers with different internal designs, making server-side remote procedure calls (RPCs) available, “perhaps even in a standardized way across forges,” and working with GitHub, GitLab, and the open-source community. The post also points to earlier examples: Google’s Piper and Meta’s Sapling. Both are internal systems that were never released for others to use. As the publication has explained in its article about how the tooling layer keeps following a similar pattern, the first organizations to hit the limits of existing infrastructure tend to build their own solutions. The unanswered question is whether the companies that build and host code repositories will agree on shared ways for their systems to work together before another large group of agents reaches the same limit. Until that happens, teams running agents that create code changes at high speed are getting a guide to the problem, not a bridge across it.