Theo Explains Scion, Anthropic’s Source-Control System for Agent-Scale Work

I have used Git since before I began writing code, but the way I build has changed. Git and GitHub grew around expensive human-written changes and human review. With many agents working in parallel, I have started to see friction in both the hosting platform and the underlying source-control workflow.

Anthropic describes a different response: its in-house source-control system, Scion. The company says its daily merged changes grew from roughly 2,500 in May to more than 30,000 in September, and that it migrated its monorepo in five months. Its account is a case study in rethinking infrastructure for an unusual workload.

Anthropic says coding itself is no longer its main bottleneck; source control, builds and CI increasingly are. I describe a related goal as de-risking the merge button: verify before a change lands, limit the blast radius afterward, test releases with a smaller audience and make reversions practical.

For my own T3 Code work, I recently merged more than 50 PRs in one sitting and used a nightly release to test the result before a wider release. That is my experience in my project, not a universal standard for every team. The surrounding verification and ability to undo a bad release are central to why I can work that way.

Custom source control for large organizations is not unprecedented. Meta built systems around Mercurial and stacked changes; tools such as Graphite brought some of those workflows to GitHub. Large repositories and unusual workflows can justify choices that differ from the industry default.

Anthropic says it built Scion together with Antique, a code-review service, code search, access controls and other infrastructure. Its blog focuses on Scion. The company acknowledges that its agent-heavy workload is unusual, although it expects similar pressure points to spread as organizations use coding agents more heavily.

A normal Git clone is self-contained: it can read history, calculate diffs and work offline. Anthropic says its main-branch history is nearly 100 GB, its compressed working copy exceeds 25 GB, and CI performs around 25 million checkouts daily. Naively fetching that much data would imply over 600 PB of traffic per day.

Shallow clones, sparse checkouts, mirrors and repository snapshots helped, but Anthropic says it eventually operated hundreds of mirrors and struggled as merge rates rose. Snapshots fell behind the tip of main, while history-dependent operations on partial clones required more care. The company was effectively treating a distributed system as centralized anyway.

Its clients were primarily agents and jobs that already needed a network connection. Anthropic therefore asks what source control looks like when a reachable server is an explicit design assumption. That assumption fits its workload but sacrifices a property that makes Git valuable for many other repositories: local, offline operation.

Scion is asymmetric. The server answers history and blame queries, creates commits, and performs merges and rebases. The client keeps a bounded local object cache, lays out files and monitors the working copy. Clients do less independently in exchange for keeping much less data locally.

The same source-control operations are exposed as APIs. A CI job that needs a merge base or a diff may be able to ask the server instead of maintaining a repository. Anthropic says this made internal tools such as automated bisection and revert pipelines practical at its scale.

Scion distributes repository data so components can scale independently. It avoids materializing a full repository on each server and does not use Git-style pack files in this design. Anthropic wants commit creation and downstream work to scale with the size of the change rather than the whole repository.

Commits, rebases and merges are performed server-side, so there is no separate push after a local commit. The workflow discourages most refs other than main or release branches, reducing shared mutable state. The goal is cheap, incremental change creation without forcing many parallel agents through a common lock.

A working copy is optional. Jobs can request only a diff or perform certain writes over the API. Sparse checkouts request selected directories; virtualized checkouts materialize files on demand. At millions of checkouts, avoiding unnecessary files can make a large difference.

The unit of work is a changeset, stored as a write-ahead-log entry. Instead of pointing only to a complete tree as a Git commit does, the changeset lists files changed relative to its first parent and points to compressed, content-addressed file contents in blob storage. The server creates the changeset.

This lets the system accept changes without repacking a repository or coordinating every server around ref movement. The changeset records what changed, but it does not by itself answer every history question efficiently. Scion builds other structures for blame, path history and commit-graph traversal.

Anthropic calls those structures derived data. Each type is computed recursively from the values for a changeset's parents. The system can add new kinds, compute them eagerly or on demand, and change their implementation without changing the client. Anthropic says it has added indexes for copy detection and path-based search.

The API boundary matters here. With a complete local Git repository, a client can inspect data directly; with a server API, the service can optimize a query and its indexes behind the interface. The tradeoff is that clients rely on the service and on the operations the service exposes.

A small fleet of Scion servers answers queries such as changesets, diffs and merge bases. Data is content-addressed and immutable: once a particular object is stored, caches can reuse it without coordinating to check whether its contents changed. The servers can compute derived data and write results back to Spanner.

For file contents and working copies, Scion uses its own fetch protocol. Rather than telling the server everything the client already has, a client requests missing trees and then blobs that it wants. Each object is independently addressable, making requests cacheable and resumable without a single large pack-file response.

