Scion – Anthropic's Source Code Version Control System, a Replacement for Git

1. What is Scion

Scion is a source code version control system developed internally by Anthropic, specifically designed to replace Git for managing its massive monorepo. As the code generation volume of Claude has surged 12-fold within 4 months, with the number of daily merges increasing from 2,500 to 30,000, traditional Git infrastructure has become inadequate to handle such high-concurrency automated operations. Scion is redesigned with the "always-on" working mode of AI agents in mind. The client pulls data from the server on demand, and all commits and merges are performed entirely on the server side, supporting full horizontal scalability and sparse checkouts. After migration, resource consumption is reduced to 1/200 of the Git solution, and checkout speed improves by two orders of magnitude, providing a new infrastructure paradigm for large-scale AI-driven development processes.

Technical positioning and domain: Scion belongs to the version control system domain in software engineering, but its design premise is fundamentally different from traditional VCS — it is tailored for development environments dominated by AI agents and automated tasks, rather than the offline workflows of human developers. This system moves all core source code control operations (commit, merge, rebase) to the server side, with the client retaining only a bounded cache and pulling data on demand.

Development background: Scion was developed internally by Anthropic due to bottlenecks in its own infrastructure. The exponential growth in the code generated by Claude led to resource exhaustion in the Git repository mirroring infrastructure. As a result, the Anthropic engineering team was forced to re-examine the fundamental assumptions of version control systems and designed a new architecture from scratch to adapt to the pace of AI development.

Core value: Scion addresses the core contradiction faced by version control systems in the AI era — Git's offline-first, local full-copy model, designed for human developers, cannot support thousands of automated commits and merges per day. Scion reduces resource consumption by 200 times and improves checkout speed by two orders of magnitude through a server-first, API-based, horizontally scalable architecture.

Technical features: Scion replaces traditional commits with change sets, using a prewritten log to record the list of file changes relative to the parent version; it introduces a three-tiered caching architecture (daemon → cache → server), with hit rates exceeding 99% at each level; all source code control queries are exposed via RPC, allowing CI and tools to operate without maintaining local repository copies.

2. Key Features

• Changeset instead of commit: Scion replaces the traditional Git commit object model with a prewritten log entry that records the list of file changes relative to its parent. Once a changeset is created on the server, it is immediately globally available, without the need for packaging, locking, or moving references. This design fundamentally eliminates bottlenecks caused by concurrent commits.

• Derived data mechanism: The system recursively builds indexes such as blame, path history, and skip lists of the commit graph based on changesets, and supports hot-plugging of new data types. Derived data can be computed immediately or delayed, and clients are completely unaware of this process, making complex repository analysis operations no longer require traversing the full history.

• Fully API-based source control service: Queries such as diff, merge base, and blame are all exposed through RPC interfaces. CI systems and development tools no longer need to maintain local repository copies. This feature transforms source control from "local file operations" to "remote service calls," significantly reducing the complexity of the automation toolchain.

• Hierarchical checkout caching architecture: A three-tier caching system is used: scion-daemon (node-level) → scion-cache (zone-level) → scion-server (authoritative layer), with all layers achieving over 99% hit rates. The caching layers do not require long-term state, making scaling simple. Checkout time is reduced from minutes to seconds.

• Sparse/virtualized checkout: The client only pulls files from the requested directory and instantiates them on demand. File content is only transmitted over the network when it is actually read. This mechanism allows tens of thousands of engineers to share the same massive repository, with each person only retrieving the directories they are responsible for, greatly reducing bandwidth and storage costs.

• Fine-grained access control: Supports access control at both the repository and directory levels, and integrates with the Antique review tool to implement semantic approval constraints. Sensitive code can be protected at the directory level within a large shared repository, without the need to split the repository.

• Low-cost, incremental, and lock-free commits: The cost of creating a commit is proportional to the size of the change, not the size of the repository. Reference updates are atomic operations on a single Spanner record. Without packfiles, locks, or cross-service coordination, Scion can handle high-throughput changeset ingestion, supporting up to 30,000 merges per day.

3. How to Use

Scion is an internal system at Anthropic and is not currently publicly released; external users cannot download or deploy it. However, based on the technical details disclosed by the Anthropic engineering team, we can understand its core usage process:

1. Environment Requirements: Scion relies on Spanner as the metadata storage layer and requires support from a large-scale distributed infrastructure. Clients communicate with the server via the RPC protocol, requiring stable and low-latency network connections.

2. Client Configuration: Developers or AI agents run the scion-daemon process locally, which acts as a node-level cache layer and maintains a bounded local cache. Clients do not need to clone the entire repository; they only need to configure the repository paths and directory ranges they need to access.

3. Creating a Changeset: Agents or developers create a changeset directly on the server using the API, without needing to perform a push operation. Once a changeset is created, it becomes globally visible immediately, and other clients can continue working based on the latest state.

4. Checkout and Read: Clients request directory files on demand, and the scion-daemon first responds from the local cache. If there is a cache miss, it requests from scion-cache and scion-server in a cascaded manner. File content is only transmitted when it is actually read, enabling virtualized checkout.

5. Merge and Rebase: Merge and rebase operations are performed on the server side. Clients initiate requests and receive results via the API. Since the server holds the complete repository state, merge operations do not require negotiation between clients.

