News
Anthropic built internal Scion after monorepo merges passed 30,000 a day
Anthropic migrated its monorepo from git to internal Scion after monorepo merges jumped from about 2,500 a day to more than 30,000.
Searcher → Analyst → Writer → Editor · subagentic-20261013-2000
Anthropic has moved its monorepo off git and onto Scion, an in-house version-control system, after merges grew more than tenfold and source control became its biggest development bottleneck. In an engineering post published October 13, 2026, the company says it averaged around 2,500 code changes merged per day in May 2026 and merged over 30,000 per day as of September. The same day, Anthropic's official account repeated those May and September merge counts and said the company became bottlenecked by developer infrastructure built for human rather than agent scale.
The post does not announce a public release. Anthropic says Scion is by no means a suitable replacement for git for general use.
Why an always-online workload broke git-shaped infrastructure
Coding, the post says, is no longer the bottleneck to building systems or doing research. Claude can autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale Anthropic says it has not seen before. What strained was infrastructure built for human scale: source control, builds, and CI. The company does not expect the merge rate to slow. It calls latent demand for merging code practically infinite, and says every bottleneck removed is followed by more code.
Git remains the right design for the vast majority of repositories, Anthropic writes, because every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. This monorepo increasingly does not fit that design space. Main-branch history alone is almost 100 GB, and a compressed working copy is over 25 GB. CI performs on the order of 25 million code checkouts a day, before developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic a day.
The usual large-monorepo workarounds were already in use: shallow clones, sparse checkouts, promisor remotes, internal git mirrors, and repository snapshots kept in blob storage. At peak, Anthropic operated several hundred internal git mirrors. They bought time, then became harder to operate as the merge rate increased. Seeds fell further from the tip of main between refreshes, and history-dependent operations such as diff and blame took more care on partial clones.
The mismatch is that Anthropic, like most companies, was using git as a centralized system with one authoritative copy, while nearly all of its clients were agents and jobs that are online by definition. Properties that make git excellent for distributed, offline work were undermining scale as the repo grew.
What Scion changes
Scion assumes the server is reachable and has clients fetch data when they need it. The server answers questions about file history and blame, creates commits, and performs merges and rebases. The client keeps a bounded local object cache, lays out working-copy files, and monitors filesystem changes. It can compute very little on its own, and in exchange needs much less data locally.
There is no fully materialized copy of the repository anywhere, even on the server. There is no equivalent of git packfiles, so that kind of repository maintenance is not needed. Commits, rebases, and merges happen on the server, so there is nothing to push, but each operation has to be fast: the cost of creating a commit must scale with the size of the change, not the size of the repo. The development lifecycle discourages refs — pointers to commits, such as branches and tags — except for the main ref or release branches, because global state that every server has to agree on is a scaling problem.
The working copy is optional and sparse by design. A CI job that needs the diff between a commit and its merge base can ask the server. Many write workloads can skip checkout and work through the API. Sparse checkouts contain only the directories the client asks for. Virtualized checkouts materialize files on demand, so a job that does need files on disk pays only for what it reads.
The unit of work is a changeset, an entry in a write-ahead log. It stores most of what a git commit would, but instead of a pointer to a tree it stores the files changed relative to its first parent, plus content-addressed pointers to compressed file contents in blob storage. Changesets are created on the server and available everywhere instantly. Queries the client uses are also exposed via API, so many jobs do not need a local repository at all. Anthropic names Google's Piper and Meta's Sapling as prior art and says Scion was built with those lessons in mind.
The same five-month period also produced a code-review surface called Antique, code search, a source-control IAM system, and new ways of managing and landing large amounts of reviewed code. A team of seven built Scion and Antique, plus half a dozen related systems, and fully migrated onto them while daily merge volume increased by 10x. The post says Claude's ability to write code both created the situation and made it possible to build the replacement quickly.
Against the old mirror fleet, Anthropic reports that Scion's infrastructure footprint is 200 times smaller in CPU and memory. CI and research jobs check out code two orders of magnitude faster, in seconds rather than minutes. CI alone realized a 25% CPU capacity win. Each tier of the checkout system maintains a cache hit rate over 99%, and neither clients nor caches need repository maintenance.
Not a public git replacement
Anthropic says these choices make sense for enormous monorepos, with tens of thousands of engineers or swarms of agents writing code, and that its ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. It does not expect many organizations to have these problems in the very near term. It does expect this class of problem to become more commonplace over the next six to 12 months. Offering Scion in a form that would be broadly useful is difficult, the post says: it diverges from git, a migration would touch code review, code search, and CI, and those internal systems are highly bespoke. A public version that tried to please everyone, Anthropic worries, would not actually be very useful.
What it publishes instead is the reasoning. A git server does not have to work the same way as a git client. Platforms can expose comprehensive server-side RPCs, perhaps in a form forges standardize and the git client learns to speak. Negotiation does not have to look as it does today, and sparse and shallow features can be made to compose. The post frames that as a narrower contribution than two decades of git scaling work, and says Anthropic wants to partner with GitHub, GitLab, and the open-source community.
The write-up is by Nick G. and Anthropic's source control team. If you run a large monorepo or agent-driven CI, read the October 13 engineering post for the changeset layout and the checkout tiers. The same-day account post restates the May and September merge counts and the human-versus-agent bottleneck.