In May 2026 Anthropic merged around 2,500 changes a day into its main branch. By September it was over 30,000. Anthropic writes software with Claude more than almost any other company, and the tightest bottleneck in development turned out to be git. Today the source control team published how they replaced git with their own system, Scion. In practice it is a git alternative for AI agents, designed for agent traffic first and people second.
Below, briefly: why git stopped coping, how the new system works, what they gave up, and what applies to a normal project with two or three agents instead of thousands. I am writing as someone with several repositories, each with coding agents working in it. I do not need Scion. Some of its ideas I need already.
Why Anthropic needed a git alternative#
The scale, from the post. The main branch history alone is almost 100 GB, and a compressed working copy is over 25 GB. CI by itself does on the order of 25 million checkouts a day. Fetched naively, that would be more than 600 PB of git traffic a day.
They tried the standard tricks for git at scale: shallow and sparse clones, partial clones, prepared seeds in blob storage. At the peak they ran several hundred internal git mirrors. As merges grew, the mirrors got harder to operate, and the seeds drifted further from the tip of main.
Their key observation: git was built for distributed, offline work, where everyone holds a full copy of history. Their clients are agents and CI jobs that are always online. They were already using git as a centralized system, and its distributed design was in the way.
How Scion source control works#
Scion assumes the client is always online. The rest follows from that.
- The server does the heavy work. History, blame, commits, merges and rebases are computed on the server. The client keeps a bounded object cache, lays out files and watches the filesystem.
- A changeset instead of a commit. The unit of work is an entry in a write-ahead log. A changeset does not point to a full tree; it lists the files changed relative to the first parent. It is created on the server, so there is nothing to push.
- Moving a branch is one atomic operation. A ref update is a compare-and-swap on a single Spanner row, separate from creating changesets. They avoid refs beyond
mainand release branches, because global state does not scale. - The client asks only for what is missing. In git, the client tells the server what it already has. In Scion the client starts from a root tree and requests only the trees and blobs it lacks. Objects are immutable, so any cache can serve them.
- Three serving tiers.
scion-daemonon each machine, a regional in-memoryscion-cache, andscion-serveron top of Spanner and cloud storage. They all speak the same protocol, but the tiers are isolated, so a failing regional cache cannot flood the servers. - A working copy is optional. Many CI jobs need no checkout at all and use the API. When a copy is needed, it is sparse or virtual: a file lands on disk only when something reads it.
None of this is new as an idea, and the authors say so. Monorepo source control at this size has prior art in Google's Piper and Meta's Sapling, so the familiar "Google Piper vs git" debate applies here too. What is new is the load: the clients are agents, and there are orders of magnitude more of them than people.
The results in numbers#
| Metric | Value |
|---|---|
| Merges per day | ~2,500 in May → 30,000+ in September |
| Infrastructure vs git mirrors | 200x smaller |
| CI checkout | seconds instead of minutes |
| CI CPU | 25% freed up |
| Cache hit rate per tier | over 99% |
| Team and timeline | 7 people, 5 months |
Seven people built Scion, the Antique code review tool, code search, an access control system and several related services in five months. The migration happened while merge volume grew tenfold. They built it with Claude: the team hand-wrote a prototype of the git-to-Scion ingestion pipeline, and an early Claude Mythos Preview snapshot rewrote it to use 20x less memory and run 4x faster.
What they gave up#
For me this is the most useful part of the post.
It is not a git replacement#
The authors say plainly that Scion is not suitable as git for general use. Adopting it meant replacing code review, search and CI. They do not plan to offer it outside: the internal tools are too bespoke.
History follows the mainline only#
A changeset stores changes relative to the first parent. Blame and path history are optimized for main. That only works with trunk-based development.
No global merge queue lock#
At this rate they could not reproduce the industry-standard global lock on the merge queue. Instead they rely on testing after merge and before deploy. Concurrent changes sometimes conflict, and Claude usually fixes the conflict faster than a person would notice it. That is the main signal for me: the merge queue was designed for human pace, and with agents it may be easier to replace it with a different scheme than to scale it.
The engineer's job: telling Claude "no"#
According to the authors, people still set the architecture and the trade-offs. Most often their job came down to telling the agent "no". Examples from the post: an agent brute-forcing commit history instead of asking the code review tool, and an agent piling on defensive checks after adversarial review.
Reviewers look at the intent of a change rather than every line. Production is watched by separate Claude instances, one per component, which they call "superfans". They read telemetry and logs and catch what static alerts miss.
What to borrow: git at scale with agents, without Scion#
My scale is different: a few websites and apps, one or two agents in each. Three ideas from Scion still work on plain git.
1. Don't clone what you don't need. Partial clone and sparse checkout have been in git for years, and an agent rarely needs full history. This is the cheapest fix for git large repository performance:
git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/ios packages/sharedFor big repositories there is scalar clone, shipped with git since 2.38, which turns these settings and background maintenance on at once.
2. Give each agent its own working tree. Today an agent shipped a fix to meteohealth.pro, where my working branch had an unpushed commit. It did not touch that branch and made a separate worktree from origin/main instead:
git worktree add -b fix-key ../site-main origin/main
git -C ../site-main push origin fix-key:main
git worktree remove ../site-mainIt is the local version of Scion's cheap, optional working copy.
3. Make the checks automatic and run them before merge. I have no global lock; a pre-push hook plays that role. On meteohealth.pro it runs type checks, a translation check and the header layout across 108 combinations of languages and widths. An agent cannot talk its way past it. People are left to judge the intent of the change, as at Anthropic.
What I would not copy: dropping branches and first-parent-only history. That is a sensible price at 30,000 merges a day. At thirty merges a week it buys nothing.
What the post doesn't cover#
- Source code, or even a description of the
scnclient API. You cannot rebuild the system from the post, and the authors do not expect you to. - A comparison against other approaches on the same load. The "200x" and "seconds instead of minutes" figures are measured against their own git mirror setup. Nobody compared it with Piper or Sapling.
- When the rest of us will need this. The authors expect this class of problems to become common within 6 to 12 months and want to share ideas with GitHub, GitLab and the open source community. Which server-side RPCs and sparse or shallow modes they will propose is not known yet.
If you run a git monorepo and your agents are starting to outnumber your people, check the three items above before you hit the mirror stage. How to give agents shared memory about a project is covered in my article on a wiki for coding agents over MCP. How several agents split work without conflicts is in the piece on agent claims in a shared wiki.
