Redesigning source control at Anthropic

TL;DR Highlight

Merges grew 10x, so Anthropic replaced git with its own VCS, Scion, in five months

Who Should Read

Infra and platform developers whose CI checkouts and monorepo size are straining as coding agents flood them with changes

Core Mechanics

Merges grew over 10x in five months
- Anthropic averaged about 2,500 merged changes per day in May 2026 and over 30,000 per day by September.
- The bottleneck is now human-scale infrastructure like source control, builds, and CI, not writing code.
Git strained under the monorepo
- The main branch history alone is almost 100 GB and a compressed working copy is over 25 GB.
- About 25 million CI checkouts per day would mean over 600 PB of naive git traffic daily.
- At peak they ran several hundred git mirrors, which got harder to operate as the merge rate rose.
Scion assumes clients are always online
- Nearly all clients are agents and jobs, so full offline copies were undermining scaling.
- The server handles commits, rebases, merges, and blame, while the client keeps a bounded local cache and lays out files.
Commits happen on the server with no push
- A changeset is a write-ahead log entry listing changed files versus the first parent, plus content-addressed blob pointers.
- No packfiles, locks, or ref moves are needed, so throughput is high.

Community Reactions

Doubts about reviewing at this speed
- One commenter said every time they stop reviewing Claude's code they later find janky code, and wondered how Anthropic avoids that.
- Another asked how 30k merges per day can be reviewed for intent and still catch shortcuts the model takes.
Pushback on whether git truly had to go
- One commenter said the article doesn't convincingly show git can't handle the workload.
- Others asked whether a monorepo was the right call, noting you can check out five repos in one directory for an agent.
- One noted that 25M checkouts for 30k merges is about 833 per merge, which seems odd.
Domain expertise still matters
- One commenter argued that generalists without source control experience wouldn't have gotten a usable result at this scale.
- Another said cheaper code will lead to more reinvented wheels, though maintenance may not get equally cheap.
Prior art and openness concerns
- One commenter recalled Oracle and Google also building their own source control systems.
- Others pointed to Meta's EdenFS and Sapling and Cloudflare's artifact-fs as similar on-demand checkout designs.

How to Apply

Measure your CI checkout cost first
- Today, pull daily checkout counts, clone time per job, and bytes fetched from your CI logs.
- Compute checkouts per merge and compare with the numbers in this post.
Replace full clones with API queries
- Pick jobs that only need diff, merge base, or blame.
- Switch them to your host's API or to shallow and sparse checkout.
Make agent workspaces sparse by default
- Set sparse checkout as the default for agent sandboxes so they fetch only the directories they need.
- This is the first step toward paying only for files actually read.
Audit merge queue assumptions and add post-merge tests
- Count how many changes pile up while tests run.
- If a global-lock queue blocks, add post-merge and pre-deploy automated tests and let agents fix conflicts.

Try It

copy & run

# Paste into Claude or ChatGPT as is (simplified version of the paper's method: diagnosing source control bottlenecks in your CI)

I run a monorepo where agent-generated code changes are growing fast.
- Merges per day: {{merges per day}}
- CI checkouts per day: {{checkouts per day}}
- History size and working copy size: {{sizes}}
- Current approach (shallow clone, mirrors, seeds, etc.): {{current approach}}

Diagnose the bottlenecks using these principles.
1. Clients are always online. Is a full clone really needed?
2. Can diff, merge base, and blame be replaced by server APIs?
3. Can checkouts shrink with sparse or fetch-only-what-you-read approaches?
4. Can we move to cacheable immutable objects?

Give me the top 3 improvements I can make in 30 minutes, in priority order.

Next to try: pick the biggest job and ask for a script that measures checkout time before and after.

Terminology

MonorepoOne repository holding all of a company's code, like one big library for every book.

ChangesetScion's unit of work: a log entry listing files changed versus the parent plus pointers to their contents.

Packfilegit's compressed bundle of objects, like packing a whole move into one squeezed box.

Derived dataIndexes computed from changesets, such as blame, path history, and commit graph skip lists. Like an index built from a book's text.

Content-addressedData identified by its content so it never changes once stored. Any cache can serve it without checking.

Sparse checkoutDownloading only some directories of a repo, like copying only the chapters you need.