6. Access Control: Administrators configure repository-level and directory-level access permissions through the control plane. Combined with the Antique review tool, semantic approval constraints are set to ensure that changes to sensitive code require approval under specific conditions.

4. Pros and Cons Analysis

5. Comparative Analysis with Similar Tools

Selection Recommendations: For large organizations where AI agents are the primary developers and daily commit volume reaches tens of thousands, Scion's architectural philosophy is most valuable—server-side prioritization, API-driven design, and horizontal scalability are key to handling the surge of automated development. However, due to its non-open-source status, external teams may consider Meta Sapling as an alternative, which introduces server-side optimizations while retaining Git compatibility.

For small and medium-sized teams or organizations relying on the Git ecosystem, standard Git combined with a hosting platform (e.g., GitHub/GitLab) remains a practical choice. Scion's concepts such as "no local repository, fully API-driven, hierarchical caching" can serve as directional references for optimizing Git workflows.

6. Editor's Summary

Scion represents a significant shift in the design philosophy of version control systems—from being "designed for human developers" to "designed for AI agents." The extreme scenarios faced by Anthropic, including 30,000 merges per day and a 12-fold increase in code volume over four months, have exposed the limitations of traditional Git architectures. Scion's core innovation lies in completely rethinking the fundamental assumptions of VCS: clients no longer hold the full repository, commits are performed on the server side, queries are exposed via APIs, and caching is deployed in layers. These design choices collectively achieve remarkable results, including a 200-fold reduction in resource consumption and a two-order-of-magnitude improvement in checkout speed.

From a technical perspective, Scion's change set model and derived data mechanism offer broad reference value. The pre-recorded log of file changes relative to the parent commit naturally fits high-concurrency write scenarios; the index built recursively based on change sets supports hot-swapping, providing a flexible data layer for repository analysis. The three-tier caching architecture (daemon → cache → server) is also worth emulating, as hit rates exceeding 99% across all layers demonstrate that the on-demand data retrieval model is practically viable in large repository scenarios.

Scion's practical value is primarily reflected in three aspects: first, it addresses the infrastructure bottlenecks caused by the exponential growth of AI-generated code; second, its fully API-driven design simplifies the complexity of CI and toolchains; third, its fine-grained access control provides security guarantees for large shared repositories. The primary users are infrastructure engineers, DevOps teams, and technical decision-makers on AI development platforms.

7. Application Scenarios

• High-frequency Code Submission by AI Agents: After completing coding tasks, agents directly create change sets on the server via API, without needing to maintain a local repository, supporting tens of thousands of merges per day. In this scenario, Scion's lock-free, server-side submission model eliminates concurrency bottlenecks, allowing AI programming assistants to continuously and efficiently contribute code.

• Large-scale CI Execution Without Checkouts: CI jobs directly call RPC to obtain diff, blame, and merge base information, and can even perform write operations without checkouts. Daily checkouts in the millions are no longer a bottleneck, reducing CI pipeline startup time from minutes to seconds and significantly improving development feedback efficiency.

• Multi-team Collaboration in Large Monolithic Repositories: When tens of thousands of engineers share the same repository, sparse checkouts allow each person to pull only the directories they are responsible for, with directory-level permissions protecting sensitive code. This scenario validates Scion's feasibility in ultra-large-scale organizational collaboration, avoiding the integration costs that come with splitting repositories.

• Automated Operations and Regression Localization: Automated bisect and revert pipelines query commit ancestor relationships through programmatic interfaces, enabling large-scale rollbacks of problematic changes. Scion's derived data mechanism and API-based querying capabilities make these automated operations possible without rebuilding the repository state locally.

8. FAQ

Q: What is the core difference between Scion and Git?
A: Scion moves operations such as commits, merges, and rebases entirely to the server side, retaining only a bounded cache on the client side and fetching data on demand. In contrast, Git requires each clone to be a complete self-contained repository, with commits first completed locally before being pushed. Scion's change set model is lock-free and does not use packfiles, supporting full horizontal scalability and designed for AI agents operating in a "permanently online" mode.

Q: Does Scion support offline development?
A: No. Scion is designed with the premise that the client is always online, and all source code control queries are provided via API. In offline scenarios, the client cannot create change sets, query history, or perform merge operations, which is a stark contrast to Git's offline-first design.

Q: How does Scion achieve high-throughput commits and merges?
A: Scion uses a pre-write log to record change sets, making the cost of creating a commit proportional to the size of the change rather than the size of the repository. Reference updates are atomic operations on a single Spanner record, lock-free and without cross-service coordination, allowing the server to receive change sets at high throughput and support up to 30,000 merges per day.

Q: Can external teams use Scion?
A: Not currently. Scion is an internal system at Anthropic and has not been publicly released. External users cannot download or deploy it. The Anthropic engineering team has shared its architectural design on their official blog, but no usable open-source code or deployment tools have been provided.

Q: How does Scion's three-tier caching architecture work?
A: Scion employs a three-tier caching system: scion-daemon (node-level) → scion-cache (zone-level) → scion-server (authoritative layer). Client requests are first responded to by the daemon layer. If there is no cache hit, the query proceeds up the hierarchy. Each tier achieves a hit rate of over 99%. The caching layers do not require long-term state, making scaling simple and checkout times reduced from minutes to seconds.

9. Project Links

• Project Website: https://www.anthropic.com/engineering/redesigning-source-control (Official technical blog of the Anthropic engineering team, publishing architectural design details of Scion)