In May 2026, Anthropic merged an average of 2,500 changes a day into its main code repository. By September the figure had passed 30,000, with a single-day high of 30,401 on September 9. The surge came from Claude, which now runs research loops on its own, optimizes complex programs and builds backend services from scratch. Tools built for human-paced work, such as Git-based source control and CI (the automated build-and-test system that runs on every change), became the company’s biggest bottleneck. In a technical write-up published October 13, Anthropic explained how a team of seven built a new version control system called Scion, plus a code review tool called Antique, and moved its monorepo off Git in five months. Any team that leans heavily on AI coding agents may eventually hit the same wall.
Why Git stopped fitting the workload
Git rests on an assumption that code is written by people, is expensive to produce and deserves careful human review. It is also decentralized. Every clone, or full local copy of a repository, stores the entire history, computes diffs on its own machine and works offline. That suits open-source projects and human-scale teams but struggles with a giant monorepo, a single repository that holds the code for many projects, when machines create and test changes around the clock.
| Measure | Size |
|---|---|
| History of the main branch | More than 100 GB |
| One compressed working copy | More than 25 GB |
| CI checkouts per day | About 25 million |
| Daily traffic if every checkout fetched everything | More than 600 PB |
A checkout pulls code out of the repository so a job can work on it, and the daily count excludes developer environments, agent sandboxes and research jobs. Anthropic tried the usual workarounds that fetch only part of a repository, such as shallow clones, sparse checkouts and blobless clones, and ran hundreds of internal Git mirror servers. As merges accelerated, the setup grew fragile. Seed snapshots for the mirrors kept falling behind the tip of the main branch, and partial clones made it costly to compute a diff or a blame, the record of which change last touched each line.
The deeper problem was a change in users. Traditional version control assumes users who are often disconnected and need to work offline. The main users of Anthropic’s source control are agents, CI bots and compute jobs, which are always online. The traits that made Git strong for distributed, offline work held it back under an automated workload. Anthropic rethought version control from first principles, drawing on large-scale systems such as Google’s Piper and Meta’s Sapling. Meta itself once overhauled Mercurial to cope with its own monorepo.

▲ The cost of copying the whole repository
The principles behind Scion
Scion reverses many of Git’s defaults:
- Servers do the heavy lifting. Servers are the authority for history, diffs, blame, merges and rebases. Clients keep only a bounded local cache and sync the working copy with changes on disk.
- Source control is an API. CI jobs and tools query commit relationships and file history remotely without downloading the repository. Anthropic’s automated bisection and revert pipelines, which hunt down and undo a bad change, isolate faults this way.
- Commits are cheap and lock-free. Because commits are incremental and take no locks, hundreds of agents can commit at once without waiting in line. Commits, rebases and merges happen directly on the server, and a commit’s cost scales with the size of the change, not the repository. Global branch pointers, which need agreement across servers, are limited to the main trunk and release branches.
- The system scales out. No server or storage node holds a full copy of the repository, and Git’s packfiles, the compressed bundles Git uses to store and ship objects, are gone.
- Local copies are optional. Working copies are sparse by default. A virtualized checkout shows files in the local file system but downloads contents only when a process reads them, so a job pays only for the bytes it uses. Jobs that just need a diff ask the API for metadata, and write jobs can submit changes without any checkout.
Changesets instead of full trees
Scion’s basic unit is the changeset, an entry in a write-ahead log, an append-only record of changes kept in order. A Git commit points to a tree describing the entire directory structure. A changeset lists only the files that changed relative to its first parent, each referenced by a content address, an ID derived from the file’s contents. Metadata such as author, committer, timestamps, message and parents lives in Google Cloud Spanner, and file contents sit in Google Cloud Storage. Scion only adds data and stores full, immutable files instead of deltas, so it needs no packfiles, distributed locks or cross-server coordination, and it avoids rebuilding files from long delta chains.
Separate author and committer fields record which person or system asked for a change and which agent actually made it. Questions a changeset cannot answer on its own, such as who last edited a line, are handled by derived data the server computes: blame structures, path histories and skip lists for walking the commit graph. Each value is defined recursively from the parent changesets, can be computed up front or on demand, and stays hidden behind the API. Anthropic can therefore add indexes such as copy detection without changing client code.
Fetching only what is needed
Instead of negotiating packfiles, the client checks its local store, requests missing tree nodes from the root down and then fetches only the file contents it needs. Small requests replace multi-gigabyte responses, so fetches can resume and cache well. Caching runs in three tiers:
- scion-daemon runs on each developer machine and CI node and serves every process on that machine.
- scion-cache serves each region, streaming objects from memory in a ready-to-write format.
- scion-server is the authoritative layer, which reads metadata from Spanner and file contents from Cloud Storage on a cache miss.
All three tiers speak the same RPC protocol, a way for one program to call functions on another machine, but strict tiering rules keep a regional cache outage from flooding the authoritative servers. Because committed data never changes, any server or cache can answer without checking with the others. Scion also rolled out in stages: it first served only as a metadata service, and the custom client and transport came later.

