---
title: "Anthropic Scion Benchmarks: 8.8x Faster CI Checkouts, 25x Faster Pulls"
description: "Anthropic replaced git with Scion for a monorepo that peaked at 30,401 merges a day. Anthropic's benchmark chart number by number, how Scion works, and git options for your own repo."
author: "Jahanzaib Ahmed"
date: 2026-10-18
category: "implementation"
readingTime: "9 min read"
tags: ["ai news", "anthropic", "scion", "git", "source control", "claude"]
canonical: https://www.jahanzaib.ai/blog/anthropic-scion-source-control
source: https://www.jahanzaib.ai
---
# Anthropic Scion Benchmarks: 8.8x Faster CI Checkouts, 25x Faster Pulls

Anthropic published a long account on October 13 of how it replaced git for its monorepo with an in house system called [Scion](https://www.anthropic.com/engineering/redesigning-source-control). Seven engineers built it and finished the migration in five months, while merged changes rose from about 2,500 a day in May 2026 to a peak day of 30,401 on September 9, with the 7 day average near 18,000. Anthropic does not claim Scion replaces git for most teams. I wanted to know which of git's assumptions stop holding when nearly every client is an agent, and what the post's own benchmark chart shows.

## Merges peaked at 30,401 in a day

30,401changes merged on September 9, the peak day on Anthropic's chart, against about 2,500 a day in May

~18,000the 7 day average at the end of that chart, by my reading of it

8.8xfaster CI checkout by median, 31 seconds down to 3.5 ([Anthropic's chart](https://www.anthropic.com/engineering/redesigning-source-control))

9.2xless source control time per change request in agent environments, 34 minutes down to 3.7

The article's text says Anthropic merged "over 30,000" changes per day as of September. Its chart shows that as one day, with the seven day average well below it. Both are real numbers, but they are not the same number, and the difference matters when you plan around them. The peak is about twelve times May's level and the average roughly seven times. Anthropic expects the climb to continue, because every bottleneck it removes lets more code through.

## Why git stopped fitting

Git is distributed by design: every clone holds the whole repository and works offline. For almost every repository that is the right design. Anthropic's main branch history alone is close to 100 GB, and a compressed working copy is over 25 GB. Multiply 25 million CI checkouts by 25 GB and you get 625 PB a day, consistent with Anthropic's figure of more than 600 PB of naive git traffic. Anthropic does not show that sum, so it is my sanity check, not its method.

The usual remedies came first: shallow clones, sparse checkouts, promisor remotes, internal mirrors (several hundred at the peak) and repository snapshots. They bought time but got harder to operate as the merge rate climbed, and snapshots drifted further from the tip of main between refreshes.

## Inside Scion: changesets, tiered caches and server side queries

Scion moves the work from the client to the server. The server answers history and blame questions and creates commits, merges and rebases. The client keeps a bounded local cache and lays files out on disk. Anthropic assumes clients are online, because nearly all are agents and jobs, so many skip the working copy altogether and ask the server for a diff.

The unit of work is a changeset, an entry in a write ahead log. It lists the files changed relative to its first parent, with content addressed pointers to the compressed contents. Accepting one needs no packfile, lock or coordination between servers. Moving a ref is a compare and swap on one Spanner row, separate from creating the changeset. Blame, path history and commit graph skip lists are "derived data", computed by one mechanism from each changeset's parents.

Checkouts go through three tiers that answer the same requests: a daemon on each node, regional caches, and the authoritative servers backed by Spanner and cloud storage. The client never tells the server what it already has. It asks only for the trees and blobs it wants, so every request names an object that never changes and any cache can answer it. Anthropic enforces the tiering so a failing regional cache cannot swamp the servers upstream, and reports a hit rate above 99% at every tier.

![Diagram of Scion's checkout path from an agent job through a node daemon, a regional cache and the server to Spanner](https://cdn.sanity.io/images/qajb7q5q/production/4a5dc6bb81538d067612f15f120189836d8df5a8-1376x768.png?w=1200&q=75&auto=format&fit=max)

_Scion's checkout path as Anthropic describes it: every tier serves the same requests, so a cache miss just moves one tier up._

## The benchmark chart, number by number

Anthropic's chart "Everyday source control commands on the monorepo" compares median times for git and its `scn` client, and the article captions it as observed improvements on native Scion repos. I read these values off the chart:

| Task | Git median | Scion median | Faster |
| --- | --- | --- | --- |
| Developer: pull latest | 87 s | 3.5 s | 25x |
| Developer: status | 3.9 s | 19 ms | 207x |
| Developer: commit | 1.4 s | 1.1 s | 1.3x |
| Agent: new worktree | 7.1 min | 5.1 s | 84x |
| Agent: pull latest | 3.0 min | 9.0 s | 20x |
| Agent: commit | 18 s | 761 ms | 24x |
| Agent: total per change request | 34 min | 3.7 min | 9.2x |
| CI job checkout | 31 s | 3.5 s | 8.8x |
| Compute job checkout | 175 s | 22 s | 8.0x |

Two things stand out. The article's text says CI and research jobs check out code "two orders of magnitude" faster, but the chart's medians for CI and compute jobs are 8.8x and 8.0x. Only the developer status check, at 207x, passes 100x, and agent worktree creation, at 84x, comes near. A developer's commit barely changes, 1.3x, while an agent's commit is 24x faster, a pattern that would fit agents that begin from a fresh checkout. Anthropic puts the saving at about 11,000 agent hours a day, 195,000 machine hours for CI and 85,000 for compute jobs. It also reports an infrastructure footprint 200x smaller than the old git mirrors by CPU and memory, and a 25% CPU capacity gain for CI.

## Scion next to Piper, Sapling and git with Scalar

Anthropic names Google's Piper and Meta's Sapling as prior art, and a footnote now credits Mononoke, the server side of Sapling, with pioneering many of Scion's techniques, in particular the Bonsai data model.

| System | Working copy | Outside use |
| --- | --- | --- |
| Git with Scalar | Partial clone with blobs fetched on demand, plus sparse checkout and background maintenance | Yes. scalar ships with Git 2.38 |
| Piper at Google | Most developers use a cloud workspace over a FUSE file system, averaging under 10 files, with no local clone | No. Google found no commercial or open source system able to handle its scale (2016 paper, excerpted) |
| Sapling at Meta | Virtual file system or sparse profiles, Git compatible client | Client open source since November 2022. The repository says the server and file system are not yet supported outside Meta |
| Scion at Anthropic | Server side commits, merges and rebases. Sparse or virtualized checkouts, and often none | Not today. Anthropic says it is difficult to offer broadly |

Google's 2016 paper put its repository at 86 TB. My reading is that Anthropic's strain comes more from changes and checkouts per day than from code size, though the post does not rank the causes.

## How the team built it with Claude

Anthropic's own explanation is that Claude produced the extra merge volume and also helped build the replacement. The team had largely hand written the first git to Scion ingestion pipeline. When it got an early internal snapshot of Claude Mythos Preview, it asked for a rewrite with no further instructions. The result used 20x less memory and ran 4x faster, with the ordering rules intact. Anthropic currently [limits its newest Mythos model, 5.1, to vetted organizations](https://www.anthropic.com/claude/mythos).

Claude also wrote simulations of every non trivial infrastructure interaction the team had met, plus fuzzing and rate limiting. Engineers still review every change request, but examine its intent instead of reading each line. Anthropic also gives each component, such as the cache or the merge queue, its own Claude to watch in a Slack channel. It calls them superfans, and they run on [Claude Tag](https://www.anthropic.com/news/introducing-claude-tag), launched in June 2026.

Anthropic still runs a merge queue, but could not replicate the standard version that locks the whole repository. It tests after merge and before deploy, accepts that concurrent changes can conflict, and says Claude can typically fix them faster than people can identify them. Scion supports permissions on individual directories, and the Antique review tool can tell a comment only change from a logic change.

## Anthropic's pitch to git platforms

Anthropic says it is difficult to offer Scion broadly and worries a public version built for everyone would not be very useful, so it shares the design and hopes git platforms adopt parts of it. Hosts could offer server side RPCs like Scion's, perhaps standardized across forges, and git's negotiation protocol and its sparse and shallow features could be made to work together.

My read: none of this helps you today, because it depends on git hosts shipping server side history and blame queries. If they do, teams stay on plain git and skip a migration.

## Gaps in Anthropic's account

-   The numbers are Anthropic's own medians, with no method given, no error rates and no cost per merge.
-   The merged change chart switches between pull requests and Antique change requests, with Antique taking over from about July. The post does not say whether the two count a change the same way.
-   Anthropic says its internal token spend far exceeds what any other business would want, so the economics do not transfer.
-   The conflict claim comes without data, and dropping the repository lock only pays if rollback is cheap. The post gives no rollback figures.
-   Every engineer on the project rates Claude better than themselves at writing code. That is self reported, by people at the company that makes it.

## What an ordinary team can take from Scion

You do not need Scion, and Anthropic says so. I have no data on this, but I expect checkout cost to show up before merge volume does. Here is the arithmetic at smaller scale, with an assumed 2 GB compressed repository and a full clone for every agent run:

| Agent runs per day | Naive clone traffic per day |
| --- | --- |
| 100 | 200 GB |
| 2,000 | 4 TB |
| 25,000 | 50 TB |

The 2 GB is my assumption, so swap in your own. Traffic is runs times repository size, so a team running agents notices a big repository sooner than one where people clone once. Git has the tools Anthropic tried first, which it says stopped being enough at its size:

```
git clone --filter=blob:none <url>
git clone --filter=tree:0 <url>
git clone --depth=1 --single-branch --branch=main <url>
scalar clone <url>
```

| Job type | Clone choice | Watch for |
| --- | --- | --- |
| Long lived build host or developer machine | Blobless | Blobs download on first checkout |
| One build, repository deleted after | Shallow or treeless | Shallow cuts history, so git log and git merge-base differ. Treeless keeps history but fetches trees on demand |
| Very large monorepo, everyday use | scalar clone | Sparse checkout is on, so some directories are absent |

The first two rows follow [GitHub's partial clone guide](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/), which warns that treeless and shallow clones make everyday development harder. The third follows the Scalar post linked above.

Start by timing your own checkout step. Then close the route out of any agent [sandbox](https://www.jahanzaib.ai/glossary/sandboxing), as [the OpenAI wiki egress case](https://www.jahanzaib.ai/blog/ai-agent-sandbox-escape-openai-wiki-egress) showed. More merged code also means more model spend, so pick [the model your agents run on](https://www.jahanzaib.ai/blog/openai-vs-claude-business-ai-agents) with [token budgets](https://www.jahanzaib.ai/blog/rippling-ai-spend-console-token-roi) in mind.

I build agent workflows for repositories and CI. Details are on my [agents page](https://www.jahanzaib.ai/agents).

## Frequently asked questions

### Can I use Anthropic Scion?

Not today. Anthropic says it is difficult to offer Scion in a broadly useful form, because adopting it means migrating the whole development lifecycle, including code review, code search and CI. It shared the design instead.

### Does Scion replace GitHub?

No. Anthropic says Scion is by no means a suitable replacement for git for general use. It describes an internal system for one very large monorepo with its own review, search and CI, not a hosting service.

### How much faster is Scion than git?

By Anthropic's chart medians, 25x for developer pulls, 84x for creating an agent worktree, 8.8x for CI checkout and 9.2x for total source control time per change request. A developer's commit is only 1.3x faster. The figures are Anthropic's own.

### Is 30,000 merges a day an average?

No. Anthropic's chart labels 30,401 as the count for one day, September 9. By my reading the 7 day average at the end of the chart is nearer 18,000, still about seven times May's level.

## Related

- [Claude Got Past a Fetch Tool's URL Limit With a Link Shortener](https://www.jahanzaib.ai/blog/claude-unintended-actions-url-shortener-fetch-tool)
- [What Google's $40B Anthropic Investment Means for n8n Workflow Automation in 2026](https://www.jahanzaib.ai/blog/google-anthropic-investment-n8n-workflow-automation-2026)
- [How to Get a Claude API Key and Cap What It Can Spend](https://www.jahanzaib.ai/blog/claude-api-key-setup-first-request)

---

Canonical HTML version: https://www.jahanzaib.ai/blog/anthropic-scion-source-control