专为 AI Agent 重构版本控制：Anthropic 打造自研系统 Scion 替代 Git

在 Anthropic，编写代码已不再是构建系统或开展研究的瓶颈。Claude 能够以我们前所未见的速度与规模，自主迭代研究循环、对复杂程序进行微调优化，并从零构建新服务。如今的瓶颈，转移到了所有专为人类工作规模设计的开发者基础设施：版本控制、构建系统以及 CI（持续集成）。

2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；而到了 9 月，我们每天合并的变更超过 30,000 次。我们预计这种增长速度短期内不会放缓；合并代码的潜在需求几乎是无限的，我们消除的每一个瓶颈都会立即转化为代码产出量的进一步提升。

为了支撑这种增长，我们构建了内部版本控制系统 Scion，并在五个月内将 Monorepo（单体代码仓库）完全从 Git 迁移出来。在同一时期，我们还构建并上线了代码审查界面（名为 Antique）、代码搜索系统、功能完备的版本控制 IAM 权限系统，以及用于管理和落地海量经审查代码的全新方案等。在本文中，我们将重点探讨 Scion 的构建过程。这是一个极具代表性的案例：Claude 编写代码的能力既是最初让我们面临这一困境的根源，也是我们能够迅速构建出一套高质量、可扩展系统来化解该难题的利器。

拓展 Monorepo

在探讨我们构建了什么之前，有必要先说明我们的工作负载有多么特殊。不足为奇的是，Anthropic 使用 Claude 编写软件的频率远超几乎任何其他公司，因此我们往往最先观察到专为人类规模设计的工具何时开始不堪重负。版本控制系统只是其中一例。虽然我们预计短期内不会有很多机构遭遇类似问题，但我们相信用不了多久，其他使用 AI 编程工具的团队也会感受到同样的压力点，这也是我们希望分享自身构建经验与心得的原因。

Git 是一个去中心化系统：每个克隆出来的副本都是一个完整、独立的仓库，能够在完全离线的情况下计算 diff、读取提交历史与 blame，并检出任意修订版本。对于绝大多数代码仓库而言，这是完全正确的设计，也是 Git 成为行业标准的重要原因。

但随着我们 Monorepo 的持续膨胀，它越来越无法适应这种设计模式。仅我们主分支（main）的历史记录就接近 100 GB，一个压缩后的工作副本就超过 25 GB。在未计算开发者本地环境、Agent 沙箱和研究任务之前，我们每天仅在 CI 中执行的代码检出就高达 2500 万次。如果直接朴素拉取，每天的 Git 流量将超过 600 PB。

Git 提供了处理仓库切片的工具，例如浅克隆（shallow clones）、稀疏检出（sparse checkouts）和 promisor remotes。除此之外，处理超大 Monorepo 还有一些常规变通方案，例如内部 Git 镜像和保存在 Blob 存储中的仓库快照（seeds）。这些方法我们全部用过——在业务峰值期，我们曾运行了数百个内部 Git 镜像来应对负载。这虽然为我们争取了时间，但随着代码合并速率提升，维护难度急剧增加。在两次刷新间隔期，Seeds 快照与 main 主分支最新提交点脱节得越来越严重；而在部分克隆的副本上保证 diff、blame 等依赖历史记录的操作正常工作，也需要投入越来越多的精力。

退一步来看，我们发现与大多数公司一样，我们虽然将 Git 当作拥有单一权威副本的中心化系统来使用，但几乎所有的客户端在定义上都是全天候在线的 Agent 和作业。那些让 Git 在分布式、离线环境下表现出色的特质，随着仓库规模的膨胀，反而在严重削弱我们的横向扩展能力。于是我们思考：如果我们从一开始就基于「Agent 始终在线」这一事实来设计版本控制系统，它应该是什么样子？

面向 Agent 规模版本控制的核心原则

