|
In September, Anthropic's monorepo took in a little over 30,000 merged changes a day. Roughly 25 million times a day, a CI job checked that same repo out. Divide one by the other and you get roughly 833 reads of the repository for every change written, and that count leaves out developer machines, agent sandboxes and research jobs.
Most coverage led with the 30,000. The ratio is the more useful number. Claude made writing code fast and plentiful. What broke was everything that reads it, and that is why Anthropic's answer was a server that answers questions rather than a faster way to copy files.
postmark: a 7-person team, five months, one migration
Anthropic built Scion, an in-house version control system, and moved its entire monorepo off git in five months. In the same window the team shipped a code review tool called Antique, code search, and an access control system for source. Seven people built Scion, Antique and about half a dozen related systems while daily merges grew roughly tenfold.
12x daily merges, May to Sept
(about 2,500 to 30,000+) |
200x smaller CPU and memory
than the git mirror fleet |
25% CPU capacity CI
got back |
fig. 1 · the daily mailbag
| item | figure | where it comes from |
| Merged changes per day (Sept) | 30,000+ | post |
| One merge every | ~2.9 s | arithmetic |
| CI checkouts per day | ~25,000,000 | post (approximate) |
| CI checkouts per second | ~289 | arithmetic |
| Checkouts per merged change | ~833 | arithmetic |
| Git traffic per day if fetched naively | 600+ PB | post (hypothetical) |
| Implied size of one naive checkout | ~24 GB | arithmetic, matches the 25 GB working copy |
| History of the main branch | ~100 GB | post |
Source: Anthropic's post. Arithmetic rows divide the post's rounded figures and are approximate.
postmark: a design for offline readers, used by readers who never go offline
Git is decentralized. Every clone is a complete repository that can diff, read history, run blame and check out any revision with no network. For most repos that is the right call, and it is a big reason git won.
Think of it as mailing every reader a copy of the whole library so they can read on a plane. Anthropic, like most companies, actually ran git around one authoritative copy, and nearly all of its readers were agents and jobs that are online by definition. If every reader sits next to the library, mailing them the library is pure overhead.
The team tried the standard workarounds first: shallow clones, sparse checkouts, promisor remotes, internal mirrors (several hundred at peak) and repo snapshots in blob storage called seeds. They bought time. But seeds drifted further from the tip of main between refreshes, and keeping diff and blame working on partial clones took more and more care.
fig. 2 · who does the work
| job | git | scion |
| Create a commit | client, then push | server, nothing to push |
| Blame, file history | client, from local history | server, also exposed as API |
| Merge, rebase | client | server |
| Data kept locally | complete copy | bounded object cache |
| Repo maintenance | packfiles to manage | none, no packfiles exist |
| Working copy | full tree by default | optional; sparse or virtualized |
Source: the "principles" section of Anthropic's post. Virtualized means files appear on disk when a process first reads them.
| route 03 | How a checkout travels |
postmark: ask for what you want, never describe what you have
Git's fetch starts with negotiation: the client tells the server what it already has, and the server computes the difference and ships a packfile. Scion flips this. The client starts at a root tree, checks its local store for missing trees, requests them one level at a time, then does the same for file contents.
Every request names one object by its content hash, and that object never changes. So any cache anywhere can answer it, nothing has to be computed per client, and a dropped transfer resumes instead of restarting a multi-gigabyte download. Sparse checkouts need no special support: the client simply never asks for the trees it does not want.
fig. 3 · the delivery route
scn client the job or agent asking your mailbox |
→ |
scion-daemon one per node, shared by every job on it; boots from a snapshot local post office |
→ |
scion-cache regional; streams objects from memory in the format the daemon stores regional sorting center |
→ |
scion-server authoritative; reads Spanner or cloud storage on a miss central depot |
| 99%+ cache hit rate at each tier |
same RPCs at every tier, so the client never needs the topology |
tiers enforced so one failed regional cache cannot flood the servers |
Source: "Scaling Scion" section of Anthropic's post. Postal labels are this newsletter's analogy.
The payoff is the 833 problem solved from the read side. CI and research jobs check out code in seconds rather than minutes, roughly 100x faster, and neither clients nor caches run repository maintenance.
postmark: a delivery slip, not a photo of the warehouse
Scion's unit of work is a changeset, an entry in a write-ahead log. A git commit points at a full tree. A changeset lists the files that changed relative to its first parent, plus content-addressed pointers to their compressed contents in blob storage.
That shape is why the server keeps up. Accepting a changeset involves no packfiles, no locks, no coordination between servers and no refs. Moving a ref, such as main, is a compare-and-swap on a single Spanner row, done separately. The team discourages refs beyond main and release branches, because global state every server must agree on is a scaling problem waiting to happen.
A slip of changes cannot answer "who last touched this line" on its own. So Scion builds derived data (blame structures, path history, skip lists over the commit graph), each type defined recursively from its parents' values. Each can be computed eagerly or deferred, and because clients never see the internals, the team keeps adding new types, like indexes for copy detection and path-based file search.
| The design rule: the cost of a commit scales with the size of the change, never the size of the repo. Anything that grows with the repo has to live in derived data, built incrementally, off the write path. |
| route 05 | The merge queue they could not keep |
postmark: green main moves from before merge to before deploy
The quietest line in the post is the one with the most consequence for anyone running agents at volume. Anthropic says it could not effectively replicate the industry standard, a global repository lock on the merge queue. Instead it invested in post-merge and pre-deploy automated testing, and accepts that concurrent changes can conflict, because Claude usually fixes those conflicts faster than a human could spot them.
The arithmetic shows why. At September's average of one merge every 2.9 seconds, a 10-minute test suite watches about 200 other changes land before it finishes. A queue that tested each change alone, one after another, behind that suite would clear about six an hour.
fig. 4 · where "main passed tests" lives
| stage | human-scale merge queue | anthropic at agent scale |
| before merge | tested against the tip, behind a lock | reviewed for intent; no global lock |
| at merge | main advances one tested change at a time | many changes land concurrently |
| after merge | little to do | automated post-merge testing |
| before deploy | release gates | automated pre-deploy testing |
| collision | caught before main | reaches main; Claude repairs it |
Source: "We're completely rethinking our priors" in Anthropic's post. The 200-merge figure is this newsletter's arithmetic on the September average.
Our reading: at agent merge rates, "main is green" stops being a property of the branch and becomes a property of the deploy gate. If your agents are pushing a merge queue toward its limit, that is the trade to plan for, not a faster queue.
| route 06 | The engineers' job was saying no |
postmark: the agents scanned the log the API was built to replace
All of the engineers on the project rate Claude as better than themselves at writing code. What they supplied was knowledge of how systems connect, and judgment about which trade-offs mattered at the scale they needed.
The best example is a small irony. Several systems tried to find out when a change merged to main by reading the commit log line by line instead of asking the code review tool. That brute-force scan is the exact pattern Scion's API exists to retire, and agents reached for it anyway. Agents, the post says, will sometimes break a core system constraint to satisfy a pattern that should never have been allowed.
fig. 5 · division of labor
| claude did | engineers did |
| Rewrote the handwritten git-to-Scion ingestion prototype (Mythos Preview snapshot): 20x less memory, 4x faster, sequencing invariants kept | Chose the problems, the scale target and the cross-system design |
| Hermetic simulations, fuzzing and rate limiting on a tight timeline | Stopped agents from bypassing the review tool with log scans |
| Found an ancestry-query optimization that missed an index | Reined in over-engineering from adversarial review (one review distrusted another internal service and added needless validation) |
| Ran "superfan" channels in Claude Tag, each watching one component's telemetry and logs | Reviewed every change request for intent rather than reading every line |
Source: "What we learned building Scion" in Anthropic's post.
| route 07 | The return address |
postmark: prior art, credited two days late
Centralized source control for huge monorepos has a lineage: Google's Piper and Meta's Sapling. On October 14, a former Meta engineer writing as Rain on sunshowers.io argued that Scion's changeset model closely tracks Mononoke, Sapling's server, and its Bonsai changesets, with the complaint framed as "The problem is attribution, not copying."
Anthropic updated the post on October 15. The updated post credits Piper and Sapling in the body, and a footnote names Mononoke and its Bonsai data model as pioneering many of the techniques Scion uses. Worth knowing if you go looking for the design: the open-source version of these ideas already exists, in Sapling's repo.
| route 08 | What to carry into your own repo |
postmark: you do not need Scion to borrow the idea
Anthropic says plainly that Scion is no general replacement for git and that a broadly useful public version would be difficult to provide. Its stated hope is narrower: git servers need not work like git clients, forges could expose server-side RPCs (perhaps standardized), and git's sparse and shallow features could compose better. Five checks follow from the post.
fig. 6 · five checks
| # | check | why it matters |
| 1 | Divide clones and fetches per day by merges per day | Tells you whether reads or writes are your real load. Anthropic's ratio was about 833. |
| 2 | List jobs that clone just to ask a question | Diff, merge base, blame and ancestry can come from a forge API. Scion's API is what made automated bisect and revert practical at scale. |
| 3 | Slice what git already lets you slice | git clone --filter=blob:none and git sparse-checkout set. Anthropic used these and they bought real time. |
| 4 | Treat refs as shared global state | Every branch is something every server must agree on. Fewer long-lived refs, fewer contention points. |
| 5 | Decide where green lives | At high merge rates the queue lock gives first. Know whether your safety net is pre-merge or pre-deploy before an agent swarm decides for you. |
Source: checks derived from Anthropic's post; git flags from the git documentation.
|
return to sender · what the post does not say
□ No cost figures for building or running Scion.
□ No split of the 30,000 daily merges between Claude and people.
□ The 25 million checkouts are stated as approximate, and the 600 PB is a naive hypothetical, so the 833 ratio is a rough scale, not a measurement.
□ No code released. Anthropic notes its internal token spend far exceeds what other businesses would choose.
□ Its expectation that others hit these limits within six to twelve months is a forecast.
|
The headline was 30,000 merges. The engineering was in the 25 million reads. Scion stopped mailing the library to every reader and started answering their questions at the counter, and if your agents read far more than they write, that is the part worth copying.
| 
