Article: Redesigning source control at Anthropic

Anthropic Engineering article on how they out grew git and built their own in-house source control called Scion.

Mononoke is apparently some prior art, see @sunshowers.io on Bluesky.

Section headers kept in order, with highlights of certain paragraphs.

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.

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.

Taking a step back, we noticed that, like most companies, we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew. So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like?

Principles for agent-scale source control

Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind. Our principles are:

(trimmed to just the label)

• Clients are always online.
• Client-server asymmetry.
• A comprehensive source control service can power many novel applications.
• Everything must be horizontally scalable.
• Commits must be cheap, incremental, and lock-free.
• The working copy is optional, and sparse by design.

Scaling Scion

A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and fetching blobs. All source control data is content-addressed, so a piece of data never changes once it’s stored, and any server can cache it without checking with the others. As a result, the servers are horizontally scalable and require little coordination. They are essentially large caches that can also compute derived data on the fly and write the results back to Spanner.

Each tier of this system maintains a cache hit rate of over 99% and does not require long-lived state, so it’s easy to scale up if needed. Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance, which simplifies the lifecycle management of our jobs.

What we learned building Scion

What we learned building and operating Scion offers some interesting lessons for what building agent-scale software could look like.

• Rapid development with a small team will become more common.
• Engineers are no less valuable, but their work is changing.
• We were able to substantially improve optimization and quality.
• We laid the groundwork for new forms of monorepo security.
• A new level of operational excellence is possible.
• We’re completely rethinking our priors.

Contributing to the wider ecosystem

My paraphrase: Scion is very custom and very large scale and wouldn’t be useful as is to other organizations, and is very tied to Anthropic systems (translation: we’re sharing all the concepts but we’re not open sourcing it)

Lastly, we want to acknowledge that the git community has spent nearly two decades scaling the platform for millions of developers. Our contribution is far narrower: sharing our early view into how agentic software development interacts with these systems, so that we can partner with GitHub, GitLab, and the OSS community to support the changing needs of developers. We’re all in it together as the software development lifecycle intersects with the AI exponential.