Anthropic Builds Scion VCS: 7-Person Team Replaces Git to Handle 12x Surge in Claude-Generated Code Commits

Anthropic developed Scion, a custom version control system, in just five months with a team of seven to handle the explosive growth of Claude-driven code commits (a 12x increase in four months). The project involved migrating a Monorepo exceeding 100GB and simultaneously building supporting infrastructure for review, search, and permissions.

Git completely failed under the pressure of tens of millions of daily checkouts and petabyte-scale data transfers; traditional optimizations like shallow clones had reached their limits. Scion employs fine-grained object storage and an incremental synchronization architecture, reducing CI checkout times by 90%. The engineering decision focused on "AI-native development workflows," treating the VCS as AI collaboration infrastructure rather than a tool for humans.

This article is suitable for platform engineers, DevOps architects, and AI infrastructure leads.

In May of this year, Anthropic merged approximately 2,500 code changes per day on average. By September, that number exceeded 30,000. In just four months, the volume of code merges grew more than 12-fold.

Much of this growth stems from Claude. AI Coding Agents can autonomously modify code, run tests, iteratively optimize programs, and even build services from scratch. While code production speed increased, the software development infrastructure originally designed for human engineers struggled to keep up.

Git was the first to hit severe bottlenecks. The main branch history of Anthropic’s Monorepo approached 100GB, with compressed working copies exceeding 25GB. The Continuous Integration (CI) system alone required about 25 million code checkouts per day. Using naive Git data fetching methods could generate over 600PB of data transfer demand daily.

Anthropic had previously employed various optimization techniques, including Git shallow clones, sparse checkouts, internal mirrors, and object storage snapshots. At peak times, they maintained hundreds of Git mirror servers. However, as code merge volumes continued to rise, this solution became increasingly difficult to sustain.

Consequently, Anthropic made a radical decision: develop a new version control system from scratch.

On October 13, Anthropic disclosed this engineering effort in its official engineering blog. A team of only seven engineers developed a new version control system named Scion within five months and completed the migration of the entire Monorepo. Simultaneously, they built code review tools (Antique), a code search system, permission management, and other supporting infrastructure.

After the migration, Scion’s infrastructure CPU and memory usage dropped to approximately 1/200th of the original Git mirror setup. Code checkout speeds for CI and research tasks improved by roughly two orders of magnitude, saving about 25% of CPU capacity for CI alone.

Interestingly, Claude was both a major cause of this infrastructure strain and a key tool helping Anthropic complete the system overhaul.

With 30,000 Daily Code Merges, Where Exactly Did Git Break Down?

Git became the industry standard largely due to its distributed design. Developers can store repository history locally, create commits, and compare diffs, completing most operations without network connectivity.

For the vast majority of software projects, this is a highly successful design. However, it also implies that clients must possess substantial version control capabilities and store the repository data required to perform these operations.

The workload Anthropic faced had changed significantly.

First, the code repository itself grew massive. A main branch history approaching 100GB and compressed working copies exceeding 25GB made frequently creating development environments, CI environments, and Agent sandboxes expensive. Second, the frequency of code checkouts was extremely high. Approximately 25 million daily checkouts did not even account for additional demands from developer environments, Agent sandboxes, and research tasks.

More critically, the rate of code change far outpaced traditional development teams. Anthropic stated in their official post that every time a development bottleneck was eliminated, code output increased further. Development infrastructure needed to continuously adapt to this growth.

To keep Git running, Anthropic deployed hundreds of internal mirror servers and stored repository snapshots in object storage. These solutions reduced redundant downloads but introduced new maintenance burdens. Mirrors required constant synchronization, snapshots quickly fell behind the main branch, and maintaining the functionality of history-dependent operations like diff and blame in partial clone environments became increasingly complex.

This led Anthropic to re-evaluate a long-standing design assumption: If most code operations are performed by always-connected Agents and automated tasks, why does each client still need the ability to independently process full repository history like a traditional Git client?

This question became the starting point for Scion’s design.

Of course, the conflict between ultra-large-scale Monorepos and Git is not new. Google developed its internal centralized version control system, Piper, early on, and Meta invested years in building Sapling. Anthropic’s challenges share similarities with those faced by these tech giants, but the driving force differs: previously, it was primarily large engineer organizations and codebase sizes; now, numerous parallel-working Coding Agents are generating similar pressures.

How Is Scion Designed? Moving Most Version Control Work to the Server

The most significant design shift in Scion is moving version control from a local-repository-centric workflow to an always-online client-server architecture.

In Git, clients can operate independently with full repository access. In Scion, the server handles the heavy lifting.

This change also enables version control capabilities to be exposed directly via API to other systems. For example, if a CI job only needs to compute the diff between a specific commit and its merge base, it can request the result directly from the server without checking out the entire repository. Tools for automated rollbacks or identifying problematic commits can also query version history through the API.

