Scion: why Anthropic replaced Git for its agents

The test is still waiting for its source

Your agent fixes a function. The patch is ready, but test results are taking longer than expected. The logs reveal that the compiler has not started: the machine is preparing its environment and retrieving the repository. Faster code generation does not shorten this part of the journey.

Imagine a thousand independent jobs, each checking a small part of the same project. Their source revisions are nearly identical. If each job rebuilds its environment from scratch, the network and disks repeatedly serve the same data. This is a teaching example, not a measurement of Anthropic’s system.

On October 13, Anthropic announced its monorepo migration to Scion, reporting roughly 25 million daily CI checkouts. Seven people built Scion, Antique and related services, migrating in five months. Scion creates changes server-side, computes derived indexes and distributes objects through local and regional caches, backed by Spanner and object storage. Anthropic’s engineering report.

To understand the tradeoffs, we will follow our test job. This article separates mechanisms documented in other systems, our illustrative calculations and unanswered evaluation questions. LeCompute has not run Scion.

What Git can already avoid

Three quantities matter: available history, downloaded content and files present on disk. Git supports shallow clones to limit history and partial clones to defer content downloads. Sparse checkout selects the working-tree files. Clone documentation, sparse checkout documentation.

Anthropic says it already used these optimizations, mirrors and repository snapshots. They delayed migration without meeting its growing needs. Git mitigations used.

Our parser test might need one directory and a few dependencies. A small visible directory does not prove that the initial transfer was small. Conversely, an object omitted from the download may still be needed later. The timer must keep running until useful work can begin, otherwise an optimization may simply move waiting time into a different step.

Logical representation and physical storage also differ. A Git commit references a tree, and unchanged objects are reused. This does not mean Git physically copies every file for every commit. Git’s object model.

Packfiles group objects and can encode some as differences against others. Compression trades computation for storage and transfer savings. Reusing existing packs and deltas matters too: serving a request need not rebuild everything from scratch. The git-pack-objects manual.

For our fleet, the diagnostic question is specific. How much time goes into network transfer, how much into decompression, and how much into writing files? A single metric called “clone duration” conceals these differences.

Git can share objects too: linked worktrees share a repository, and clones can borrow from a reference repository. These mechanisms reduce some copies; they do not by themselves isolate untrusted jobs. Worktrees, reference repositories.

Store the change, then prepare the answers

Scion changesets list files changed relative to the first parent. APIs can spare jobs a checkout when all they need is a diff. Documented structures and APIs.

Meta provides a useful architectural precedent. Mononoke, Sapling’s server, keeps a canonical model called Bonsai and derives other representations from it. Its architecture separates write and read paths, with services that can scale independently. Mononoke architecture.

Consider the file containing our patched function. Accepting the change and answering “who wrote each line?” require different work. The first operation must preserve the change and its connection to history. The second needs an efficient way to traverse or index that history. Combining them into a single operation can make a writer wait for a result that nobody will request.

Mononoke documents derived structures for directory trees, file histories and line attribution. These can be computed on demand or in the background, then retained for later reads. Derived-data framework.

The practical consequence is straightforward: a first reader may pay for a computation while subsequent readers reuse the answer. That first access still needs measuring. Moving work after a write does not eliminate its cost; it changes when the cost is paid and which resources perform it.

One source of truth does not require one serving machine

Software Engineering at Google, published in 2020, distinguishes a project’s central authority from its tool’s distributed design. A team can use Git while treating a particular repository as authoritative. The authors describe Piper, Google’s specialized centralized system. This is a historical precedent, not an observation of its infrastructure in October 2026. Version-control chapter.

In our example, a single reference identifies the revision under test. It does not require every file read to pass through one machine. Stable content can be copied closer to readers. Mutable information, such as which revision is now authoritative, needs coordination rules.

A transactional database does not remove that design decision. Spanner documents atomic transactions and consistency guarantees; an application must still decide which updates belong in the same transaction. Avoiding a global application lock should not be interpreted as eliminating coordination throughout the storage system. Spanner transactions.

Sharing data without promising a miracle

Return to the thousand jobs. Illustrative assumption: each needs the same 200 MB of compressed source data. Independent transfers would total 200 GB in decimal units. If the jobs run on ten machines and a shared cache on each machine fetches that data only once, upstream traffic falls to 2 GB.