随着 Agent 编码时代的到来，关于软件开发的许多传统假设正在发生改变。在构建 Scion 时，我们顺应了这些变化，从而在多项核心原则上采取了与 Git 截然不同的设计取向。针对超大 Monorepo 的版本控制系统已有先例，尤其是 Google 的 Piper 和 Meta 的 Sapling，因此我们在构建 Scion 时得以充分借鉴它们积累的宝贵经验。我们的核心设计原则包括：

客户端始终在线。 Git 假设客户端需要离线工作且必须持有仓库的完整副本。鉴于我们绝大多数客户端都是 Agent 和自动化作业，我们将 Scion 的客户端与通信协议围绕「服务端随时可达」来设计，让客户端仅在需要时按需获取数据。

客户端-服务端不对称。 在 Git 中，每个客户端都具备充当完整服务端的能力。而在 Scion 中，由服务端负责解答文件历史与 blame 查询、创建 commit、执行 merge 与 rebase 等计算密集型操作。客户端仅维护一个受限的本地对象缓存，在磁盘上排布工作副本文件，监控文件系统变动，并为用户提供与服务端交互的人性化接口。客户端自身几乎不执行复杂计算，以此换取极低的本地数据占用。

功能完备的版本控制服务可赋能众多创新应用。 在 Git 中，若 CI 任务或工具需要查询仓库信息（例如某行代码由谁修改、两个 commit 之间有何关联），就必须在本地保留一份仓库副本，或者寄希望于特定托管平台的专有 API。在 Scion 中，客户端使用的所有版本控制查询均通过 API 对外暴露，因此许多情况下自动化任务根本无需在本地准备代码仓库。若没有这种低成本、程序化的版本控制访问能力，诸如自动二分查找（bisect）和回滚（revert）流水线等许多内部工具在规模化运作下将完全不切实际。

一切皆可横向扩展。 峰值期我们运行了数百个 Git 镜像，这对容量造成了巨大负担，且一旦仓库体积超出镜像服务器的磁盘或内存极限，就再也无法扩容。在 Scion 中，仓库数据完全分布式存储，每个组件均可独立扩容；无论何处都不存在仓库的完整物化实体，即便在服务端也是如此。系统没有类似 packfiles（Git 的打包对象压缩包）的机制，因此无需运行仓库维护任务。

提交必须廉价、增量且无锁。 在 Git 中，你在本地进行 commit，然后通过 push 共享工作成果。在 Scion 中，所有的 commit、rebase 或 merge 均发生在服务端，无需任何 push 操作，但每个操作都必须极快。创建 commit 以及更新下游数据结构的开销必须根据本次变更的大小（而非整个仓库的体积）来伸缩，否则服务端将无法承受。Scion 的开发流程不鼓励使用 refs（分支、标签等指向 commit 的指针，除 main 分支或发布分支外），因为所有服务器必须达成一致的全局状态是一个隐蔽的扩展瓶颈。

工作副本可由按需配置，天然具备稀疏性。 鉴于单体仓库极其庞大，且我们每天为 CI 检出代码数千万次，我们希望尽可能避免检出操作。借助 Scion，需要获取某个 commit 与其 merge base 之间 diff 的 CI 任务可以直接向服务端请求。写入操作同样如此：许多写入工作负载也可以跳过本地检出，完全通过 API 进行。Scion 的协议以稀疏检出（仅包含客户端请求的目录）和虚拟化检出（按需动态物化文件）为核心，因此当任务确实需要在磁盘上准备文件时，客户端仅需为其实际读取的数据付出开销。

Scion 的工作原理

理解这些原则在构建 Scion 时的实际落地方式很有帮助。这些经验不仅适用于其他版本控制系统，也更广泛地适用于软件开发生命周期的其他阶段。

数据结构

在 Scion 中，最小工作单元是一个「变更集」（changeset），即预写日志（WAL）中的一个条目。Changeset 保存了你在 Git commit 中能见到的大部分信息。但 Git commit 保存的是指向文件树（tree）的指针，而 changeset 保存的则是相对于其第一个父节点的变更文件列表，以及指向 Blob 存储中压缩文件内容的内容寻址指针。Changeset 在服务端创建，可瞬间全局同步可用。