From an engineering architecture perspective, Scion aims to make the cost of version control operations depend more on the amount of data actually modified, rather than the size of the entire repository.

To achieve this, Scion redesigned its underlying data structures.

In Git, a commit references a corresponding tree object. Scion, however, uses a record called a Changeset, which is written to a Write-Ahead Log (WAL). Each Changeset records the files that changed relative to the first parent commit, along with content-addressed references pointing to compressed file contents.

File contents are stored in Blob Storage, while version relationships and associated metadata are managed by the backend system. Scion uses Spanner to store certain metadata requiring coordination, minimizing cross-server synchronization during commit creation as much as possible.

This design allows commits to be created and distributed quickly, avoiding the partial packing, negotiation, and maintenance overheads introduced by Git’s Packfile mechanism.

Scion still supports refs similar to Git branches and tags, but minimizes reliance on them. Anthropic believes that if many operations require updating globally shared state, it risks reintroducing coordination bottlenecks. Therefore, standard commit creation in Scion does not involve moving refs; these references are updated only in scenarios such as main branch updates or release branches.

However, moving operations to the server does not automatically solve all problems. The server must handle requests from numerous Agents and CI jobs simultaneously. If all clients access central storage directly, the system could still be overwhelmed by traffic.

Anthropic therefore designed a tiered caching architecture.

On compute nodes, scion-daemon handles sharing file object caches among multiple tasks on the same node. Regional scion-cache servers provide a second layer of caching, connecting upward to the authoritative scion-server. Only when a cache miss occurs do requests proceed to Spanner or cloud storage.

Clients request specific immutable objects. Since objects are content-addressed, caches do not need to repeatedly verify whether objects have changed, allowing each service layer to scale horizontally independently.

Anthropic disclosed that the cache hit rate exceeds 99% at every layer of this architecture. It also isolates failures through explicit cache tiers, preventing a large volume of requests from flooding upstream services if issues arise in a regional cache.

Scion also treats sparse checkout and virtualized checkout as fundamental capabilities. Clients fetch only the directories and files they need, with some files loaded only upon actual access. For tasks requiring only version metadata, working directory creation can be skipped entirely.

Ultimately, Anthropic reported that Scion’s infrastructure CPU and memory footprint shrank by approximately 200x compared to the original Git mirror solution, code checkout times dropped from minutes to seconds, and CI achieved about a 25% savings in CPU capacity.

It is important to note that these metrics correspond to different optimization dimensions. The 200x figure refers to differences in infrastructure resource usage, two orders of magnitude refers to code checkout speed, and 25% represents CI capacity gains. These should not be simplistically interpreted as Scion being 200x faster than Git across all operations.

Seven People, Five Months: Claude Also Accelerated Infrastructure Rewriting

If Scion’s architectural design reflects systemic changes driven by Agent scaling, then its development process demonstrates another impact of Coding Agents on software engineering organization.

Anthropic disclosed that Scion and the accompanying code review tool Antique were developed by a team of seven. Within five months, the team completed system construction and migrated the entire Monorepo, while also delivering related systems such as code search and permission management.

During this process, Claude handled a significant portion of the code implementation and optimization work.

The official article highlights a specific case: Scion’s early Git data import pipeline was primarily hand-written by engineers, who initially believed performance was already good. Later, they tasked an internal early version of Claude Mythos Preview with reimplementing the entire pipeline.

Without further instructions, the new version generated by Claude reduced memory consumption by 20x and improved execution speed by 4x, while preserving the original data import order and structural constraints.

The significance of this case lies in the fact that Agents are now capable of participating in complex infrastructure performance optimization, going beyond merely writing local functions, interfaces, or business logic.

However, Anthropic emphasizes that this does not mean the role of engineers has disappeared.

Team members believe Claude surpasses them in code writing, but system-level design decisions still rely on engineers. This includes understanding relationships between components, making architectural trade-offs, and determining which problems are worth solving.

An interesting detail from the official article is that a key part of an engineer’s job is telling Claude “don’t do that.”

This relates to the practical characteristics of the Scion project. There are numerous trade-offs between high throughput, low latency, horizontal scalability, fault isolation, and data consistency. An implementation may have excellent code quality yet fail to meet long-term operational requirements. Engineers must decide which solutions are acceptable based on overall architecture and production environment constraints.

Claude is also used for daily system operations. The Anthropic team created a group of Claude Agents dubbed “superfans,” each focusing on different components of Scion. For instance, one Agent continuously monitors scion-daemon, another focuses on scion-cache, and others specifically observe the Antique merge queue.

These agents can read telemetry data and logs, continuously checking system status to identify anomalies that traditional monitoring rules might miss. Anthropic has not eliminated standard alerts; instead, it uses agents as an additional analytical layer.

