Why would an AI company build its own version control system when Git already powers so much software development? The reported explanation for Anthropic’s Scion is a mismatch between a familiar development model and an increasingly automated workload: a large monorepo, rapidly rising change volume, and AI agents and continuous integration jobs that need fast access to code.
The central idea is not that Git stopped being useful. It is that maintaining and distributing repository state reportedly became an infrastructure bottleneck. Scion takes a different approach: keep code on a server, let clients retrieve the files they need, and create commits on the server rather than requiring a separate push.
The Short Answer: Source Control Reportedly Became the Bottleneck
According to the report, Anthropic’s daily merged changes increased from approximately 2,500 in May to more than 30,000 by September. That is roughly a twelvefold increase. The account does not identify the year, so those months should not be presented as a complete timeline.
At that reported scale, the question changes. A source control workflow is no longer judged only by whether an individual developer can comfortably use it. It also has to support many automated consumers preparing workspaces, retrieving files, recording changes, and feeding subsequent checks.
The stated motivation for Scion was therefore operational: Anthropic reportedly moved its monorepo away from Git after source control became a limiting part of its engineering infrastructure.
I interpret this as a workload-specific decision, not a general verdict against Git. A system that works well for distributed human collaboration may involve avoidable overhead when many of its clients are online automation jobs.
What Is Scion?
Scion is described as Anthropic’s custom version control system for its monorepo. The available account identifies three important characteristics:
- Server-resident code: repository content remains on a server.
- Selective retrieval: clients download the files they need rather than necessarily obtaining a complete local repository.
- Server-side commits: changes are committed directly on the server, without a separate push step.
Those characteristics suggest a system organized around shared infrastructure and connected clients. They do not, by themselves, establish its storage format, branching model, conflict-resolution behavior, or compatibility with existing Git tools.
Calling Scion “Anthropic’s own Git” is understandable shorthand, but it can be misleading. The significant point is not simply that another version control tool exists. It is that the reported design changes where repository state lives and how clients interact with it.
Did Anthropic Replace Git Everywhere?
The available account describes a monorepo migration. It does not establish that every Anthropic repository, public project, or development workflow stopped using Git.
I would keep the claim narrow: Anthropic reportedly replaced Git for the monorepo discussed in the account. A company-wide statement would require additional evidence.
Why AI Agents Change the Version Control Equation
The reported rationale rests partly on a shift in who, or what, uses source control. Human developers remain important, but AI agents and CI jobs can become substantial consumers of repository infrastructure.
These consumers may have different needs from a developer maintaining a long-lived local workspace.
A Human Workspace and an Automated Job Have Different Priorities
Git’s distributed model supports local repository operations and disconnected work. Those are valuable capabilities when a developer needs to inspect history, create commits, and continue working without constant access to a central service.
An always-connected automated job may value something else more: obtaining the required files quickly, performing a bounded task, and recording the result.
That does not mean every automated job needs only a small part of a repository. The useful distinction is that not every client needs the same amount of repository state or the same degree of independence.
Repeated Setup Can Become an Aggregate Cost
Consider a hypothetical agent assigned to change one component in a large codebase. It needs the relevant files, enough context to make the change, and whatever inputs its checks require.
If preparing that workspace takes substantially longer than necessary, the delay is repeated each time a similar task begins. Across many jobs, workspace preparation becomes an infrastructure concern rather than a minor inconvenience.
This example illustrates the reported motivation; it is not a description of Anthropic’s exact internal task flow. The underlying question is practical: how much work must the source control system perform before useful engineering work can start?
Online Clients Make a Different Trade-Off Possible
The account emphasizes that many clients are AI agents and CI jobs that are already online. Under that assumption, a central service can take on responsibilities that a distributed workflow places on local repositories.
I see that as the key architectural trade: accept greater reliance on a shared service in exchange for reducing work performed repeatedly by individual clients.
How Scion’s Reported Design Addresses the Problem
The most useful way to understand Scion is to connect each reported design choice to the overhead it is intended to avoid.
1. Keep Repository State on the Server
In the reported model, code remains server-side. Clients interact with that shared repository rather than treating a full local repository as the default starting point.
The intended benefit is less duplication of repository-related work across consumers. However, the available information does not explain what Scion caches locally or how much repository metadata a client retains.
Those details matter. “Server-side” describes the broad architecture, not every storage or performance characteristic.
2. Retrieve Files According to the Task
Selective retrieval aligns workspace preparation with the files a client actually needs.
For a narrowly scoped task, that can be a more appropriate starting point than preparing a much broader workspace. But the task’s real dependency boundary still matters: tests, build configuration, and related components may require more than the files being edited.
I would therefore read “download only what is needed” as a design goal, not a promise that every task touches very little data.
3. Record Commits on the Server
The account says commits happen directly on the server, eliminating a separate push operation in that workflow.
This changes the interaction model. Instead of creating a local commit and subsequently transferring it to a remote, the client records the change through the server-side system.
It does not follow that review, testing, or merge decisions disappear. The available material does not describe how those processes work in Scion, so they should not be inferred from the absence of a push step.
What the Reported 200x Efficiency Improvement Actually Means
The most striking claim is that Scion used approximately 200 times less CPU and memory than the previous mirroring setup. The account also says checkout times fell from minutes to seconds.
Those are potentially significant results, but their scope matters as much as their size.
The Comparison Is to a Particular Mirroring Setup
The reported baseline is Anthropic’s previous mirroring infrastructure. It is not a universal comparison between Scion and every possible Git deployment.
I would not turn that claim into “Scion is 200 times faster than Git.” That would change both the measured resources and the scope of the comparison.
- CPU and memory consumption describe resource use.
- Checkout time describes the latency of a particular operation.
- Engineering throughput concerns how much useful work the broader development process completes.
Improvement in one can help another, but they are not interchangeable measurements.
Minutes to Seconds Needs More Context
The reported checkout improvement suggests faster workspace preparation. Without exact timings and workload definitions, however, there is no defensible basis for calculating a precise speedup.
For a serious comparison, I would want to know:
- Whether measurements used cold or warm caches.
- How much content each checkout retrieved.
- Whether the workloads were equivalent before and after migration.
- Whether the figures represented typical latency or slower cases.
- Which client-side and server-side resources were included.
These questions do not invalidate the reported result. They identify what is needed to interpret it accurately.
Why Build a New System Instead of Improving Git Infrastructure?
This is the most important unanswered comparison. A source control bottleneck does not automatically prove that replacing the version control system is the best solution.
Before making that decision, I would separate three possible problems:
- Repository access: clients take too long to obtain the content they need.
- Supporting infrastructure: mirroring or workspace preparation consumes excessive resources.
- Workflow mismatch: the operating model repeatedly requires capabilities that the workload does not need.
The first two may point toward improving the existing setup. The third provides a stronger reason to consider a different architecture.
The available account suggests Anthropic saw a deeper mismatch: large numbers of connected clients were being served through infrastructure built around a different repository interaction model. It does not document every alternative the company evaluated.
That distinction prevents a common leap in reasoning. A successful custom system can demonstrate that a specialized design fits one environment well without proving that every less disruptive option was inadequate.
The Trade-Offs Behind a Custom Version Control System
Building Scion would not merely exchange one command-line tool for another. A custom source control system becomes part of the organization’s critical engineering infrastructure.
Service Reliability Becomes Central
If clients depend on a server to retrieve code and record commits, the server’s availability and responsiveness become important workflow concerns.
The supplied material does not describe Scion’s reliability mechanisms. I would treat resilience, recovery, and behavior during connectivity problems as essential evaluation questions, not assume they have any particular implementation.
Compatibility Requires Examination
Development workflows often connect source control with editors, review processes, automation, and release tooling. A replacement needs a workable relationship with those surrounding systems.
There is not enough information here to say whether Scion offers Git compatibility, a translation layer, or an entirely different interface. Claims of a seamless migration would therefore be premature.
Ownership Continues After Launch
A custom system needs ongoing maintenance, operational support, and migration planning. Performance gains must be considered alongside that responsibility.
My decision rule would be straightforward: build only when the measured benefit addresses a persistent bottleneck and justifies long-term ownership. A compelling infrastructure result is not automatically a compelling choice for a smaller team.
What Other Engineering Teams Can Learn
The practical lesson is to investigate workload fit before copying the architecture.
I would use this checklist when evaluating whether source control is becoming a limiting factor:
- Measure preparation time. Separate repository access and checkout from builds, tests, and other setup.
- Identify the consumers. Distinguish interactive developers, AI agents, CI jobs, and other automation.
- Measure content requirements. Determine how much repository content each task actually uses.
- Find repeated work. Look for expensive preparation that many clients perform independently.
- Define the constraint. Decide whether latency, CPU, memory, or another measured resource is limiting throughput.
- Compare options fairly. Evaluate improvements to the current setup alongside replacement.
- Include ownership costs. Account for operations, compatibility, recovery, and maintenance.
This approach keeps the decision grounded in evidence. “AI agents use our repository” is not, by itself, a sufficient reason to build a version control system.
Top comments (0)