这种结构使我们能够以极高吞吐量接入变更集，因为无需接收 packfile，无锁且无需跨服务器协调，也不必移动 ref 指针。Scion 在技术上确实支持 ref，但创建与拉取 commit 都不涉及它们，移动 ref 仅是对单个 Spanner 行执行 CAS（比较并替换）操作，与创建 changeset 是解耦分开的。

Changeset 仅记录了改动内容，因此它本身无法快速回答「谁最后编辑了这行代码」或「哪些 commit 影响了该文件」等问题。为了回答这些问题，Scion 从 changeset 中派生出额外的数据结构，包括专用于文件 blame 和路径历史记录的数据结构，以及用于 commit 图的跳表（skip list）。我们将所有不直接属于 changeset 的数据统称为「派生数据」（derived data），并通过一套通用机制进行计算。每种类型的派生数据均采用递归定义，因此某个 changeset 的派生数据值，是根据其父节点的对应值计算而来的。

这一机制带来了三大优势：第一，当新数据结构能加快某类操作时，我们可以轻松添加新类型的派生数据；第二，对于每种类型，我们可以自由选择即时计算还是延迟计算，从而避免物化不需要的数据；第三，由于客户端永远接触不到这些数据结构的内部实现细节，我们可以在完全不修改客户端的情况下对其进行优化。随着系统规模增长，我们已多次新增派生数据类型，例如用于检测代码复制或基于路径进行文件检索的新索引。

扩展 Scion

由少量 Scion 服务器构成的集群提供了客户端所需的任意版本控制 API，例如获取 changeset、计算 diff、寻找 merge base 以及拉取 blob。所有版本控制数据均采用内容寻址，因此数据一旦存储便不可更改，任何服务器都可以直接缓存，无需与其他节点协商。这使得服务器可以轻松横向扩展，几乎不需要协同。它们本质上是超大型缓存层，同时能够实时计算派生数据并将结果写回 Spanner。

Scion 的众多下游调用方不再需要在本地维护自身仓库。过去，拉取与维护仓库对于需要查询版本控制数据（尤其是 commit 祖先关系与 blame）的 CI 任务或自动化工具而言是巨大的维护负担。在迁移初期，在我们尚未拥有专有客户端、仓库格式或协议之前，Scion 仅用于响应这些「元数据」查询。拉取文件内容与物化工作副本属于数据密集度高得多的操作，需要一套独立的设计方案。

Scion 的 scn 客户端在多个重要维度上偏离了 Git 的拉取协议，从而构建出一套扩展能力极高、CPU 消耗远低于 Git 服务器的架构。Scion 的通信协商不会告诉服务端客户端已经拥有了什么，而是完全针对客户端当前需要的 tree 和 blob 展开操作。从根节点 tree 开始，客户端检查本地存储中缺失的 tree 并递归发起请求，随后对 blob 重复该过程。每个请求都指向一个不可变的特定对象，因此任何缓存层均可直接响应，架构形态与传统多层缓存极为相似。该流程高效且支持断点续传，因为不存在单一多 GB 级别的 packfile 响应。稀疏检出甚至虚拟化检出无需特殊协议支持，因为客户端只需直接忽略那些不想要的 tree 请求即可。

在机器节点集群中，客户端通过本地 socket 与守护进程 scion-daemon 通信，该守护进程为整台机器节点统一缓存管理对象。我们的大多数节点都需要访问该 Monorepo，而同一节点上的不同任务通常会复用绝大部分对象。每个守护进程基于定期刷新的快照启动，且仅与其所在区域的 tree 和 blob 缓存服务器（称为 scion-cache）通信。这些缓存服务器以守护进程可直接读取的磁盘格式直接从内存流式传输对象，因此无需耗费时间计算客户端缺失了哪些对象，也无需执行增量 delta 压缩。当缓存层缺失某个对象时，它会向权威的 scion-server 请求，由后者按需从 Spanner 或云存储中读取。

scion-daemon、scion-cache 和 scion-server 在该协议中响应完全相同的 RPC 请求，因此客户端无需感知缓存拓扑。理论上任何层级都可以相互通信，但我们严格执行分层限制以隔离故障域，防止区域 scion-cache 故障导致上游 scion-server 被流量击垮而引发全盘雪崩。