From code implementation and performance optimization to runtime monitoring, Claude is now deeply involved in Scion's entire engineering lifecycle.

When Agents Continuously Write Code, CI and Merge Rules Must Be Redesigned

Scion solved the scalability issues of version control systems, but Anthropic discovered that many aspects of existing software development workflows are still built around the pace of human engineers. A prime example is the merge queue.

Traditional merge queues coordinate the order in which code enters the main branch, aiming to ensure compatibility between commits and running tests before merging. This mechanism reduces risks associated with concurrent modifications but introduces waiting times and coordination overhead.

The complexity increases significantly when the volume of code merges reaches tens of thousands per day.

While a test is still running, hundreds or even thousands of changes may have already been merged into the main branch. The code state corresponding to the test results may differ substantially from the current state of the main branch. Enforcing strict serial processing through a unified merge queue for all changes would severely limit throughput.

Anthropic stated that the team has not yet found an effective way to replicate industry-standard global repository lock-based merge queues at this scale. Consequently, they have invested more resources in post-merge testing and pre-deployment automated testing.

This means that conflicts between some concurrent modifications may only be detected after merging. Anthropic believes that Claude can typically resolve these conflicts faster than human engineers.

However, this approach raises new engineering challenges.

If merged code may contain undiscovered conflicts, how does the team ensure the usability of the main branch? How should responsibilities be divided between post-merge testing and pre-deployment testing? If multiple agents continuously modify the same set of files, how can the scope of fault propagation be controlled?

Anthropic’s article did not fully disclose solutions to these questions, nor did it provide defect rates, rollback rates, or production incident data under the new workflow. Therefore, while it is clear that Anthropic has adjusted its code integration and verification mechanisms, it remains uncertain whether this model comprehensively outperforms traditional processes in terms of quality and reliability.

Nevertheless, this is a change worth noting. In the past, software engineering infrastructure was primarily built around workflows where developers submit code, run tests, wait for reviews, and merge. As agents take on more actual development work, code generation and submission may become continuous background activities. Version control, CI, code review, and release systems will need to adapt to new throughput and concurrency patterns.

Will Git Be Replaced? Anthropic Doesn't Think So

Seeing Anthropic rebuild its version control system, many might conclude that Git is destined for obsolescence in the era of coding agents.

But Anthropic has not made such a conclusion.

In fact, large tech companies developing dedicated version control systems for ultra-large-scale monorepos have precedents.

Google uses its internal centralized version control system, Piper, while Meta has long been building Sapling. When Meta publicly introduced Sapling in 2022, it noted that traditional open-source version control systems struggled to meet the needs of its massive repositories containing tens of millions of files and commits. Sapling addresses scalability issues through dedicated servers, virtual file systems, and on-demand history retrieval, while retaining the ability to interact with Git repositories.

Scion draws on the design experiences of these systems. What makes Anthropic unique is that the speed of code output driven by agents has caused a team much smaller than Google’s or Meta’s traditional engineering organizations to face similar infrastructure pressures.

However, this does not mean that all teams using Claude Code or other coding agents need to abandon Git.

Scion targets specific scenarios involving extremely large monorepos, tens of millions of checkouts per day, and tens of thousands of code merges. It also relies on a suite of custom-developed code review, code search, and CI infrastructure. For typical teams, migrating to a system like Scion would likely incur costs far exceeding the benefits.

Anthropic explicitly stated that Scion is not intended as a general-purpose replacement for Git and has no current plans to package it as a product for widespread external use.

Instead, the company hopes to drive improvements in server-side scalability within the Git ecosystem by sharing architectural insights. For instance, Git servers do not necessarily need to fully replicate client-side behaviors; code hosting platforms could offer richer server-side APIs; and sparse checkout, shallow cloning, and data negotiation protocols have room for further optimization.

This explains why Anthropic chose to publish technical designs without directly open-sourcing Scion.

Based on currently disclosed information, Scion is an infrastructure heavily dependent on Anthropic’s internal R&D ecosystem. While its architectural experience may have broad reference value, the complete system may not be suitable for direct adoption by other companies.

Conclusion

The most interesting aspect of the Scion project is that it simultaneously demonstrates the productivity gains brought by coding agents and the new engineering costs they introduce.

Claude increased Anthropic’s code merge volume by more than tenfold in just a few months, forcing the team to redesign its version control system. During the development of the new system, Claude helped a seven-person team complete infrastructure transformations that previously might have required more time and more engineers.

This system is already running internally at Anthropic and has achieved significant performance benefits. However, it solves a very specific scale problem and is far from becoming an industry-standard solution.

For more engineering teams introducing coding agents, Scion provides an early case study: when code writing speed is no longer the primary bottleneck, whether version control, testing, code review, and release processes can withstand the resulting changes will become the new engineering challenge.

Related Link:https://www.anthropic.com/engineering/redesigning-version-control-for-coding-agents