Anthropic rebuilds source control for AI-heavy development

Anthropic says its daily merged code changes rose from about 2,500 in May 2026 to more than 30,000 in September. The company says the increase made source control, builds and continuous integration (CI) infrastructure a bottleneck, so it moved a large monorepo from Git to an internal system called Scion.

The numbers describe Anthropic's own engineering operation. They do not show that AI agents make Git inadequate for ordinary teams. A useful evaluation starts by separating checkout, CI queue, dependency installation, compilation, testing and deployment time.

Where the bottleneck appears after agents multiply changes

Anthropic reports that its repository history approaches 100 GB, its compressed working copy exceeds 25 GB and CI checks out code about 25 million times a day. A short-lived agent or CI worker that repeatedly downloads a large repository can turn network traffic and local storage into a recurring cost.

That workload is unusually large, and the public account does not provide a cross-company benchmark. Teams should record queue time, checkout time, dependency setup, compilation, test execution and deployment separately, using median and high-percentile results. If tests dominate the run, a new source-control layer will not address the main delay.

How Scion changes access to a large repository

Anthropic describes Scion as a service-oriented system in which servers answer history, diff and file-ownership queries while clients fetch needed file objects on demand. Git normally gives each clone a locally usable copy of repository data, including the ability to inspect history and commit while offline.

Scion moves more work to the server. A client keeps a limited object cache, and a working copy materializes files when a job needs them. A changeset records files changed from its parent and points to content-addressed objects. Immutable objects can be reused by caches, while sparse and virtual checkouts avoid retrieving paths that a job never reads.

The request path starts at a worker-side scion-daemon, continues to a regional scion-cache, and reaches an authoritative scion-server when the object is missing. That arrangement can absorb repeated reads close to the workers, but it also makes network access, cache design, server capacity and recovery procedures part of the source-control system.

What the reported speed gains actually measure

Anthropic says Scion's cache hit rate exceeds 99 percent, its source-control CPU and memory needs are about one two-hundredth of its former Git mirror setup, and CI and research checkouts fell from minutes to seconds. The company also says the change released 25 percent of CI CPU capacity.

Those are internal comparisons, not independent tests. A lower checkout cost can let a fixed pool of runners handle more jobs, but it does not mean each job compiles or tests faster. Queue time may fall because capacity was released, while a single job remains limited by a compiler, test suite or external service.

Anthropic says Scion is not a general-purpose replacement for Git and does not present its design as suitable for every organization. That qualification matters: the system is built around a large monorepo, always-connected workers and a company able to operate the surrounding code-review, search and access-control services.

How this plays out outside Taiwan

For an organization in the United States, the first practical question is availability. Anthropic's public article describes Scion as an in-house system, not as a hosted service or downloadable open-source project. A team cannot turn the reported checkout figures into a purchase plan without a public release, support terms, migration tooling and a service-level agreement. For a commercial baseline, GitHub's US pricing page lists GitHub Enterprise at US$21 per user per month for the first 12 months and describes Enterprise Cloud as a service with regional data-residency options. That price is for GitHub Enterprise, not Scion, and it excludes the engineering work needed to measure CI capacity, storage, runners and data transfer. Federal agencies also need to check the relevant US government authorization and agency requirements rather than treating a commercial plan as automatically suitable for government code.

For a UK team, the decision has a different review point. The UK Department for Science, Innovation and Technology's Software Security Code of Practice is a voluntary framework for reducing software supply-chain and resilience risks. A source-control redesign should therefore be assessed alongside dependency provenance, vulnerability handling, incident communication and the supplier's maintenance commitments. The framework is not a rule that mandates Git, Scion or a particular cloud, but it gives a procurement team a concrete list of questions for any service that will hold source, build metadata and pipeline credentials.

Singapore's government controls make the repository boundary more explicit. Singapore's ICT&SS policy catalog recommends a central repository with version control, rejecting unsigned commits, protecting the default branch and requiring CI tests before merging. A team considering a Scion-like service would need to demonstrate how those controls map to its server-side changesets, identity system, review flow and build pipeline. The catalog points to GitHub branch protection and GitLab push rules as examples; it does not certify Scion or require either vendor.

Singapore's Cyber Security Agency also advises organizations to keep software bills of materials, review third-party tools, restrict developer and CI privileges, and keep credentials and private keys out of repositories. Its April 2026 advisory says contracts with paid providers should address security patching, incident reporting, service levels and audit rights. Those checks are relevant to any centralized source-control service because a failure in the server or cache layer can affect many agents at once.

That procurement work should include the agent itself. A hosted platform may expose repository contents to build runners, indexing services, code-review features or AI coding tools even when the source-control product is the only item on the purchase order. Ask whether prompts, logs, cache objects and generated patches are retained, where each class of data is stored, and whether administrators can export the full history. These questions matter in the United States, the UK and Singapore because a faster checkout path can widen the number of systems that handle the same source code.

For teams elsewhere, the same rule applies: check the local procurement, data-residency and security requirements before choosing a hosted platform, then ask the vendor for the exact region, retention period, subprocessors, export path and recovery target. If the requirement is only to reduce initial downloads, a full rewrite may be unnecessary. Git's official clone documentation supports sparse checkouts and partial-clone filters such as --filter=blob:none, which defer file contents until they are needed. Those features create a lower-risk comparison point before a team takes on a new service and a new operating model.

Migration costs extend beyond the repository format

A new source-control service affects offline work, permissions, code review, search, CI integrations, backups, disaster recovery and developer training. Anthropic says it built internal review, search and access-control services during its migration, which shows that the repository is only one part of the toolchain.

Teams also need a parallel-run plan, history validation, rollback path and an answer for server outages. Centralized access can simplify policy enforcement, but it creates a larger dependency on service availability and network connectivity. Security review must cover machine identities, emergency access, audit logs, cache contents and the handling of secrets in agent environments.

How to decide between Git tuning and a new system

Start with a repeatable workload that represents normal repository size, change patterns, agent concurrency and CI usage. Measure cold-cache and warm-cache runs, popular-path access, network interruptions and service failure. Then compare Git configuration changes, internal mirrors, warmed caches, sparse checkout and partial clone with the cost of operating a new service.

Git's partial-clone documentation describes a promisor remote that supplies missing objects later. That does not reproduce Scion's server-side query model, but it gives teams an existing mechanism for reducing the initial object set. A benchmark should use the same runners, repository revisions, cache state and test suite for every option.

A self-built system becomes easier to justify only when source retrieval remains a repeated constraint after these lower-cost tests, the improvement scales across representative workloads, and the organization can maintain the service for years. Anthropic's Scion is a useful design case for that discussion. It is not a product catalogue or evidence that every AI-heavy team should leave Git.

Frequently asked questions

Has Scion replaced Git for most companies?
No. Anthropic uses Scion for its own large monorepo and describes it as an internal system rather than a general-purpose Git replacement.

Does faster checkout make the whole build faster?
Not necessarily. Checkout, queueing, dependency installation, compilation, testing and deployment are separate stages and need separate measurements.

Can a small team adopt Scion directly?
There is no public download or hosted plan documented in Anthropic's engineering article. A small team can first test Git's partial-clone, sparse-checkout and cache options against its own workload.