# Anthropic rebuilt source control for its always-online agent workload > Anthropic's internal Scion system moves source-control history, commits and merges to a service while agent and CI clients fetch only the code they need. By BIG CHANGE Editorial Published: 2026-10-14T13:58:21.150Z Updated: 2026-10-14T13:58:21.150Z Canonical: https://bigchange.ai/blog/anthropic-scion-source-control-agents ![Conceptual charcoal illustration of a tall service rack connected by an orange cable to a smaller client node in a data center aisle.](https://bigchange.ai/api/media/file/scion-client-service-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. Generic infrastructure; no actual Anthropic hardware, Scion interface, measured result or public product is depicted. Anthropic says its internal monorepo went from about 2,500 merged changes a day in May to more than 30,000 a day by September 2026. Its [October 13 engineering account](https://www.anthropic.com/engineering/redesigning-source-control) describes Scion, a source-control system built for the agents and automated jobs behind much of that growth. The useful engineering question is which work a client still needs to do when it can rely on a central service for history, commits and merges. ## The big change - **What changed:** Anthropic moved its monorepo from Git to Scion in five months. Scion clients fetch only the objects they need and leave commits, merges, rebases and history queries to a server. Anthropic built it for a workload dominated by online agents and jobs. - **Why it matters:** A CI job can ask for a diff or merge base through an API without maintaining a local repository. When it needs files, a sparse or virtualized checkout limits what reaches disk. That shifts cost and operational responsibility toward the central service. - **What to watch:** Anthropic reports faster checkouts and lower infrastructure use in its own fleet, without independent validation here. The company says Scion is a bespoke internal system whose migration also required code review, search and CI changes. ## Why Git became expensive in this monorepo Git's distributed design gives each full clone the history and objects needed for offline work. Anthropic says the main branch history of its monorepo is almost 100 GB, while a compressed working copy exceeds 25 GB. Its CI fleet performs roughly 25 million code checkouts a day, before developer environments, agent sandboxes and research jobs. Those are Anthropic's workload figures, not a general threshold at which Git stops working. The company had already used shallow clones, sparse checkouts, internal mirrors and repository snapshots. It says several hundred mirrors eventually became difficult to operate as the repository and merge rate grew. Anthropic's diagnosis was specific: most of its clients were agents or jobs that were online anyway, yet the tools still paid much of the cost of keeping a local repository. Scion takes that online connection as a design assumption. The [engineering account](https://www.anthropic.com/engineering/redesigning-source-control) says the server answers history and blame queries, creates commits, and performs merges and rebases. The client keeps a bounded cache of objects, places requested working files on disk and monitors local file changes. Losing the ability to do those operations independently is a deliberate tradeoff for moving less data to each client. ## A checkout can be smaller, or unnecessary Scion exposes the source-control queries used by its client through APIs. Anthropic says a CI job needing a diff from a merge base can ask the server directly. Its automated bisect and revert pipelines use the same programmatic route. For those tasks, the job may never need to materialize a working copy. When a job does need files, Scion supports sparse checkouts containing requested directories and virtualized checkouts that materialize files when read. The client asks for specific missing trees and blobs, recursively, rather than negotiating a large packfile. Each requested object has immutable, content-addressed identity, so caches can return it without checking whether its contents changed. Anthropic describes a node-level daemon and regional caches between clients and authoritative servers; all tiers use the same object-request protocol. This design has a different failure and maintenance boundary from a complete local clone. The client depends on the service for operations that Git can perform offline, and the service must supply object and history queries at the fleet's pace. Anthropic says it enforces cache tiers partly to prevent a failed regional cache from overwhelming upstream servers. The article does not provide availability measurements for that architecture. ## What the server stores and computes Scion's unit of work is a changeset in a write-ahead log. Anthropic says it records changed files relative to a first parent, with pointers to compressed file contents in blob storage. The server creates changesets without moving a shared branch pointer for every write. Separate derived structures support queries such as file blame, path history and commit ancestry; Anthropic can calculate some eagerly and defer others. That separation matters to the API design. Jobs can ask for a merge base or a file's history without carrying all the structures needed to calculate the answer locally. It also moves the cost of maintaining those structures to Anthropic's service. The company says it distributes repository data and scales components independently, with no fully materialized copy of the repository even on the server. Anthropic reports that Scion's infrastructure uses 200 times less CPU and memory than its previous Git mirroring setup, and that CI and research checkouts now take seconds rather than minutes. It attributes a 25% CPU capacity gain in CI to the change. These comparisons are against Anthropic's prior internal system, under its own workload; BIG CHANGE has not reproduced the measurements or inspected the underlying telemetry. ## The migration cost is part of the result Anthropic says seven engineers built Scion and a companion code review tool, Antique, along with related systems, and migrated the monorepo in five months. That account also describes new code search, access control and changes to the way code is reviewed and landed. An organization evaluating the design has to account for those adjoining workflows, as well as the source-control service itself. Anthropic explicitly says Scion is unsuitable as a general Git replacement. Its internal review, search and CI components are bespoke, and a move away from Git would require changes across a development lifecycle. The narrower lesson in its account is architectural: an online service can answer more source-control questions for automated clients, while those clients keep only the files they use. Anthropic suggests some ideas, including richer server APIs and better composition of Git's sparse and shallow features, could be applied without adopting Scion. ## Sources & further reading - [Anthropic Engineering, “Redesigning source control at Anthropic”](https://www.anthropic.com/engineering/redesigning-source-control) (October 13, 2026). Anthropic's first-party account of its Scion architecture, migration and internal workload and performance figures. The reported measurements and operational outcomes have not been independently verified by BIG CHANGE; no Scion system was tested for this article. ## Sources - [Anthropic Engineering, Redesigning source control at Anthropic](https://www.anthropic.com/engineering/redesigning-source-control) — First-party engineering account of internal Scion architecture, workload, migration and performance. All workload and performance figures are attributed company claims; BIG CHANGE did not access or test Scion or independently validate its measurements.