The hundredfold difference applies only to that traffic under those ideal assumptions. It says nothing about test CPU time. Files may still need writing into a thousand isolated directories. Local reads, decompression and filesystem metadata operations still have costs. New revisions and cache eviction would reduce sharing as well.

EdenFS, part of the Sapling ecosystem, populates working files on demand. Microsoft also developed GVFS for its use of Git with Windows. These precedents show that lazy retrieval can extend into the filesystem. EdenFS, Microsoft’s Windows and Git experience.

The program launched afterward determines how useful this is. A focused test may read only a small part of the tree. A tool that walks every directory and opens every file eventually requests almost everything. Before adopting lazy access, observe the consumers that will trigger it.

What happens when the cache is empty?

Anthropic describes strict cache tiering to protect upstream servers. This is a reported safeguard; we have not measured its effectiveness. Cache hierarchy.

An effective cache can hide the capacity of upstream storage. In another illustrative scenario, assume a 99% hit rate. Upstream receives one request in a hundred. If the cache disappears and every read immediately falls through, potential upstream demand rises a hundredfold at the same client request rate. This is not a prediction of a Scion incident.

Google’s SRE guidance explains how cold caches and overload can contribute to cascading failures. It recommends testing capacity limits and overload behavior. Retries must also be bounded so they do not amplify a failure. Cascading failures, service practices.

Our evaluation criterion is now stricter. The fleet must make progress with warm caches and recover predictably after restarts. Temporarily refusing work may be better than forwarding every request to a service that is already saturated.

Building the replacement includes the migration

To evaluate a project like this, we would ask how the team establishes equivalence between old and new representations. A source-control migration must preserve the right content, its parents and applicable permissions. Testing a successful download alone leaves out renames, merges and recovery from interrupted operations.

Anthropic reports simulations and fuzzing. The post announces no public Scion offering. Testing and distribution.

A useful evaluation protocol would compare sampled histories, inject failures between write stages and replay interrupted requests. These are our audit criteria, not claims about internal implementations we have inspected. We also do not infer Scion’s programming language from the language used by a neighboring project.

The economic question includes maintaining integrations for reviews, builds, tests, search and developer tools. An improvement in source delivery can be real without making the full migration worthwhile for another organization.

Measure the wait before replacing the tool

Instrument the complete path from requesting a test to receiving its result. Separate waiting for a machine, retrieving source, installing dependencies, building and running tests. Compare identical jobs with warm and cold caches. Examine slow jobs as well: a good median can conceal delays that block a release.

Fix the revision, dependencies, machine resources and concurrent job count. Specify which cache is cleared: the operating-system file cache, node cache and remote service cache cover different boundaries.

If preparation dominates, experiment with a smaller checkout scope or shared data compatible with job isolation. Check that the improvement does not merely postpone waiting until the first file access. If tests already dominate, replacing source control is unlikely to be the first investment to make.

The same discipline applies when distributing local inference across machines: understand which work can actually be shared and which costs remain local. The useful outcome is a correct validation delivered sooner at a controlled cost. A higher count of integrated changes does not establish that outcome on its own.

Sources and method

Scope. Documentary research as of October 15, 2026. Anthropic’s October 13 report is an account from its engineering team, not an independent evaluation. We have neither test access nor raw traces to reproduce its results. Latency distributions, total operating costs and migration incidents remain necessary for a reproducible comparison.

Documented mechanisms. Git’s clone, sparse checkout, object and pack documentation distinguish its capabilities. Meta’s Mononoke architecture, derived-data framework and EdenFS description document those projects, not Scion’s code. Similar design choices do not establish code reuse.

Context and reliability. Google on version control, Microsoft on Windows and Git, Spanner transactions, cascading failures and SRE service practices.

Illustrative calculations. 1,000 × 200 MB = 200 GB; 10 × 200 MB = 2 GB. At a 99% cache hit rate, 1% of requests reach upstream; without that cache, up to 100 / 1 = 100 times as many can reach it. These assumptions isolate mechanisms. They are neither Scion measurements nor performance estimates. No benchmark script was run.

Traceability. Meta sources are pinned to commit 79071c2a3ea20c36ed71332608535e5801101bba, dated October 14, 2026. Git and cloud documentation are evolving pages consulted on October 15, 2026.