该系统的每一层缓存命中率均保持在 99% 以上，且无需长期保留状态，因此在需要时极易进行扩容。在 CPU 和内存占用方面，如今 Scion 基础设施的资源消耗比先前的 Git 镜像设施足足缩小了 200 倍。CI 和研究任务的代码检出速度提高了两个数量级（从数分钟缩减至数秒），从而在全集群范围内释放了可观的计算容量；仅 CI 一项就实现了 25% 的 CPU 算力节约。客户端与缓存层均无需进行仓库运维维护，极大简化了各项作业的生命周期管理。

构建 Scion 的经验教训

我们在构建 Scion 时，大约正值 [

At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months. We also built and shipped a code review surface (called Antique), code search, a rich source control IAM system, novel ways of managing and landing large amounts of reviewed code, and more, all in that same time period. In this post, we’ll focus on how we built Scion specifically. It makes for an interesting case study: Claude’s ability to write code was both what put us in this situation in the first place and how we were able to quickly build a high-quality, scalable system to deal with it.

Growing our monorepo

Before we explore what we built, we should acknowledge how unusual our workload is. Unsurprisingly, Anthropic uses Claude to write software far more than almost any other company, so we’re often the first to see where tools built for human scale start to strain. Source control is just one example of this. While we don’t expect many organizations to have these problems in the very near term, we suspect it won’t be too long before others who use AI coding tools experience these same pressure points, which is why we wanted to share what we built and what we learned.

Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design, and it’s a large part of why git became the standard.

As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

Git offers tools for working with a slice of a repository, such as shallow clones, sparse checkouts, and promisor remotes. Beyond these, there are standard workarounds for large monorepos, like internal git mirrors and repository snapshots (seeds) kept in blob storage. We’ve used all of them—at our peak, we operated several hundred internal git mirrors to deal with the load. This bought us time, but they became harder to operate as our merge rate increased. Seeds fell further from the tip of main between refreshes, and it took more and more care to keep operations that depend on history, like diff and blame, working on partial clones.

Taking a step back, we noticed that, like most companies, we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew. So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like?

Principles for agent-scale source control

With agentic coding, many common assumptions about how software is developed are evolving. We embraced these changes when building Scion, which allowed us to take a fundamentally different approach than git on several core principles. Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling,2 so we were able to build Scion with their hard-won lessons in mind. Our principles are:

Clients are always online. Git assumes that clients work offline and need a complete copy of the repository. Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable, and have clients fetch data when they need it.

Client-server asymmetry. In git, every client is capable of being a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on. The client maintains a bounded local object cache, lays out the working copy files on disk, monitors for filesystem changes, and gives users an ergonomic way to work with the server. It can compute very little on its own but, in exchange, it requires much less data locally.

A comprehensive source control service can power many novel applications. With git, a CI job or tool that needs to ask a question about the repository, such as who last changed a line or how two commits are related, has to maintain a local copy of the repo or hope that vendor-specific APIs provide the answer. With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all. Many internal tools, such as our automated bisect and revert pipelines, wouldn’t be practical at scale without this cheap, programmatic access to source control.

Everything must be horizontally scalable. At our peak, we ran several hundred git mirrors, which significantly strained capacity and no longer scaled once the repo outgrew the mirrors’ disks or memory limits. In Scion, the repository’s data is distributed, and every component is independently scalable; there is no fully materialized copy of the repo anywhere, even on the server. There is no equivalent of packfiles (git’s compressed bundles of objects), so no repository maintenance is needed.

Commits must be cheap, incremental, and lock-free. In git, you commit locally and then push to share your work. In Scion, every commit, rebase, or merge happens on the server, so there’s nothing to push, but each of those operations needs to be fast. The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo, or the server can’t keep up. The development lifecycle in Scion discourages refs (pointers to commits, such as branches and tags), except for the main ref or release branches, because global state that every server has to agree on is a looming scaling problem.

The working copy is optional, and sparse by design. Because our monorepo is so large, and because we check out code tens of millions of times a day for CI, we wanted to avoid checkouts whenever we could. With Scion, a CI job that needs the diff between a commit and its merge base, for example, can ask the server for it. The same goes for writes: many write workloads can also skip the checkout and function entirely via API. Scion’s protocol is centered around sparse checkouts, which only contain the directories the client asks for, and virtualized checkouts, which materialize files on demand, so when a job does need files on disk, the client only pays for what it actually reads.

How Scion works

It’s helpful to understand how these principles came together in practice when building Scion. These insights can apply to other source control systems or, more broadly, to other stages of the software development lifecycle.

Data structures

In Scion, the unit of work is a “changeset,” an entry in a write-ahead log. A changeset stores most of what you’d expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent,1 along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere, instantly.

This structure lets us accept changesets with very high throughput because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Scion does technically support refs, but since neither creating nor fetching commits involves them, moving one is a compare-and-swap on a single Spanner row that happens separately from creating changesets.

A changeset records only what’s changed, so on its own, it can’t quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn’t directly part of the changeset “derived data,” and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset’s parents.

This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don’t need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We’ve added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search.

Scaling Scion

A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and fetching blobs. All source control data is content-addressed, so a piece of data never changes once it’s stored, and any server can cache it without checking with the others. As a result, the servers are horizontally scalable and require little coordination. They are essentially large caches that can also compute derived data on the fly and write the results back to Spanner.

Scion’s many consumers no longer need to maintain local repositories of their own. Fetching and maintaining the repository used to be a significant maintenance burden for CI jobs or tools that needed to ask source control questions, particularly about commit ancestry and blame. Early in the migration, before we had our own client, repo format, or protocols, Scion only answered these “metadata” queries. Fetching file contents and materializing working copies are far more data-intensive operations, and they needed a design of their own.

Scion’s scn client deviates from git’s fetch protocols in several important ways and, as a result, lends itself to a highly scalable architecture that requires significantly less CPU than git servers. Scion’s negotiation doesn’t tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific object that never changes, so any cache can answer it, and the architecture closely resembles traditional tiered caches. The process is also efficient and resumable, because there is no single multi-gigabyte packfile response. Sparse and even virtualized checkouts don’t need special support, because the client simply doesn’t ask for trees it doesn’t want.

In the fleet, the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node. Most of our nodes need access to the monorepo, and jobs on the same node reuse most of the same objects. Each daemon starts from a periodically refreshed snapshot, then talks only to the tree and blob cache servers in its region, called scion-cache. These cache servers stream objects directly from memory, in the disk format that the daemon will consume, so they don’t need to spend time computing the client’s missing objects or performing delta compression. When a cache is missing an object, it asks the authoritative scion-servers, which read from Spanner or cloud storage as needed.

The scion-daemon, scion-cache, and scion-server all respond to identical RPCs for this protocol, so the client doesn’t need to know the cache topology. Any tier could theoretically talk to any other, but we strictly enforce the tiering to isolate failure domains. We want to avoid a situation where a failure in a regional scion-cache overwhelms the upstream scion-servers and brings down the entire system.

Each tier of this system maintains a cache hit rate of over 99% and does not require long-lived state, so it’s easy to scale up if needed. Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance, which simplifies the lifecycle management of our jobs.

What we learned building Scion

We started building Scion around the same time as Claude Mythos Preview and Claude Tag became available internally. Both of these releases simultaneously amplified the need for Scion __ and meaningfully accelerated how quickly we could build it.

Here’s a particularly striking example. Earlier in the year, we had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. We thought it was good—until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures.

What we learned building and operating Scion offers some interesting lessons for what building agent-scale software could look like.

Rapid development with a small team will become more common. A team of seven people built both Scion and Antique (our code review tool, which we could easily write a whole other blog post about), not to mention half a dozen related systems, and fully migrated to them in five months. We did all this while the volume of code merged per day increased by 10x. In the past, developing and deploying a source control system like this would have taken a company years of iterative migration, with many more engineers. We think this sort of fast, nimble migration will become more common in the future.

Engineers are no less valuable, but their work is changing. All of the engineers who worked on this system would now rate Claude as better at writing code than them. But our engineers still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs, making informed choices around the problems we wanted to solve and the scale we knew we needed to achieve. Very often, we found that the role of the engineers was to tell Claude “no.” Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. This was particularly common in our migration. For example, there were multiple systems that tried to brute force looking up when a change merged to main by linearly reading the commit log instead of asking our code review tool. Anthropic also makes extensive use of adversarial review, and, while this is incredibly effective in many ways, it can also be myopic, so skilled engineers needed to steer Claude away from over-engineering parts of the system in response to hypothetical concerns. For example, one such review was overly defensive about trusting another internal service, which resulted in Claude adding excessive validation and complexity. Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.

We were able to substantially improve optimization and quality. By virtue of Claude’s ability to write immense amounts of code much faster than we could ourselves, Scion is among the most well-tested and well-defended codebases we have ever worked on. Even on our tight timeline, we were able to build hermetic simulations of every non-trivial infrastructure and source control interaction we’ve ever encountered, as well as fuzzing and sophisticated rate limiting. Claude also casually found significant optimizations—for example, an algorithmic optimization to ancestry queries that missed one of our indexes—that would have taken an expert days or weeks of analysis and tuning… and then did it all again the next day.

We laid the groundwork for new forms of monorepo security. Managing safety, security, and compliance in a massive monorepo is as important as managing the size and scale. We built Scion with these in mind from the start. It supports rich access control on repositories, as well as the ability to apply permissions to individual directories in order to protect the most sensitive code without losing the benefits of a monorepo. Furthermore, the code review tooling we built can express complex semantic constraints on approvals, which lets us differentiate simple things like comment-only changes from sensitive logical changes, so that human reviewers can focus on the most consequential changes.

A new level of operational excellence is possible. Our team uses Claude Tag heavily, which has helped us monitor each component of the system. For example, we created Slack channels where we tasked Claude with being obsessively focused on the health of a single component. We call these Claudes “superfans.” We have a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, and so on. They have access to our telemetry and logs, and act like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange. We also have traditional alerts for all of our systems, but our superfans can detect subtle and novel issues that make these alerts seem one-dimensional by comparison.

We’re completely rethinking our priors. This project prompted us to take a very hard look at other workflows designed for human scale. A proper merge queue, for example, doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running? We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing. This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them.

Contributing to the wider ecosystem

We see Scion as just one part of the answer to the scaling concerns that increasingly capable AI agents have raised. We’re sharing these details as an example of how teams can tackle similar challenges, though we don’t expect our solution, or our considerations, to suit every case.

Scion is by no means a suitable replacement for git for general use. The concepts we’ve outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Plus, Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. We do this both to address our own software development needs, and to test Claude’s capabilities.

Practically speaking, it’s difficult to offer Scion in a form that would be broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI. Our internal versions of these components are highly bespoke, so they would be difficult for other organizations to adopt, and we worry that attempting to build a public version that tries to please everyone wouldn’t actually be very useful.

However, we anticipate that this class of problems will become more commonplace over the next six to 12 months, and it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Given that, we think the most impactful __ thing we can do is to share our thinking, so that other developers can apply some of the most successful parts of Scion to git without departing from the overall model. A git server doesn’t have to work the same way as a git client does; novel server architectures exist that provide significant scaling improvements. Git platforms can provide comprehensive server-side RPCs like Scion, perhaps even in a standardized way across forges that the git client can learn to talk to. The negotiation protocol doesn’t have to look exactly like it does today, either, and the various sparse and shallow features in git can be made to compose well.

Lastly, we want to acknowledge that the git community has spent nearly two decades scaling the platform for millions of developers. Our contribution is far narrower: sharing our early view into how agentic software development interacts with these systems, so that we can partner with GitHub, GitLab, and the OSS community to support the changing needs of developers. We’re all in it together as the software development lifecycle intersects with the AI exponential.