Redesigning source control at Anthropic
Anthropic redesigned source control because agents now write code faster than review, merge and CI can absorb it.
Extract
At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.Changes merged to our monorepo per day, from January to September 2026.In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months. We also built and shipped a code review surface (called Antique), code search, a rich source control IAM system, novel ways of managing and landing large amounts of reviewed code, and more, all in that same time period. In this post, we’ll focus on how we built Scion specifically. It makes for an interesting case study: Claude’s ability to write code was both what put us in this situation in the first place and how we were able to quickly build a high-quality, scalable system to deal with it.Growing our monorepoBefore we explore what we built, we should acknowledge how unusual our workload is. Unsurprisingly, Anthropic uses Claude to write software far more than almost any other company, so we’re often the first to see where tools built for human scale start to strain. Source control is just one example of this. While we don’t expect many organizations to have these problems in the very near term, we suspect it won’t be too long before others who use AI coding tools experience these same pressure points, which is why we wanted to share what we built and what we learned.Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design, and it’s a large part of why git became the standard.As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We …
Explained
What happened
Anthropic replaced Git for its monorepo with Scion, an in-house version control system, and finished the migration in five months. The trigger was volume from AI coding agents: merged changes went from about 2,500 per day in May 2026 to over 30,000 per day by September.
The numbers that broke Git:
- Main branch history of almost 100 GB, a compressed working copy over 25 GB.
- About 25 million checkouts per day for CI alone, before developer machines, agent sandboxes and research jobs. Fetched naively that would be over 600 PB of Git traffic a day.
- They had already used every standard workaround: shallow clones, sparse checkouts, promisor remotes, repository snapshots in blob storage, and at the peak several hundred internal Git mirrors. Snapshots fell behind main, and history operations like diff and blame got harder on partial clones.
Scion is built on four principles:
- Clients are always online. Agents and jobs are online by definition, so the client fetches data on demand instead of holding the full repo.
- Client-server asymmetry. The server answers history and blame questions, creates commits and performs merges and rebases. The client keeps a bounded local object cache, writes working files and watches for changes.
- Source control as a service. Every query the client uses is also an API, so many jobs, such as automated bisect and revert pipelines, need no local checkout at all.
- Horizontal scale. Repository data is distributed and stored by content hash with tiered caches, instead of whole copies on mirror disks.
They built it with prior art in mind, notably Google's Piper and Meta's Sapling, and used their own coding model heavily to build it.
Why it works
Git's core strength is that every clone is a full, offline repository. That costs a lot of data per client, which is fine for humans with a few clones each. With millions of short-lived agent and CI clients, almost all online and touching few files, that strength turns into pure overhead.
Moving computation to the server and making storage content-addressed means identical files and trees are stored and cached once, and clients pull only the objects they touch. The trade-off is explicit: no offline independence, in exchange for far less local data and shared infrastructure.
The bigger pattern
This is a classic shift from fat client to thin client when the workload changes, the same move Google and Meta made years ago for human-scale monorepos. What is new is the cause: AI agents raising write throughput by an order of magnitude in months, so tools designed for human pace (source control, builds, CI, code review) become the bottleneck.
What it means in practice
- If you are rolling out coding agents widely, measure CI checkouts, clone sizes and merge rate now. They may grow 10x faster than headcount.
- Cheap first steps: partial clones, sparse checkouts, a shared object cache close to CI runners, and reusing warm workspaces.
- Expose repository queries (blame, history, file at revision) as an API so tools stop cloning to answer simple questions.
- Expect similar pressure on build caches, test infrastructure and review queues; content-addressed caching helps across all of them.
- Revisit design assumptions (offline, human pace) whenever the main user of a system changes from people to automated agents.