Anthropic’s merges went from around 2,500 a day in May to more than 30,000 a day in September, and source control, which meant git, became the biggest bottleneck. In five months, a team of seven moved the monorepo off git and onto Scion, a version control system the company built itself. Anthropic’s engineering blog told the story on October 13 in “Redesigning source control at Anthropic,” which opens with a claim: “At Anthropic, coding is no longer the bottleneck to building systems or doing research.” I followed what changed, where commenters on Hacker News pushed back, and what a small team like ours can take from it.
When writing code stopped being the bottleneck
According to the post, Claude iterates on research loops on its own, micro-optimizes complex programs and builds new services from scratch. The bottleneck moved to the developer infrastructure built for human scale: source control, builds and CI. Anthropic calls the latent demand for merging code “practically infinite.” Every bottleneck it removes, it says, immediately leads to more code.
The size of the monorepo shows why git struggled. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. CI checks out code on the order of 25 million times a day, and that count leaves out developer environments, agent sandboxes and research jobs. Fetched naively with git, the post says, that would be more than 600 PB of traffic a day.
Git does have tools for working with part of a repository: shallow clones, sparse checkouts that expand only the directories you want, and promisor remotes that fetch missing objects on demand. Large monorepos also lean on standard workarounds, like internal git mirrors and repository snapshots (seeds) kept in blob storage. Anthropic used all of them, and at its peak ran several hundred internal git mirrors. Still, as merges sped up, the snapshots fell further behind the tip of main between refreshes. Keeping history-dependent operations like diff and blame working on partial clones took more and more care.
Source control for clients that are always online
Git is a decentralized system. Every clone is a complete repository, so it can compute diffs, read history and blame, and check out any revision while offline. That is the right design for most repositories, and a big part of why git became the standard. But looking back, Anthropic was using git the way most companies do: as a centralized system with one authoritative copy. Nearly all of its clients were agents and jobs, which are online by definition. The properties that make git excellent for distributed, offline work got in the way as the repo grew.
If we designed source control with the fact that agents are always online in mind from the start, what would it look like?
Anthropic, “Redesigning source control at Anthropic”
Source control for huge monorepos has prior art: Google’s Piper and Meta’s Sapling. Anthropic says it borrowed heavily from Mononoke, Sapling’s server, and its Bonsai data model. On top of that, it laid down six principles.
Clients are always online. They don’t carry the whole repository; they fetch from the server when they need something.
Client and server are asymmetric. The server answers questions about file history and blame, and creates commits, merges and rebases. The client keeps a bounded local cache, lays out the working copy and watches for file changes.
Source control is an API. Every query the client uses is also exposed as an API, so a CI job can ask who last changed a line without a local repository. Automated bisect and revert pipelines depend on that.
Everything scales horizontally. Repository data is distributed, and no fully materialized copy exists anywhere, not even on the server. With no packfiles (git’s compressed bundles of objects), there’s no repository maintenance.
Commits are cheap and lock-free. The cost of a commit has to scale with the size of the change, not the size of the repo. To keep global state small, refs (branches and tags) are discouraged except for main and release branches.
The working copy is optional and sparse by default. A CI job that needs a diff asks the server instead of checking out. When files are needed, the client fetches only the requested directories or fills files in as they’re read, so it pays only for what it reads.
Changesets instead of commits
Scion’s unit of work is a “changeset,” an entry in a write-ahead log. Where a git commit points to a whole tree, a changeset stores only the list of files that changed relative to its first parent, plus content-addressed pointers to their contents. With no packfiles to accept, no locks and no refs to move, Scion can take in changesets very quickly. Moving a ref is a separate compare-and-swap on a single Spanner row. Because a changeset records only what changed, it can’t directly answer questions like who last edited a line. So Scion builds “derived data” from changesets: blame, path history, skip lists for the commit graph. Each kind is defined recursively, computed for a changeset from its parents’ values. That made it easy to add new kinds, to choose whether to compute each one eagerly or later, and to optimize them without touching the client.
A git commit points to a root tree, and the tree reaches every file.
So any single commit is enough to rebuild the whole repository as it was.
A Scion changeset lists only the files that changed relative to its first parent.
The contents live in blob storage; the changeset holds only their addresses. Moving a ref happens separately.
Data that answers ‘who changed this line’ is built separately.
Each kind of derived data is computed recursively: the parent’s value plus this change.
Asking for what you want, not saying what you have
Checkouts work differently too. In git’s negotiation, the client tells the server what it already has, and the server computes what’s missing and sends it back as one packfile. Scion’s client, scn, only asks for what it wants. Starting from the root tree, it requests the trees it doesn’t have locally, then does the same for blobs. Every request names one object that never changes, so any cache can answer it. A scion-daemon on each node keeps objects for that node. A regional scion-cache streams them straight from memory. On a miss, a scion-server reads from Spanner or cloud storage. All three tiers answer the same RPCs, but the tiering is strictly enforced, so a failure in a regional cache can’t overwhelm the servers above it.
The results the post reports: every tier keeps a cache hit rate above 99% and holds no long-lived state, so it’s easy to scale. In CPU and memory, the footprint is 200 times smaller than the old git mirroring setup. CI and research jobs check out code two orders of magnitude faster, in seconds rather than minutes. CI alone got back 25% of its CPU capacity.
Seven people, five months
The team that built Scion and Antique, the code review tool, was seven people. Building about half a dozen related systems and finishing the migration took five months, during which daily merge volume grew tenfold. The post singles out one moment. The first version of the git-to-Scion ingestion pipeline was mostly handwritten, and the team thought it was good. Then they asked an early internal snapshot of Claude Mythos Preview to rewrite it. With no further instructions, it produced a version that used a twentieth of the memory and ran four times faster, while keeping the implicit invariants around ingestion order and data structures.
That doesn’t mean the engineers’ work went away. Every engineer on the system, the post says, now rates Claude as better at writing code than they are. What they still supplied was an understanding of how the high-level components fit together, and judgment about design tradeoffs. Agents sometimes broke core constraints to satisfy patterns that should never have been allowed. Several systems tried to find when a change merged by reading the commit log from the start instead of asking the code review tool. An adversarial review grew so suspicious of another internal service that Claude added needless validation and complexity. The team still reviews every change, but now it reads for intent rather than line by line.
Very often, we found that the role of the engineers was to tell Claude “no.”
Anthropic, “Redesigning source control at Anthropic”
Other habits built for human speed came up for review as well. What does CI even mean when hundreds or thousands of changes can merge while tests are running? The industry standard of a global repository lock on the merge queue couldn’t be replicated at this scale, so the team invested in post-merge and pre-deploy testing instead. Concurrent changes can conflict, but Claude usually fixes them before a human would even notice. The post also describes a Claude assigned to each component in its own Slack channel, watching nothing else; the team calls them “superfans.”
Where 1,012 comments pushed back
On Hacker News the post got 894 points and 1,012 comments. The thread with the most replies (199) wasn’t about Scion at all but about review. Its first comment read: “Every time I stop reviewing the code from Claude I later find janky crap,” and asked how anyone avoids that at this speed. Another asked how, reviewing 30,000 changes a day for intent only, you would notice a model taking shortcuts without reading the code.
Others asked whether the monorepo should have been questioned first: going from “a monorepo makes merging easier” to “merging is so hard we need new source control” skips the middle question, “should this really be a monorepo?” Many pointed to prior art. One called Scion a modern take on server-based systems like SVN and Perforce. A developer who had worked at Oracle and Google recalled a law named after the person who ran Oracle’s in-house source control project: “every large company will at some point write their own source control system.” Steve Klabnik of East River Source Control welcomed the post as validation. A monorepo with a large team and agents, Klabnik wrote, eventually hits git’s scaling limits; Google and Meta hit that point over a decade ago, and now lots of other companies are hitting it too.
Anthropic draws the line itself: “Scion is by no means a suitable replacement for git for general use.” The ideas only make sense for truly enormous monorepos, with tens of thousands of engineers or swarms of agents writing code. The tokens Anthropic spends internally are also far beyond what other businesses would realistically spend. One commenter predicted “an ugly phase where everybody FOMOs into thinking they need to do the same, only to realize that they’re not Anthropic/Google/etc.”
What a small team can take from it
Almost no team needs Scion. Anthropic expects this class of problem to become common in the next six to 12 months, but it suggests bringing Scion’s best ideas to git rather than leaving git’s model behind. Git already has some of the pieces: partial clones that fetch objects later as needed, sparse checkouts that expand only the directories you want, and git maintenance for background upkeep. Since Git 2.38, Microsoft’s scalar ships with Git and turns these on in one step. When I wrote this blog’s post on the AI math manuscripts, I cloned the manuscript repository without blobs and opened only the files I needed. There’s a price. GitHub’s Derrick Stolee explains that in a blobless clone, git diff and git blame download file contents the first time they run. Git’s own documentation goes further: partial clone requires that the user be online. Scion’s first principle, that clients are always online, has already crept into git a little.
# Clone without blobs (file contents); start with top-level files only
git clone --filter=blob:none --sparse https://example.com/big/monorepo.git
cd monorepo
git sparse-checkout set apps/web lib # expand only the directories you need
git maintenance start # background upkeep
git config core.fsmonitor true # file watcher (macOS, Windows)
# All of the above in one step (the working copy lands in monorepo/src)
scalar clone https://example.com/big/monorepo.gitAnthropic’s suggestions to the git ecosystem point the same way. A git server doesn’t have to work the same way a git client does. If hosting services like GitHub and GitLab exposed rich server-side RPCs like Scion’s, ideally in a standard shape, the git client could learn to talk to them. The negotiation protocol doesn’t have to stay as it is either, and git’s sparse and shallow features could be made to compose well.
Once writing code got cheap, what got expensive was the infrastructure that takes the code in, the review, and the judgment to say no. Thirty thousand merges a day is someone else’s problem, but the same current reaches small teams. The more pull requests agents open, the more often CI runs and the deeper the review queue gets. Deciding up front what to ask the server and what a person must look at is far cheaper than leaving git.