🔀
VCS · Merge · Checkout
Source Control at Agent Scale
When agents make code cheap to write, the expensive parts become merging it, checking it out and testing it. Anthropic went from about 2,500 merged changes a day in May 2026 to more than 30,000 in September, and replaced Git for its monorepo with an in house system called Scion. This is the architecture of that pressure: why Git's design fights a fleet of always online clients, what a changeset log and a query API change, how merge queues serialize work and what it costs to stop serializing, and the parts of the fix you can apply on Git today without building a version control system.
Barnabas Waweru
18 October 2026
22 min read
No. 033
Overview
In Plain Terms
Teams now run AI coding agents that write and submit code all day. This article is about what happens next: every change has to be merged into the shared codebase, downloaded by test machines and checked. When the writing gets ten times faster, those later steps become the slow, expensive part.
| Word you will see | What it means here |
|---|
| Repository | The shared folder that holds all of a project's code and its full history. |
| Monorepo | One repository that holds the code for many projects at once. |
| Merge | Adding one finished change into the main version of the code. |
| Checkout or clone | Downloading a copy of the code onto a machine so it can be built or tested. |
| CI | Continuous integration: machines that automatically build and test every change. |
| Merge queue | A waiting line that tests changes together before they are allowed into the main version. |
| Git | The most widely used tool for tracking code history. Every copy normally holds the whole history. |
Picture a team that turned on coding agents in the spring. Every engineer now runs several of them, each one opening pull requests against the same monorepo. Review keeps up for a while because the agents also review. Then the merge queue starts backing up, CI bills climb, and someone pulls the build logs and finds that a large share of every job is spent before the first test runs: cloning, fetching, checking out. Nobody wrote slower code. The repository simply became the busiest shared service in the company, and it was never designed to be a service at all.
Anthropic published its version of that story on 13 October 2026. Daily merged changes in its monorepo rose from about 2,500 in May to over 30,000 in September. The history of the main branch is almost 100 GB, a compressed working copy is over 25 GB, and CI alone performs about 25 million checkouts a day, before counting developer environments, agent sandboxes and research jobs. Fetched naively, the company estimates that would be over 600 PB of Git traffic per day. At peak it was running several hundred internal Git mirrors plus shallow clones, sparse checkouts and seeds in blob storage, and the mirrors eventually hit disk and memory limits.
So a seven person team built Scion, a server centric source control system, and a code review tool called Antique, and migrated the whole monorepo off Git in five months while daily merges grew tenfold. They report CPU and memory requirements 200 times smaller than the Git mirroring fleet it replaced and checkouts that went from minutes to seconds. They also say plainly that Scion is "by no means a suitable replacement for git for general use." The useful lesson for everyone else is not the system. It is where the bottleneck moved, and which of the ideas transfer to a team that is going to stay on Git.
📈
12x in Four Months
About 2,500 merges a day in May 2026, over 30,000 in September. That is roughly 21 merges a minute, around the clock, into one main branch.
📦
Checkout Is the Load
About 25 million CI checkouts a day against a 25 GB working copy. Writes are thousands; reads are millions.
🛰️
Clients Never Go Offline
Agents and CI jobs are always connected. Git's design point, a full offline copy on every client, stops paying for itself.
🧰
Most of It Transfers
Partial clone, cone mode sparse checkout, bundle URIs and background maintenance give a Git shop much of the read side benefit.
The Write Path Got Cheap, the Read Path Did Not
Every merged change fans out into many reads: CI jobs check it out, agents sync to it, review tools diff it. Multiply the write rate by ten and the read rate multiplies with it, but the cost of each read is still proportional to the size of the repository. Agent velocity is a read amplification problem wearing a productivity badge.
Where the Bottleneck Moved
In Plain Terms
Think of a restaurant that hired ten more cooks overnight. Food gets made faster, but the single counter where plates leave the kitchen, and the dishwasher, now set the pace. Merging and downloading code are that counter and that dishwasher. Every finished change gets downloaded hundreds of times by test machines, so the downloads are where the load really is.
A change travels through five stages between an idea and production. For most of software history the first stage dominated: a human writing the code. Agents compress that stage toward zero, and the queue forms at the next narrow point. Each stage below has a different scaling law, and only one of them scales with the number of agents you can afford.
01
Write
Scales with agent count and token budget. This is the stage agents made cheap.
02
Review
Scales with reviewer attention. Agents help, but a human still signs the risky ones.
03
Merge
Scales with how much you serialize. A global lock on main caps throughput at one validated change per CI cycle per lane.
04
Checkout
Scales with merges times consumers times repository size. This is where the bytes are.
05
Test and Deploy
Scales with CI minutes. Every minute spent fetching is a minute not spent testing.
The numbers in Anthropic's post make the arithmetic concrete. The table derives a few rates from their published figures. The derived column is simple division, not a number the post states.
| Published figure | Value | Derived rate |
|---|
| Merged changes, May 2026 | about 2,500 a day | about 1.7 a minute |
| Merged changes, September 2026 | over 30,000 a day | about 21 a minute |
| CI checkouts | about 25 million a day | about 290 a second |
| Naive Git traffic estimate | over 600 PB a day | about 24 GB per checkout, close to the 25 GB working copy |
| Checkouts per merge | 25 million / 30,000 | over 800 reads for every write |
Read Your Own Ratio First
The single most useful number in the post is the last row. If every merged change triggers hundreds of checkouts, then shaving bytes off a checkout matters far more than shaving seconds off a merge. Before you redesign anything, count your own checkouts per merge from CI logs. Most teams have never computed it, and it decides which half of this article applies to them.
Why Git's Model Fights an Agent Fleet
In Plain Terms
Git was designed like a personal library: everyone keeps a full copy of every book the project ever had, so they can read offline. An agent fleet is more like thousands of visitors who each need one page for five minutes and never go offline. Handing each of them the whole library is the waste.
Git is very good at what it was built for: decentralized development by people who may be offline, each holding a complete copy of history. Anthropic's diagnosis is that almost none of its clients look like that anymore. They are agents and jobs that are always online, live for minutes, and need one snapshot of a few directories. Each of Git's core design choices becomes a cost under that workload.
The full copy
A standard clone downloads every reachable object. Git's own partial clone documentation describes the failure mode in large repositories: clones that "can take hours (or days)" and consume more than 100 GiB of disk space, mostly for blobs and trees the user never needs. For an ephemeral CI runner that throws the copy away when the job ends, every one of those bytes is pure overhead.
Packfile negotiation
Clone and fetch work by negotiating a set of commits and having the server build a packfile. Scion's design note calls out the alternative it chose: no single packfile response measured in gigabytes, so transfers are resumable. A big pack is one indivisible response. If it fails at 90 percent, you start again.
Local history operations
In Git, log, blame and diff run against the local object store, which is why the full copy exists. Push those to a server and the client no longer needs history at all. That is the core of Scion's client and server asymmetry: the server handles history, blame, commits, merges and rebases, and the client keeps a bounded cache and lays out files.
Repository maintenance
Git repositories accumulate loose objects and small packs and need repacking. Git ships git maintenance for exactly this, and its own docs warn that full gc "can be expensive for large repositories" because it repacks every object into a single pack. Hundreds of mirrors each running maintenance is a fleet operations problem. Anthropic reports that in Scion "neither clients nor caches require repository maintenance."
| Git design assumption | Agent fleet reality | Cost when they collide |
|---|
| Clients may be offline for days | Clients are always online | Full local history is carried but rarely used |
| One long lived clone per developer | Millions of short lived checkouts | Clone cost paid again on every job |
| History queries run locally | Bisect, revert and review bots query constantly | Each bot needs a full copy to ask one question |
| Commits are made locally and pushed | Tens of thousands of writers on one branch | Push races and ref contention on main |
| Packfiles are maintained per repository | Hundreds of mirrors | Maintenance becomes a fleet job with its own outages |
Scion: Source Control as a Service
In Plain Terms
Scion turns the library inside out. The server keeps the only full copy and answers questions about it. Each machine asks for just the pages it needs, and caches nearby remember popular pages so the server rarely has to send them again. Saving a change happens on the server too, so there is nothing to upload.
Scion starts from six principles in Anthropic's post: clients are always online, the client and server are asymmetric, every query is an API, storage scales horizontally with no full copy on any server and no packfiles, commits are cheap and lock free on the server, and the working copy is optional and sparse. The architecture follows from those choices.
agent / CI job agent / CI job
│ scn client │ API only (no checkout)
▼ │
┌───────────────┐ one per node │
│ scion-daemon │ object store shared │
│ │ by every job on node │
└──────┬────────┘ │
│ same RPCs, strict tiering │
▼ ▼
┌───────────────┐ regional, streams ┌───────────────────────┐
│ scion-cache │ from memory in │ query API │
│ │ daemon disk format │ diff · merge-base · │
└──────┬────────┘ │ history · blame · blob│
│ └──────────┬────────────┘
▼ ▼
┌──────────────────────────────────────────────────────────┐
│ scion-server (authoritative) │
│ changeset log ── content addressed blobs (cloud storage) │
│ refs: compare and swap on one Spanner row │
│ derived data: blame · path history · skip lists · │
│ copy detection · path search │
└──────────────────────────────────────────────────────────┘
The changeset log
The unit of work is a changeset, an entry in a write ahead log. A Git commit points to a full tree. A Scion changeset lists only the files changed relative to its first parent, with content addressed pointers to compressed blobs in storage. Changesets are created on the server, so there is nothing to push, and the post says the cost of a commit scales with the size of the change rather than the size of the repository.
Refs as one row
Moving a branch is a compare and swap on a single Spanner row, deliberately separate from creating the changeset. Writing content never contends with anything. Only the pointer update does, and that is a single row operation. The post discourages refs other than main and release branches, which keeps the contended surface small.
Derived data
Blame, path history, commit graph skip lists, copy detection and path search indices are all computed from changesets through one recursive mechanism. Each type can be computed eagerly or deferred, and the client never sees how. This is the piece that lets the client stay thin: history questions become server queries backed by indexes, rather than walks over a local object graph.
Checkout by tree walk
The scn client starts from a root tree, requests missing trees recursively, then fetches blobs. Sparse and virtualized checkouts need no special support, because a client that does not ask for a tree never receives it. The three tiers answer identical RPCs, but tiering is strictly enforced to isolate failure domains, and Anthropic reports a cache hit rate above 99 percent at every tier with no tier needing long lived state.
Why Immutable Objects Make the Cache Tiers Cheap
Every object is immutable and content addressed, so a cache entry can never be stale: the same key always means the same bytes. That removes invalidation from the cache design entirely. The only mutable state in the system is the ref row, and it never leaves the authoritative tier. Compare that with a Git mirror, which must track a moving set of refs and repack as they move. Push mutability into one row and everything else becomes a CDN problem.
The query API
Servers answer diffs, merge base lookups, history, blame and blob fetches directly. Many jobs never need a working copy at all: an automated bisect or revert pipeline asks questions and writes through the API. The post lists this as a design principle, source control as a service, and it is the idea with the widest reach, because it removes the checkout from workloads that only needed an answer.
The Migration Cost Is the Whole Toolchain
Scion "diverges significantly from git," in the post's words, so adopting it meant moving code review, code search and CI too. Anthropic built a Git to Scion ingestion pipeline, a code review tool, code search and a source control IAM system. That scope is the honest price of the 200x figure, and it is why the post frames Scion as design thinking for Git platforms to borrow, not a product to install.
The Merge Queue Without a Global Lock
A merge queue exists to keep main green when many changes land at once. Two changes can each pass CI on their own and still break main together. The queue prevents that by testing each change against everything ahead of it before it lands. That safety has a price: serialization.
GitHub merge queue
Each queued pull request is combined with the latest base branch and the pull requests ahead of it into a merge_group, and the queue runs first in, first out. Build concurrency sets how many merge_group webhooks are dispatched, "between 1 and 100." The minimum and maximum group sizes are each configurable between 1 and 100. A pull request leaves the queue if its group fails required checks, conflicts with the base branch, or times out waiting for CI. CI must trigger on the merge_group event, or the required check is never reported and the merge fails. Moving a pull request to the top of the queue triggers a full rebuild of every pull request already in progress.
GitLab merge trains
Each merge request in a train runs a pipeline on its own changes plus every merge request ahead of it plus the target branch, in parallel. A train runs up to 20 pipelines in parallel by default, configurable per project with a minimum of 1. When one fails, it is removed, its earlier neighbors keep running, and every pipeline behind it is canceled and rebuilt without its changes.
Anthropic's choice: drop the lock
The post says Anthropic has not been able to replicate the industry standard global lock on the merge queue at its volume. It relies instead on post merge and pre deploy automated testing. Concurrent changes can conflict, and the post's answer is that Claude can usually fix conflicts faster than humans can find them. Main is allowed to be briefly wrong; production is not.
| Strategy | Main stays green? | Throughput limit | Failure cost |
|---|
| Merge directly after per PR CI | No, semantic conflicts land | None from the queue | Broken main, found by the next person |
| Serial queue, one at a time | Yes | One change per CI duration | Low, but the queue is the bottleneck |
| Speculative groups (GitHub queue, GitLab trains) | Yes | Concurrency limit times group size | A failure cancels and rebuilds everything behind it |
| No lock, test after merge and before deploy (Scion) | Briefly no | Write path only | Conflicts fixed forward, deploy gate carries the safety |
Speculation Amplifies Failure at High Rates
Speculative queues are excellent when failures are rare. At high merge rates with agent written changes, a single flaky or broken change near the front cancels and rebuilds every group behind it. A GitLab train can have 20 pipelines in flight, so one failure can discard up to 19 runs. If your failure rate climbs with your merge rate, the queue's waste climbs faster than either. That is the pressure that pushed Anthropic toward fixing forward behind a deploy gate.
In Plain Terms
A merge queue is a line at a single door. Everyone waits so that nobody trips over anyone else. Speculative queues let several people through at once, but if one trips, everyone behind them goes back to the end of the line. Anthropic took the door off and put the guard at the exit instead: the deploy step checks that nothing is broken before anything reaches users.
The Git Playbook: What Transfers Today
In Plain Terms
You do not need to build anything like Scion to get most of the benefit. Git can already be told three things: do not download file contents until I need them, only lay out the folders I name, and fetch the bulk of the data from a nearby file server first. Keeping one ready copy on each test machine does much of the rest.
You probably do not have 30,000 merges a day, and you should not build a version control system. But the ideas behind Scion map onto features Git already ships. Applied in order, they cut most of the read side cost for an agent fleet without changing your forge.
01
Blobless clones
Partial clone with --filter=blob:none skips file contents until a command needs them. The client becomes on demand, like Scion's.
02
Cone mode sparse checkout
Lay out only the directories a job needs. Cone mode uses hash based matching instead of O(N*M) pattern checks.
03
Bundles from a CDN
Bundle URIs bootstrap a clone from static files so the origin serves only the recent delta.
04
One cache per node
Keep a warm repository on each runner host and share it across jobs, the way scion-daemon does.
05
Answer without checkout
Move bots that only need diffs or history to your forge's API instead of cloning.
Partial clone, and its sharp edge
Git's documentation describes partial clone as avoiding unneeded objects "in advance" so they can be "demand fetched" later from a promisor remote. checkout fetches all the blobs it is missing in a single batch, which is the common path for CI. The sharp edge is history commands. The same page warns that dynamic fetching starts a separate fetch process for each missing object, which can mean "significant overhead" and repeated authentication. A bot that runs git log -p or blame across old commits in a blobless clone can turn one command into thousands of round trips. That is exactly the workload Scion moved to server side queries.
Sparse checkout and the sparse index
Git now treats non cone mode as deprecated and says to switch to cone mode, because arbitrary patterns make worktree updates "require O(N*M) pattern matches." Cone mode lets Git switch to faster hash based matching. The sparse index shrinks the index itself to match the cone, with "significant performance advantages for commands such as git status or git add," but the docs still call it experimental and warn that external tools and older Git versions may not understand it.
Scalar as a preset
Git ships scalar, "a repository management tool that optimizes Git for use in large repositories." Its clone fetches only commit and tree objects by default, enables sparse checkout, and registers background maintenance. If you want the playbook as one command for long lived developer or agent machines, start there.
Bundle URIs for CI farms
Bundle URIs exist for exactly this workload. Git's design document names the goal: allow "heavy users, such as CI build farms, to use local resources for the majority of Git data and thereby reducing the load on the origin server." Bundles are static files, so they can sit on a CDN or in object storage next to your runners, and the origin fills in only what changed since the bundle was made. The server stays authoritative: "The remote Git server is the ultimate source of truth, not the bundle URI."
ci · fast checkout on git
# CI job: blobless clone, bootstrap from a bundle, lay out one cone
git clone --filter=blob:none --no-checkout \
--bundle-uri=https://bundles.example.internal/mono/list \
https://git.example.internal/mono.git work
cd work
git sparse-checkout set --cone services/payments libs/shared
git checkout "$COMMIT_SHA"
# Long lived runner host: one warm repo, kept fresh in the background
git maintenance register # hourly prefetch and commit-graph,
# daily loose-objects and incremental-repack
# Bots that only need answers: ask the forge API, do not clone
# e.g. compare two commits or fetch one file through the REST API
Hosts and server versions differ in which of these they support. Bundle advertisement and blob filtering both require server side support, so confirm with your forge before rolling this out.
Background maintenance on warm hosts
git maintenance with its default incremental strategy runs prefetch and commit-graph hourly, loose-objects and incremental-repack daily, and pack-refs weekly, with full gc disabled. Prefetch fetches into refs/prefetch/ without disturbing remote tracking branches, so a job that starts on a warm host finds most objects already local. For large repositories the docs recommend the geometric strategy as "a full replacement for the gc strategy."
| Scion idea | Closest Git feature | What you still do not get |
|---|
| On demand client | Partial clone, blob:none | History commands fault objects in one at a time |
| Fetch only wanted trees | Cone mode sparse checkout, sparse index | Sparse index is still experimental |
| Regional cache tier | Bundle URIs on a CDN | Bundles age between refreshes |
| Per node daemon | Warm repo per runner host plus maintenance | Mostly equivalent for CI |
| Query API | Forge REST and GraphQL APIs | No standard server side blame or history RPC across forges |
| Lock free server commits | None | Pushes still race on refs |
Lineage: Piper, Sapling, Scion
In Plain Terms
Google, Meta and now Anthropic each hit the same wall at different sizes, and each reached the same answer: keep the history on servers and let machines fetch only what they need. What is new in 2026 is that the pressure comes from agents, not from adding more engineers.
Scion is the newest member of a family. Very large monorepos have repeatedly converged on the same move: put history on the server and make the client lazy. What changed in 2026 is who the clients are.
Google's Piper
Google described its monolithic repository in Communications of the ACM in 2016 as "a common source of truth for tens of thousands of developers around the world," served by a custom repository rather than Git. The scale driver was people. This article relies only on the paper's abstract.
Meta's Sapling
Meta open sourced the Sapling client in November 2022, describing it as a new Git compatible source control client. Its server and virtual filesystem make "it look and act as if you have the entire repository," and its Segmented Changelog lets clients download the high level shape of the commit graph in "just a few megabytes" and fill in details lazily, so "cloning the repository downloads almost no history." Meta describes its internal repository as having "tens of millions of files, tens of millions of commits, and tens of millions of branches." Many of these features need the Sapling specific server.
Anthropic's Scion
Scion keeps the lazy client and the server side history, then adds two things the earlier systems did not need to optimize for: commits made entirely on the server, and an explicit refusal to serialize merges. Both follow from writers that are mostly agents. The driver is no longer the number of engineers. It is the number of changes per engineer.
| Piper (2016 paper) | Sapling (2022) | Scion (2026) |
|---|
| Scale driver | Tens of thousands of developers | Tens of millions of files and commits | Agent merge rate, 30,000+ a day |
| History lives | Server | Server, lazily mirrored by the client | Server, exposed as a query API |
| Git compatibility | Not Git | Git compatible client | Diverges significantly from Git |
| Public availability | Internal | Client open source | Design write up only |
Failure Modes and Operational Concerns
In Plain Terms
Every shortcut above trades having everything on the machine for asking the network. When the network or the server is unwell, those requests fail. The three to plan for: the server being unreachable, a tool that asks for thousands of old files one at a time, and a broken change that forces the merge queue to start over.
Every technique above trades local completeness for a network dependency. That is the right trade for always online clients, and it moves your failure modes from disk to network. Plan for them.
| Failure | What you see | Mitigation |
|---|
| Promisor remote unavailable | Any command touching a missing blob fails | Git's docs say partial clone "requires that the user be online." Keep warm caches close to runners and alert on origin errors. |
| Lazy fetch storm | A history bot opens thousands of connections | Bulk prefetch with rev-list --missing=print, or move history questions to a server API |
| Stale bundles | Clones download a large delta from origin | Refresh bundles on a schedule; the docs warn a client 30 days behind redownloads a lot of data |
| Queue rebuild cascade | CI spend spikes, merges slow down | Quarantine flaky checks, limit queue jumping, watch rebuilds per merge |
Missing merge_group trigger | Queued PRs never merge | Add the event to every required workflow before enabling the queue |
| Conflicts landing on main | Main red between merge and fix | Only acceptable with a hard pre deploy gate and fast automated fix forward |
| Sparse index incompatibility | External tools misread the index | Pin Git versions on runners; disable with --no-sparse-index if a tool breaks |
| Cache tier outage (Scion style) | Fallback load hits the authoritative tier | Strict tiering as failure isolation, as Scion enforces, plus admission control at the origin |
Agents Also Generate Bad Source Control Patterns
Anthropic notes that engineers still had to say no to agent generated patterns that violated system constraints, such as scanning commit logs instead of querying the code review tool. Agents will happily clone the whole repository to answer one question. Give them a query path and make it the easiest thing to call, or the read amplification comes back through the side door.
Cost Reality Check
In Plain Terms
Test machines are rented by the minute, and the meter runs while code is downloading, not only while tests run. A faster download is a cheaper build, and the saving grows with every change your agents submit.
GitHub publishes per minute rates for hosted runners: $0.006 a minute for a Linux 2 core x64 runner, $0.005 for arm64, $0.010 for Windows, $0.062 for macOS, and $0.012, $0.022 and $0.042 for Linux 4, 8 and 16 core x64. GitHub rounds each job up to the nearest whole minute. Checkout time is billed at the same rate as test time, so every minute of fetching is a minute of CI you pay for and get nothing from.
The table is an illustration, not a benchmark. It assumes a team whose agents land 300 changes a day, each triggering 10 CI jobs, on Linux 2 core runners, and compares a three minute full clone with a thirty second blobless sparse checkout. Plug in your own counts.
| Scenario | Jobs a day | Checkout minutes a day | Checkout cost a day | A 30 day month |
|---|
| Full clone, 3 minutes | 3,000 | 9,000 | $54 | $1,620 |
| Blobless sparse, 30 seconds | 3,000 | 1,500 | $9 | $270 |
| Same, on Linux 8 core runners | 3,000 | 1,500 | $33 | $990 |
// Where the Money Actually Hides
Thirty seconds of checkout still costs a whole billed minute when it is the only thing in a short job, because of per job rounding. Small jobs are where checkout dominates the bill.
Bigger runners make checkouts cost more, not less, because network transfer does not get faster with more cores. If you moved to 8 core runners for tests, the fetch phase is now billed at $0.022 a minute.
Scale the merge rate by ten and every row scales by ten. That is the curve Anthropic was on, and why a 25 percent CI CPU capacity win is the figure in their post that a finance team would notice.
Measure Before You Build
In Plain Terms
Before changing anything, count. These six numbers tell you whether your problem is downloads, waiting in line, or changes that break the main version.
Anthropic's own recommendation is aimed at platforms, not users: server architectures that scale without changing the Git client, server side RPCs for queries possibly standardized across forges, new negotiation protocols, and sparse and shallow features that compose. For a team using a forge, the job is to know which stage is your bottleneck before you spend on it.
🔁
Checkouts per Merge
CI checkouts divided by merged changes. Above a few dozen, invest in the read path first.
⏳
Queue Wait p95
Time from enqueue to merge. Rising wait with flat CI duration means serialization is the limit.
🧮
Minutes Before First Test
Clone, fetch and checkout time per job. This is the line item the playbook shrinks.
♻️
Rebuilds per Merge
Speculative pipelines discarded per landed change. A rising ratio means failures are eating the queue.
💥
Post Merge Breakage
How often main goes red and how long it stays red. This is the number that must stay low before you relax the lock.
🗂️
Bytes per Checkout
Transferred bytes, not repository size. The gap between them is what partial clone and sparse checkout recover.
Where the Sources Disagree
GitHub's temporary branch names
GitHub's merge queue documentation tells third party CI to run on pushes to branches beginning with gh-readonly-queue/{base_branch}, while examples on the same page use names like main/pr-1. This article follows the stated prefix, because that is the rule CI filters are written against. Check the branch names your own queue actually creates before writing a filter.
Is the bundle URI design implemented?
The bundle URI document describes itself as an aspirational design submitted with an implementation plan, while the page header lists it as updated in Git 2.50.0, and the client --bundle-uri flag exists. The article treats client side bundle fetching as available and server advertisement as host dependent. Verify against your Git and forge versions.
Company reported figures
Every Scion number in this article comes from Anthropic's own post: the merge rates, the 600 PB estimate, the 200x footprint reduction, the two orders of magnitude checkout speedup and the 99 percent cache hit rates. None has been independently measured. The post was updated on 15 October 2026 after its 13 October publication; this article reflects the updated version.
Key Takeaways
Principles
- Agents move the bottleneck downstream. When writing code is cheap, merge, checkout and CI become the constrained stages.
- Count reads per write. Anthropic's figures imply over 800 checkouts per merge. Your ratio decides whether to fix the read path or the merge path.
- Always online clients do not need full copies. Lazy clients plus server side history is the move Piper, Sapling and Scion all made.
- Keep mutability in one place. Immutable, content addressed objects cache anywhere; only the ref update needs coordination.
- Give bots a query path. Diffs, history and blame through an API remove checkouts from jobs that only needed an answer.
- Speculative queues amplify failure. At high merge rates a single bad change rebuilds everything behind it. Watch rebuilds per merge.
- Relaxing the lock moves safety to the deploy gate. Fixing forward on main is only sound with a hard pre deploy check.
- Most of the read side win is available on Git. Blobless clones, cone mode sparse checkout, bundle URIs and warm hosts, in that order.
- Do not build a VCS. Scion's own authors say it is not a general Git replacement. Borrow the ideas, measure the stages, and push your forge for server side queries.
