Scion (version control)
Scion is an in-house version control system built by Anthropic to replace git for the company's internal monorepo. Anthropic described it in an engineering blog post, "Redesigning source control at Anthropic," published on October 13, 2026. According to the post, the number of code changes merged into the monorepo each day rose from about 2,500 in May 2026 to more than 30,000 in September 2026, and source control became the company's largest development bottleneck. A team of seven people built Scion, together with a code review tool called Antique and several related systems, and fully migrated the monorepo from git in five months.[1] The post presents Scion as a design for "agent-scale" development, in which most clients are AI coding agents and automated jobs rather than people, and it describes how Claude models were used to write and operate the system.[1]
Scion was built for Anthropic's own use, and the post does not announce an external release. It says Scion "is by no means a suitable replacement for git for general use" and that the company intends to share its ideas with git hosting platforms and the open-source community instead.[1]
Background
Anthropic's post says that coding is no longer the main constraint on its engineering and research work, because Claude can autonomously iterate on research loops, optimize complex programs and build new services. The constraint moved to developer infrastructure designed for human-scale use: source control, builds and continuous integration (CI).[1] A chart in the post shows the daily number of merged changes, with a peak of 30,401 merges on September 9, 2026.[1]
The post gives the following figures for the monorepo before the move to Scion:[1]
| Measure | Figure reported by Anthropic |
|---|---|
| History of the main branch | Almost 100 GB |
| Compressed working copy | Over 25 GB |
| Code checkouts for CI per day | On the order of 25 million (not counting developer environments, agent sandboxes and research jobs) |
| Git traffic if every checkout were fetched naively | Over 600 PB per day |
| Internal git mirrors at peak | Several hundred |
To cope with git at this scale, Anthropic said it had used shallow clones, sparse checkouts, promisor remotes, internal git mirrors and repository snapshots ("seeds") kept in blob storage. A diagram in the post shows CI jobs, developer environments, agent sandboxes and research jobs reading through per-cluster packfile caches and mirror replicas, with node seeds restored from snapshots in blob storage. These measures became harder to operate as the merge rate grew: seeds drifted further behind the tip of the main branch between refreshes, and history-dependent operations such as diff and blame needed more care on partial clones.[1]
The engineers concluded that, like most companies, they were running git as a centralized system with one authoritative copy, while nearly all of their clients were agents and jobs that are always online. Git's support for complete offline copies, which the post credits as a large reason git became the standard, worked against scaling in this setting.[1]
Design principles
The post names Google's Piper and Meta's Sapling as prior art for source control of very large monorepos, and says Scion was built with "their hard-won lessons in mind."[1] It lists the following principles:[1]
| Principle | What it means in Scion |
|---|---|
| Clients are always online | The client and protocols assume a reachable server, and clients fetch data when they need it instead of holding a full copy of the repository. |
| Client-server asymmetry | The server answers history and blame queries, creates commits, and performs merges and rebases. The client keeps a bounded local object cache, lays out working copy files, watches for filesystem changes and provides the user interface. |
| A source control service, not just a client | Every query the client uses is also exposed as an API, so many jobs need no local repository. Anthropic says internal tools such as automated bisect and revert pipelines depend on this access. |
| Horizontal scalability | Repository data is distributed and each component scales independently. No fully materialized copy of the repository exists anywhere, including on the server, and there is no equivalent of git packfiles, so no repository maintenance is needed. |
| Cheap, incremental, lock-free commits | Commits, rebases and merges happen on the server, so there is nothing to push. The cost of a commit scales with the size of the change rather than the size of the repository. Refs (branches and tags) are discouraged except for the main ref and release branches. |
| Optional, sparse working copies | Many read and write workloads run entirely through the API. When files are needed on disk, the protocol is built around sparse checkouts and virtualized checkouts that materialize files on demand. |
Architecture
Changesets and derived data
Scion's unit of work is the changeset, an entry in a write-ahead log. A changeset holds most of what a git commit holds (author, dates, message, parents and an optional signature), but where a git commit points to a full tree, a changeset stores only the list of files changed relative to its first parent, with content-addressed pointers to compressed file contents in blob storage. A diagram in the post shows changeset metadata stored in Spanner and file contents stored in cloud storage, immutable, compressed and deduplicated by hash, with root and directory trees derived by the server rather than stored in the changeset.[1] A footnote describes recording changes relative to the first parent of a merge as "a stylistic choice", explaining that in trunk-based development in a monorepo people mostly care about history and blame for commits on the main line.[1]
Because accepting a changeset involves no packfiles, no locking, no cross-server coordination and no ref updates, Scion can accept changesets at very high throughput. Refs are supported, but moving one is a separate compare-and-swap on a single Spanner row.[1]
Information that a changeset alone cannot answer quickly, such as who last edited a line or which commits touched a file, comes from derived data: structures built from changesets, including blame and path-history structures and skip lists over the commit graph. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for the changeset's parents. Anthropic lists three benefits of this single mechanism: new types can be added when a new structure would speed up an operation (the team later added indices for copy detection and path-based file search), each type can be computed eagerly or deferred, and clients never see the internals, so the structures can be changed without changing the client.[1]
Servers, caches and the client
A small fleet of scion-server processes provides APIs for operations such as fetching changesets, computing diffs, finding merge bases and fetching blobs. Since all data is content-addressed and never changes once stored, any server can cache it without coordinating with others. Anthropic describes the servers as "essentially large caches" that can also compute derived data and write it back to Spanner. Early in the migration, before Scion had its own client, repository format or protocols, it answered only these metadata queries.[1]
The scn client fetches data differently from git. Its negotiation does not tell the server which objects the client already has. Instead, starting from a root tree, the client checks its local store for missing trees and requests them recursively, then does the same for blobs. Each request is for one specific immutable object, so any cache tier can serve it, transfers can resume, and there is no single multi-gigabyte packfile response. Sparse and virtualized checkouts need no special support, because the client simply does not request trees it does not want. Anthropic says this design needs much less CPU than git servers.[1]
On fleet machines, clients talk over a socket to a per-node scion-daemon, which starts from a periodically refreshed snapshot and stores objects for every job on the node. On a miss, the daemon asks a regional scion-cache tier, which streams objects from memory in the daemon's on-disk format without computing missing-object sets or delta compression. Cache misses go to the authoritative scion-servers, which read from Spanner or cloud storage. All three tiers answer identical RPCs, so clients do not need to know the topology, but Anthropic enforces strict tiering so that a failing regional cache cannot overwhelm the upstream servers. Separately from this object path, every client, including Antique, sends control-plane requests (branches, history, diffs, uploads, commits and landing changes) directly to scion-server.[1]
Reported results
Anthropic reports that each cache tier keeps a hit rate above 99% and that the Scion infrastructure needs 200 times less CPU and memory than the git mirroring infrastructure it replaced. CI and research jobs check out code two orders of magnitude faster, in seconds rather than minutes, and CI gained 25% in CPU capacity. Neither clients nor caches need repository maintenance.[1]
A chart in the post compares median times for common commands on the monorepo using git and scn:[1]
| Environment | Operation | git | scn | Speedup reported |
|---|---|---|---|---|
| Developer | Pull latest | 87 s | 3.5 s | 25x |
| Developer | Checkout | 15 s | 1.1 s | 14x |
| Developer | Rebase | 13 s | 2.7 s | 4.8x |
| Developer | Status | 3.9 s | 19 ms | 207x |
| Developer | Commit | 1.4 s | 1.1 s | 1.3x |
| Developer | Diff | 407 ms | 67 ms | 6.1x |
| Agent | New worktree | 7.1 min | 5.1 s | 84x |
| Agent | Pull latest | 3.0 min | 9.0 s | 20x |
| Agent | Commit | 18 s | 761 ms | 24x |
| Agent | Status | 4.3 s | under 0.2 s | over 20x |
| Agent | Total source control time per change request | 34 min | 3.7 min | 9.2x (about 11,000 agent hours a day) |
| CI and compute | Checkout at start of compute job | 175 s | 22 s | 8.0x (about 85,000 machine hours a day) |
| CI and compute | Checkout in a CI job | 31 s | 3.5 s | 8.8x (about 195,000 machine hours a day) |
These figures are Anthropic's own measurements. The Japanese technology site GIGAZINE repeated several of them, such as the 25-fold, 207-fold and 84-fold speedups, as reported by Anthropic.[1][2]
Antique
Antique is the code review tool that Anthropic built alongside Scion. The post calls it a "code review surface" and says the same seven-person team built both systems.[1] Charts in the post label merged changes as either pull requests or "Antique change requests." On those charts, pull requests give way to Antique change requests between late May and early July 2026; from July onward almost all merges shown, including changes to the Scion and Antique codebases themselves, are Antique change requests.[1]
Anthropic says its code review tooling can express complex semantic constraints on approvals, for example distinguishing comment-only changes from sensitive logic changes so that human reviewers can concentrate on the most consequential ones. The post also mentions an "Antique merge queue." Writing about merge queues in general, Anthropic said it had not been able to replicate the industry standard of a global repository lock on the merge queue at agent scale, so it relies on post-merge and pre-deploy automated testing instead, accepting that concurrent changes can conflict and having Claude fix the conflicts.[1] The acknowledgements credit "Amir O." with early contributions to Antique. The post does not describe Antique in detail; it says the team "could easily write a whole other blog post" about the tool.[1]
Security features
Scion supports access control on repositories and permissions on individual directories, so the most sensitive code can be protected without splitting up the monorepo. Anthropic also says it built "a rich source control IAM system" during the same five-month period.[1]
Role of Claude in development
Anthropic says it began building Scion at about the time Claude Mythos Preview and Claude Tag became available internally, and that both releases increased the need for Scion while also speeding up its construction.[1] The post gives one example: the team had largely handwritten a prototype of the git-to-Scion ingestion pipeline, then asked an early internal snapshot of Claude Mythos Preview to rewrite it. With no further instructions, the model produced a version that used 20 times less memory and ran 4 times faster while preserving the pipeline's ordering and data-structure invariants.[1] A chart counts 12,257 changes to the scm/ and antique/ directories of the monorepo between January and September 2026.[1]
According to the post, every engineer on the project would rate Claude as better than themselves at writing code. The engineers' contribution was described as system-level design and tradeoff decisions, and frequently telling Claude "no" when it tried to violate core constraints. The post says this was particularly common during the migration; one example was several systems that tried to find when a change had merged to main by reading the commit log linearly instead of asking the code review tool. Engineers also steered Claude away from over-engineering prompted by adversarial review. Team members still review every change request to the system, but they focus on the intent of a change rather than reading every line.[1]
The post says the speed of code generation let the team build hermetic simulations of infrastructure and source control interactions, fuzzing and rate limiting, and that Claude found significant optimizations, such as an algorithmic optimization to ancestry queries "that missed one of our indexes." For operations, the team used Claude Tag to run Slack channels in which a Claude instance watches one component's telemetry and logs. Anthropic calls these instances "superfans," with one each for scion-daemon, scion-cache and the Antique merge queue, alongside conventional alerting.[1]
Availability and wider ecosystem
Anthropic said Scion is difficult to offer to other organizations because it diverges significantly from git, would require migrating every part of the development lifecycle, and depends on bespoke internal code review, code search and CI systems. It also said the design only makes sense for very large monorepos with tens of thousands of engineers or large numbers of coding agents.[1]
The company said it expects similar problems to become more common over the following six to twelve months and that it would rather share ideas that can be applied to git without abandoning git's model. Its suggestions included git server architectures that work differently from git clients, comprehensive server-side RPCs (possibly standardized across git forges), a revised negotiation protocol, and better composition of git's sparse and shallow features. The post said Anthropic hopes to work with GitHub, GitLab and the open-source community on these changes.[1]
Reception
The post was widely discussed among software developers. A Hacker News submission on October 13, 2026 had received more than 880 points and nearly 1,000 comments by October 15, 2026. Commenters debated whether a centralized, server-side design was a step back toward older systems such as Subversion, questioned how 30,000 merges a day could be reviewed meaningfully, and noted that few organizations face problems at Anthropic's scale.[3]
On October 14, 2026, Rain, a software engineer who builds systems at Oxide and who said they had helped build Meta's Mononoke source control server, published a critique on their blog. Rain compared Anthropic's description of derived data with their own 2022 description of the same concept in Mononoke and argued that the similarity went "well beyond having similar insights." They wrote that crediting Sapling only for "hard-won lessons" and not mentioning Mononoke "borders on plagiarism," while also saying they had no objection to Anthropic reusing the design itself.[4] Meta's 2022 announcement of the open-source Sapling client describes the project as about ten years of work on scaling Meta's monorepo, with a separate Sapling-compatible server and virtual file system.[5]
See also
References
- ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21 ^22 ^23 ^24 ^25 ^26 ^27 ^28 ^29 ^30 ^31 ^32"Redesigning source control at Anthropic." Anthropic Engineering, October 13, 2026. anthropic.com/...redesigning-source-control
- ^"Anthropic has developed and internally migrated to Scion, a Git alternative version control system, because the explosive growth of code using AI has pushed Git to its limits, and they are developing a system that can handle it." GIGAZINE, October 14, 2026. gigazine.net/...ropic-scion-version-control-system
- ^"Redesigning source control at Anthropic" (discussion thread). Hacker News, October 13, 2026. news.ycombinator.com/item
- ^Rain. "Anthropic's Scion is heavily inspired by Mononoke." sunshowers, October 14, 2026. sunshowers.io/...anthropic-mononoke
- ^Durham Goode and Michael Bolin. "Sapling: Source control that's user-friendly and scalable." Engineering at Meta, November 15, 2022. engineering.fb.com/...ling-source-control-scalable
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation. Every suggestion is reviewed for sourcing before it goes live.
1 revision · v1 · 2,794 words · full history
Fact-checks are independent of edits: a reviewer re-verifies the article against its sources and stamps the date. How we verify
Research and drafting on this wiki are AI-assisted, under named human editorial standards. How AI is used here
Cite this page: AI Wiki. "Scion (version control)." aiwiki.ai, updated 15 Oct 2026. CC BY 4.0. https://aiwiki.ai/wiki/scion_version_control