Why Anthropic Built Scion
Anthropic moved from Git to Scion because agent-driven merge and checkout traffic exceeded the operating model of its Git infrastructure, not because Git stopped working for ordinary teams. Scion is an in-house version-control system for Anthropic’s monorepo, built for clients that are usually automated, short-lived, and online.
The scale was unusual: daily merged changes grew from around 2,500 in May 2026 to more than 30,000 in September, while CI performed roughly 25 million checkouts per day. Git remains the sensible default when local history, offline work, and manageable repository traffic matter more than centralized throughput.
The decision is therefore operational. Measure merge volume, repository and working-copy size, CI checkout traffic, online availability, and the capacity to migrate and operate a source-control platform. Persistent bottlenecks across those measures are the case for considering a Scion-like architecture.
What Changed In Anthropic’s Workload
The decisive change was activity rate and automation, not repository size alone. Anthropic merged around 2,500 code changes per day in May 2026 and more than 30,000 per day by September. Claude was autonomously iterating on research loops, micro-optimizing programs, and building services, so source control had to process machine-generated work at a sustained rate that human-scale tooling was not designed for.
The repository itself was already large: the main-branch history was almost 100 GB, and a compressed working copy exceeded 25 GB. CI performed roughly 25 million code checkouts per day, before counting developer environments, agent sandboxes, and research jobs. Anthropic estimated that fetching those copies naively would produce more than 600 PB of Git traffic per day. That figure is a modeled upper bound, not measured network usage, but it shows the pressure created by repeated transfer.
A human team usually clones occasionally, keeps a durable local repository, and works offline between server operations. Anthropic’s CI jobs, agent sandboxes, and research jobs were short-lived clients requesting source repeatedly. Their workload multiplied checkout and merge operations while gaining little from Git’s full local history or offline guarantees. That mismatch, rather than repository size by itself, made Git’s operating model expensive.
Why Git’s Distributed Model Became Expensive
Git works well because each clone is a complete repository. A developer can compute diffs, inspect blame, create commits, and check out any revision without contacting a server. That independence is valuable for ordinary teams, where clones are long-lived and repository traffic is modest.
Anthropic’s workload reversed those assumptions. Its CI jobs, agent sandboxes, and research jobs were short-lived clients that repeatedly needed small parts of a large monorepo while remaining connected to internal services. The main-branch history approached 100 GB, the compressed working copy exceeded 25 GB, and CI performed about 25 million checkouts per day. Copying a complete repository for each job made Git’s local independence an expensive duplicate of data the clients rarely needed.
Anthropic tried Git’s standard options: shallow clones, sparse checkouts, promisor remotes, internal mirrors, and repository seeds stored in blob storage. At its peak, it operated several hundred internal Git mirrors. These measures reduced transfer work, but introduced another failure mode. Mirror snapshots fell behind main as merge volume increased. Partial clones also made history-dependent operations, including diff and blame, harder because the required objects were not always local.
The problem was therefore not that Git failed at version control. Git was paying for complete, offline-capable clients in a system dominated by ephemeral, automated, always-online clients. Anthropic needed to reduce repeated repository materialization without losing dependable history queries. That workload fit a server-oriented design better than Git’s distributed default.
How Scion Differs From Git For Agents And CI
Scion fits Anthropic’s workload by putting repository intelligence on servers and making each change cheap to record and process. Its clients are always online. They keep bounded caches and manage working files, while the service handles history queries, blame, commits, merges, and rebases. Internal tools can request ancestry or a diff through source-control APIs without maintaining a complete local repository.
That reverses Git’s usual client-server balance. Git gives each clone enough data to inspect history and work offline. Scion distributes repository data across independently scalable components instead of replicating a complete repository through Git-style packfiles or whole-repository mirrors. The server can answer a history query, while ephemeral CI jobs and agent sandboxes avoid rebuilding the same local state.
The checkout is also workload-specific. A sparse checkout contains requested directories. A virtualized checkout materializes a file only when a process reads it. Some automated write paths use the APIs without a working copy at all. Commits are incremental and lock-free, so their cost tracks the changed data rather than requiring the client to coordinate a large local repository.
Scion’s basic unit is a changeset, recorded as a write-ahead-log entry. A Git commit points to a tree. A Scion changeset records the changed data directly, which suits frequent small writes and server-side processing. That design does not remove the need to preserve history or resolve merges. It changes where those operations run and how much state each client must carry.
Google’s Piper and Meta’s Sapling provide prior art for centralized or server-oriented source control at monorepo scale. Scion is a similar response to a specific operating model, not evidence that every team should replace Git. Its clients lose operations Git can perform offline, a trade Anthropic accepts because Claude, its heaviest user, is necessarily online.
Does Anthropic Still Use GitHub?
Replacing Git in Anthropic’s internal monorepo does not establish that the company abandoned GitHub or every Git-based integration. Git is the version-control system. GitHub and GitLab add hosting, code review, permissions, status checks, and integrations around that system.
Anthropic’s migration was broader than a repository-format swap. The company built Scion alongside Antique, its code-review interface, plus code search, source-control IAM, and workflows for landing reviewed changes. Those components together form an internal source-control platform for its monorepo.
What is established is that the monorepo moved from Git to Scion. The public account does not establish that Anthropic eliminated all GitHub use, or that every repository and external workflow moved with it. A company can replace its internal monorepo backend while retaining Git-compatible tools or GitHub integrations elsewhere.
The practical lesson is narrow: Anthropic’s migration addresses a specific monorepo workload. It is not evidence that ordinary teams should leave GitHub or rebuild their entire development platform.
The Strongest Case Against Replacing Git
Most teams should improve Git operations before building a replacement. A custom source-control system moves the hard problems into software the team must design, secure, operate, back up, recover, and integrate. History, merges, access control, review, disaster recovery, build tooling, and developer workflows all become part of the platform’s ownership burden.
The objection is not that AI-generated changes will never create similar pressure. More agents can raise merge volume and CI checkout traffic. Anthropic’s case is different because its merged changes rose from around 2,500 per day in May 2026 to more than 30,000 in September, alongside roughly 25 million daily CI checkouts. Those figures describe a measured infrastructure limit, not a forecast based on enthusiasm for agents.
Anthropic completed Scion and migrated its monorepo in five months with seven engineers. That result is evidence of unusual capacity, not a normal project estimate. The team had a concentrated monorepo, Claude-assisted development, and enough platform expertise to ship Scion alongside Antique, code search, source-control IAM, and landing workflows. Other organizations would also need to fund compatibility work and operational ownership after the initial migration.
The recommendation changes when Git-native measures remain bottlenecks after shallow or sparse checkouts, caching, mirrors, and CI redesign. The workload must also be mostly online, and the organization must afford long-term ownership of centralized source control. Without those conditions, replacing Git trades a visible scaling problem for a larger permanent platform obligation.
When Should A Team Consider An Alternative To Git?
Choose an alternative to Git only after measured bottlenecks survive Git-native fixes. Anthropic’s Scion decision fits a monorepo with more than 30,000 daily merges and roughly 25 million daily CI checkouts, not a typical team reacting to AI-generated pull requests.
| Signal | First response | Alternative-system trigger |
|---|---|---|
| Large history or working copy | Use shallow or sparse checkouts, promisor remotes, mirrors, and seeds | Transfer and storage costs remain a persistent bottleneck |
| Merge queue latency | Redesign queues, batching, tests, and landing workflows | Merge throughput still limits delivery after those changes |
| High CI checkout volume or poor cache hit rate | Reuse CI images, improve caching, and avoid repeated checkouts | Checkout traffic still consumes material capacity |
| Stale mirrors or seeds | Increase refresh capacity and measure freshness | Required snapshots cannot stay near main-branch state |
| Slow diff or blame operations | Move targeted queries to services or improve repository indexes | History queries remain too slow at required scale |
| Mostly always-online jobs | Keep Git clients and caches close to CI infrastructure | A centralized server model fits nearly every client |
| Offline or unreliable environments | Preserve local Git capability | Offline work is not a material requirement |
| Limited platform ownership | Improve the existing stack | A funded team can operate source control for the long term |
Repository partitioning can also help when code coordination does not require one monorepo. It is a design change, not a universal fix.
Should a team build its own version-control system? Generally no. Do it only when bottlenecks remain after these mitigations, the workload is predominantly online, centralized APIs match how agents and CI operate, and the organization can fund migration, backups, recovery, access control, integrations, and permanent platform ownership. Without all four conditions, keep Git and optimize the surrounding system.
What Engineering Leaders Should Decide Now
Most teams should keep Git, measure their bottlenecks, and treat Anthropic’s Scion as a workload-specific case study rather than a migration plan. Track merge rate, checkout rate, repository transfer volume, cache hit rate, history-query latency, CI queue time, and the share of work that requires offline access. Separate sustained agent traffic from review noise. If agents add requests without saturating merges, checkouts, or history services, improve the surrounding Git platform first with caching, sparse or shallow checkouts, mirrors, and CI image reuse.
Reconsider the architecture only when those limits remain after targeted changes, most clients are reliably online, centralized APIs improve the workflow, and the organization can fund long-term platform ownership. Anthropic’s design fits persistent agent-scale traffic and its concentrated monorepo. Git remains the default until measurements show that your operating model has changed as radically.
