Scion: What Source Control Looks Like at Agent Scale
When software agents can propose and revise code continuously, the familiar act of getting a repository becomes an infrastructure problem. A human developer might clone a project once and keep it for months. An ephemeral CI job or agent sandbox can start from scratch, run briefly, and disappear. Multiply that pattern by millions of jobs and the cost of transporting and maintaining repository history can dominate the work those jobs were meant to do.
Anthropic reached that point in 2026. Its engineering team reports that daily merged changes rose from roughly 2,500 in May to more than 30,000 by September. Its main-branch Git history approached 100 GB, while a compressed working copy exceeded 25 GB. CI alone performed about 25 million checkouts a day. At that rate, naively transferring a full working copy would imply more than 600 PB of daily traffic. The numbers describe an unusual workload, but they expose a general mismatch: a short-lived online worker rarely needs an entire repository’s history merely to read a few files.
The team built Scion, an internal source-control system, and migrated its monorepo in five months. The interesting story is not simply that it replaced Git. It is how the system moves responsibility from every client into a service, then makes each requested piece of repository data cheap to find and cache. This article walks through that design, its results, and the costs that come with it.
Why Git’s strengths became expensive
Git gives each full clone a self-contained repository. A client can inspect commits, calculate diffs, find a merge base, or work offline without asking a central service. Those properties are valuable for ordinary repositories and developers who need local autonomy. Anthropic’s fleet had different needs: most clients were online jobs, agent sandboxes, and research processes with short lifetimes. They wanted current files or an answer about history, not a durable independent copy of the whole project.
The company had already used Git’s scaling tools: shallow and sparse clones, promisor remotes, mirrors, and snapshots stored in blob storage. At peak, it operated several hundred internal mirrors. A snapshot could make a fresh checkout faster, but it aged behind the rapidly advancing main branch. Partial histories also made operations such as blame and diff harder to keep reliable. Each workaround helped one part of the workload while leaving a distributed repository protocol underneath.
Scion begins with a different contract. The server is reachable, authoritative, and responsible for operations that Git clients normally perform locally: creating commits, merging, rebasing, querying ancestry, calculating diffs, and answering blame questions. The client keeps a bounded object cache, watches the filesystem, and lays out the requested files. This gives up offline self-sufficiency to reduce the data and work carried by each client.
Changesets first, indexes when needed
Scion’s basic unit is a changeset written to a server-side write-ahead log. Like a Git commit, it records a piece of work and its parent relationship. Unlike a Git commit, which points to a tree describing the repository snapshot, a Scion changeset lists files changed relative to its first parent. File contents are compressed, stored as content-addressed blobs, and referenced from the changeset. Once accepted, the changeset is available to the system without a separate push.
That shape is tailored to a high rate of small changes. Creating a changeset need not rebuild a whole-repository view or update a global branch pointer as part of the write. Scion supports refs, but most work does not depend on creating or fetching them. Moving a ref is a separate compare-and-swap operation on a Spanner row. Main and release refs remain useful; making a new global ref for every unit of agent work would add coordination pressure.
An append-only list of changed files is fast to accept, but it is not enough for every read. To answer “who last changed this line?” or “which commits touched this path?”, the service builds derived data: path history, blame structures, commit-graph skip lists, and other indexes. Each derived value for a changeset is computed from its parents’ values. An index can be generated eagerly when reads justify it or deferred until someone needs it. Anthropic says it has added indexes for copy detection and path-based file search as needs emerged.
This split matters. The write path records the irreducible change; read-optimized structures can evolve separately. The server can change those structures without asking every client to upgrade its repository format. It also means the operators own the complexity of building, storing, and repairing indexes. Scion is a source-control service, not a simple file store.
Checkout as a sequence of object requests
Getting files onto disk is the most data-heavy part of the design. Scion does not negotiate a large Git packfile by describing what the client already has. The client starts at a root tree, checks its local store for missing tree objects, requests those exact immutable objects, and then asks for the blobs it needs. It can stop at directories outside a sparse checkout. With a virtualized checkout, it can wait to materialize file contents until a process actually reads them.
Each request names an immutable object. That is a useful cache key: a cache can return the object without checking whether it has changed, because a changed object would have a different content address. Requests are also resumable. Losing one response does not require restarting a single huge packfile transfer.
The path through Anthropic’s fleet has several layers. A local scion-daemon stores objects shared by jobs on the same machine. It starts from a refreshed snapshot and asks a regional scion-cache for misses. Regional caches serve objects directly from memory in the format the daemon consumes. If they miss, authoritative scion-server instances retrieve data from Spanner or cloud storage. The tiers speak the same object-request protocol, while enforced routing keeps a regional cache failure from stampeding the authoritative servers.
Because many jobs on one node read much of the same code, the local daemon can absorb repeated requests. Anthropic reports a hit rate above 99% at each cache tier. It says Scion uses 200 times less CPU and memory than its earlier Git mirroring infrastructure, makes CI and research checkouts about two orders of magnitude faster, and freed 25% of CI CPU capacity. These are measurements of its own workload and previous setup; they are not a general benchmark against every Git deployment.
The most economical checkout is one that never happens. A CI job needing a diff, merge base, or ancestry answer can ask the source-control API directly. Some write workloads can also operate through the API instead of first creating a working copy. The service makes repository questions first-class operations, so consumers no longer need local repository machinery just to ask them.
What a fast migration still had to solve
Scion was only one part of the migration. Anthropic also built Antique for code review, plus search, identity and access controls, and new ways to land reviewed changes. This is a major practical distinction from replacing one command-line tool. Source control sits under review, CI, browsing, permissions, and deployment; all of those integrations had to move together.
Seven engineers built Scion, Antique, and related systems while the monorepo migrated over five months. The team says Claude contributed substantially to implementation and optimization. In one reported case, a model rewrote an ingestion prototype to use 20 times less memory and run four times faster. The team also describes the human job as making architectural choices, checking invariants, and rejecting apparently helpful agent changes that broke a core constraint. For example, some generated code tried to answer a merge-history question by scanning the commit log linearly rather than using the review system’s indexed answer.
The new service also created places to enforce directory-level permissions and more precise review rules. Those capabilities make sense for a huge shared repository, where sensitive code and low-risk edits should not have identical approval paths. They add policy and operational responsibilities to the central service. Anthropic says it used simulations, fuzzing, rate limits, traditional alerts, and agents watching component health to operate the system. None of those remove the need to plan for outages: online-first clients depend on the availability of the service and its caches.
The next bottleneck is the merge lifecycle
Faster checkout does not make a rapidly moving main branch stand still. Anthropic says hundreds or thousands of changes may merge while a test run is in progress. A traditional merge queue with a global repository lock becomes difficult to preserve at that pace. The company has invested more in post-merge and pre-deploy testing, accepting that concurrent changes can still conflict and relying partly on agents to repair conflicts quickly.
That is a change in where confidence is established. A green test on a proposed revision cannot prove that every later combination of changes is green. The organization needs a path from a merged change to a tested deploy, plus fast detection and repair when combinations fail. Scion enables the throughput, but the review and deployment systems must decide how to use it safely.
What other teams can take from Scion
Anthropic explicitly does not present Scion as a general replacement for Git. Most projects benefit more from Git’s portable repository format, offline work, and broad tool compatibility than they would from operating a custom source-control platform. Scion’s design relies on very large monorepos, always-online clients, and enough agent-generated work to make centralization worthwhile. Moving to it also required replacing or adapting the surrounding development system.
The portable ideas are smaller. Avoid materializing a repository for a metadata query. Request and cache immutable objects by identity. Make sparse and on-demand file access work cleanly together. Keep the cost of accepting a change proportional to that change, and build specialized history indexes for the questions people actually ask. Git already offers partial clone and sparse-checkout tools, while Sapling demonstrates another scalable source-control path. The opportunity is to make these capabilities easier to combine and to expose useful server-side queries without requiring every caller to carry a full clone.
Scion shows what happens when source control is designed for a fleet of short-lived, online workers. The repository stops being a thing each worker must own. It becomes a service that supplies exactly the files and answers each worker needs—at a scale where that difference changes the economics of building software.