▲ Scion’s three-tier cache
The results
Anthropic reports a cache hit rate above 99% and a CPU and memory footprint 200 times smaller than its old Git mirroring setup. The switch freed 25% of CPU capacity in CI, and checkouts dropped from minutes to seconds.
| Operation | Git | Scion | Speedup |
|---|---|---|---|
| Pull latest code | 87 s | 3.5 s | 25x |
| Checkout | 15 s | 1.1 s | 14x |
| Status | 3.9 s | 19 ms | 207x |
| Diff | 407 ms | 67 ms | 6.1x |
| Create a new agent worktree | 7.1 min | 5.1 s | 84x |
The first three figures come from developer environments; a worktree is a separate working directory on the same repository. The time saved adds up to more than 1,000 agent-hours and roughly 175,000 machine-hours a day.
How seven people did it in five months
The seven-person team built Scion and Antique and migrated about half a dozen related internal systems while daily merged code grew tenfold. It also shipped internal code search, access management for source control and tools that land large volumes of reviewed code, plus fine-grained access rules that protect sensitive directories inside the monorepo. Migrations like this once took large departments several years.
Claude carried much of the load:
- Claude Mythos Preview rewrote a handwritten prototype of the pipeline that ingests Git history into Scion, without manual instructions. The new version used 20 times less memory and ran four times faster while keeping every implicit ordering rule.
- Claude generated hermetic simulation tests that run sealed off from outside systems, fuzzers that feed random inputs to find bugs, and rate-limiting systems, making Scion one of the most thoroughly tested codebases at Anthropic.
- Claude spotted subtle optimizations in ancestry queries that had been missing database indexes, work that would normally take performance specialists days or weeks of tuning.
What engineers still do
Anthropic says engineers remain essential, but their work has moved up to architecture: the constraints between systems and the trade-offs among them. A key part of the job is telling Claude “no” when an agent proposes something that breaks a core rule or bypasses a system. During the migration, several Claude agents tried to rebuild pull request histories by scanning Git logs instead of querying Antique. Adversarial reviews between agents also produced defensive over-engineering, with extra validation written to answer hypothetical reviewer criticisms. Human review now checks intent and architectural sense rather than syntax, and Antique applies semantic rules that let reviewers skip superficial edits.
Claude agents in dedicated Slack channels also watch the telemetry of components such as scion-daemon, scion-cache and Antique’s merge queue. Anthropic calls them “superfans” and finds them better than standard alerts at catching subtle anomalies that span logs and charts.
Merge first, verify fast
Development practices changed as well. Take merge queues, which line up changes and test them before they land. A queue that locks the whole repository while CI runs becomes an impossible bottleneck when thousands of agent changes arrive at once. Anthropic dropped it. It now accepts concurrent changes, validates them automatically after the merge and before deployment, and lets Claude resolve merge conflicts quickly.
This appears to follow a broader idea: take the risk out of the merge button. Automated checks verify a change before a human looks, while staged rollouts, canary releases to a small group of users and instant rollbacks limit the damage when something breaks. Since no pre-merge process catches every broken change, investing in fast recovery looks like the more realistic choice at agent scale.
Why Scion stays in-house
Anthropic says Scion is not a general replacement for Git. It targets massive monorepos shared by thousands of engineers and swarms of agents. Adopting it would mean abandoning Git across code review, search and build-and-deploy pipelines, and Anthropic’s internal spending on tokens, the units AI models process and bill by, far exceeds what most businesses could justify on infrastructure tools. Instead, it proposes modernizing Git on the server side with standard RPC protocols and negotiation interfaces that ordinary Git clients could use alongside GitHub and GitLab. Anthropic expects that most teams will not hit these limits right away, but that teams generating code at high volume with AI eventually will, and that the problem will become common within 6 to 12 months.
What to do now
When agents write code faster than people and tools can absorb it, the bottleneck moves from writing code to source control and CI. Scion answers with server-side computation, lock-free commits, on-demand fetching and validation after the merge. Few teams need their own Scion yet, but these steps are worth taking:
- Measure what Git costs your CI. One small startup audited its CI history and found that about 465,000 checkouts had used nearly 1,000 runner-hours, roughly 42 days of machine time, on Git setup alone, at a cost of $350 to $600 just to wait.
- Stop forcing full clones. Jobs that need only a diff or metadata can use sparse checkouts or virtual file systems to fetch just the files they read.
- Record who asked and who acted. Keep the person who requested a change separate from the agent that made it.
- Invest in recovery over gates. Favor post-merge tests, staged rollouts and fast reverts over more friction before the merge.
- Rein in agent reviewers. Tell agents not to add speculative defenses or extra validation layers, and keep human review on intent and design.
Do not replace standard tools with homegrown ones until they actually break at your scale. Still, inference costs are falling fast, and within about a year an ordinary software company may be able to build a source control layer tailored to its own workload at modest cost. Start by measuring where your own bottleneck is moving.