In the compute fleet, a daemon shares an object cache among jobs on a node and starts from a periodically refreshed snapshot. Regional cache servers stream objects in the format the daemon consumes. When an object is missing, the request can reach the authoritative Scion servers, which use Spanner and cloud storage.

The daemon, regional cache and server use the same RPCs, while the topology is deliberately tiered to isolate failures. Anthropic wants a regional cache failure not to overwhelm the authoritative service. Developer machines use the regional cache; CI and cluster jobs can benefit from a node-local daemon.

Anthropic reports cache-hit rates above 99% at each tier. In its environment, it says Scion's CPU and memory footprint is 200 times smaller than the earlier Git-mirroring infrastructure; CI and research checkouts moved from minutes to seconds, and CI gained 25% CPU capacity. These are company-reported results for its workload, not universal Git benchmarks.

This is an example of building for a specific constraint. My own experiment, Lust, aims at compiling a subset of Rust faster for my TypeScript rewrite. It is not intended to work for most Rust projects. A bespoke solution can be useful precisely because it does not have to solve every possible case.

Anthropic says it built an early Git-to-Scion ingestion prototype largely by hand, then asked an internal Claude model to rewrite it. The company reports the rewrite used 20 times less memory and ran four times faster while preserving required invariants. That is an internal comparison, not evidence that every rewrite will improve by those factors.

The company says seven engineers built Scion and Antique and migrated several related systems over five months. I see this as an example of lower switching costs: replacing a vendor or building a tailored alternative may become practical in cases where it previously consumed too much engineering time.

For example, I built a pipeline to mirror analytics into my own ClickHouse and R2 setup and say it was more than ten times cheaper for my needs. My own CI analysis also estimated almost 1,000 hours spent waiting for Git checkouts, and roughly $350–$600 in CPU rental. Those numbers are specific to my measurements and assumptions.

Anthropic emphasizes that engineers remain valuable even when Claude writes much of the code. Engineers make system-level decisions and must sometimes tell the model no. The article describes agents violating constraints or attempting expensive linear scans where an appropriate service could answer the question.

Adversarial model reviews can catch problems but can also encourage scope creep or unnecessary defensive complexity. Anthropic says its team still reviews every change request, focusing on intent rather than reading every line. Theo's point is that human judgment remains needed to evaluate both the implementation and the review feedback.

The company describes extensive testing, including hermetic simulations, fuzzing and rate limiting, and says Claude found algorithmic improvements. I find it striking that an agent can be asked to build a fuzzer and investigate failures, but these practices still depend on choosing meaningful invariants and evaluating the results.

Anthropic presents command timings for its monorepo. Its chart reports faster pulls, checkouts, rebases and status operations in developer environments, and an 84-times faster new worktree in the agent environment. The speedups differ by operation and environment; they describe this particular migration.

Scion also supports repository and directory-level permissions, and its review tools can express approval constraints for different kinds of change. I am enthusiastic about finer-grained access, though my criticism of how review rules should be implemented is my own view. Security still depends on correctly configuring and enforcing permissions.

Anthropic says it uses Claude-based 'superfans' with access to telemetry and logs to watch individual components, alongside traditional alerts. The company reports that these agents can notice subtle or novel issues. That monitoring complements, rather than eliminates, conventional operational practices.

The larger lesson for me is to revisit assumptions that were sensible at human scale. Engineers often prefer familiar tools because past migrations have been costly and new systems can disappoint. Knowing why an old design worked is useful, but it should also help identify where a different workload calls for another design.

Anthropic says a global lock on the merge queue did not work for its agent-scale throughput, so it invested in automated testing after merge and before deployment. Concurrent changes can still conflict. I favor reducing the damage and recovery time when a bad change lands, alongside appropriate verification before it does.

I have wondered whether a merge queue could collect approved work and let an agent combine changes and resolve conflicts in groups. That is my idea, not a claim that Anthropic implemented it. The common issue is how to keep many independent changes moving without ignoring the consequences of failure.

Anthropic is explicit that Scion is not a general-purpose Git replacement. Its approach is aimed at enormous monorepos and unusually high agent throughput, and the company's internal inference budget is not typical. Different teams have different availability, offline, security and migration requirements.

Scion also depends on bespoke review, search and CI systems that would make a public release difficult to adopt. Anthropic says it is sharing design ideas rather than presenting a turnkey product. I speculate about the internal product discussion, but the stated reasons are the integration and migration burden.

The company suggests that Git platforms could adopt some lessons without abandoning Git: different server architectures, richer server-side APIs, better negotiation and improved composition of sparse and shallow features. It credits the Git community's long work scaling the platform and frames its own contribution as narrower.

A project like this would have sounded implausible to me not long ago. Now it illustrates a practical question: what assumptions in our tools fit our actual workloads, and which ones are worth revisiting? Scion is an interesting deep dive precisely because it makes those tradeoffs visible.