Open-source Scion clones only the slice you ask for

At one point Anthropic's CI was running about 25 million checkouts a day, and it took several hundred git mirrors to keep up. OpenScion, an open-source project published on GitHub, rebuilds the replacement system from the design Anthropic described for its internal Scion, where most clients are AI agents and CI jobs rather than people on laptops.

At a glance

• OpenScion is a GPL-3.0-only source control system written in Rust and modelled on Anthropic's internal Scion. It targets huge monorepos where most of the traffic comes from AI agents and CI jobs.
• History, blame, rebases and merges run on the server. Clients fetch only the trees and blobs they name, so the cost of a one-directory clone tracks that slice rather than the whole repository.
• The project's own benchmark shows OpenScion importing and cloning several times faster than git, but only on synthetic repos of 4 KiB files. The project is an unofficial reimplementation, not Anthropic's code.

If you have not been following: Anthropic argues that coding is no longer the bottleneck, and that the new bottleneck is source control, builds and CI designed for human scale. By its account, merged changes went from about 2,500 to over 30,000 a day in four months. The main-branch history reached almost 100 GB, and a compressed working copy is over 25 GB. Anthropic estimates that fetching naively would put 25 million daily checkouts above 600 PB of git traffic a day.

Anthropic ran several hundred git mirrors before switching to Scion

Anthropic says it first tried git's own tools for working with part of a repository: shallow clones, sparse checkouts and promisor remotes, plus internal mirrors and blob-storage seeds. The mirrors peaked at several hundred. As the merge rate rose they got harder to run, the seeds fell behind the tip of main, and diff and blame on partial clones needed extra care.

Anthropic contrasts git's decentralized design, where every clone is a complete repository that works offline, with what it actually needed, and says it realised it was using git as a centralized system. By its own account, it moved its monorepo fully off git in five months. Alongside Scion it built a code review surface called Antique, code search and a source control IAM system.

Anthropic reports that each cache tier runs above a 99% hit rate. It puts the CPU and memory footprint at 200 times smaller than the old mirroring setup, and checkouts at about two orders of magnitude faster, seconds rather than minutes. Claude helped build it: an early internal version of Claude Mythos Preview rewrote a prototype ingestion pipeline to use 20 times less memory and run four times faster.

OpenScion clones several times faster than git on synthetic 4 KiB-file repos

OpenScion is a separate, unofficial project. Anthropic says Scion is not a suitable replacement for git for general use, and it urges the git community to adopt compatible server-side improvements, better RPCs and improved negotiation protocols. One report says Anthropic will not open-source Scion. OpenScion takes the published design and builds it in Rust.

The project's benchmark tool, openscion-bench, times the opnscn client against git on synthetic repositories of 4 KiB files at two sizes. OpenScion imports and clones several times faster at both. The setup, methodology and raw numbers are in benchmarks/README.md rather than on the front page.

The code is split into crates: openscion-proto for the protocol types, openscion-core for the engine, openscion-server for the HTTP API, and the opnscn client, which you install with cargo install openscion. A Next.js web GUI ships alongside it. Storage sits behind ObjectStore and MetadataStore interfaces, with filesystem and SQLite reference implementations, so a single node runs without any cloud services. CI requires 90% line coverage in every source file.

Every blob, tree and changeset is named by its BLAKE3 hash

Git gives every client the whole history. OpenScion keeps history, blame, commits, rebases and merges on the server, and the client keeps a bounded cache and lays out files. Log, diff, blame, ancestry, rebase, revert and land are RPCs, so a CI or bisect pipeline can query the repository without a checkout.

A changeset lists only the files that changed relative to its first parent, so creating one costs the size of the change. Because objects are named by their hash, any cache can serve them without coordination and any client can verify them. Landing a change means a server-side rebase plus a compare-and-swap on a single ref record. It is retried when two changes collide, and there is no global merge lock.

A request passes through tiers: the client, a per-node daemon with a file watcher, a regional cache and the server. Only the server holds mutable state such as the log and refs. Every tier answers the same object RPCs, so it works like a library network: you order a book by its catalogue number, and the nearest branch that has a copy hands it over.

The benchmark is the project's own, and it runs on uniform synthetic 4 KiB files. The front page gives no figures, so you have to open benchmarks/README.md to see what "several times" means, and nothing in the source shows OpenScion running anywhere near 25 million checkouts a day. In our view, keeping all mutable state on the server is the design's real bet: it likely suits always-online agents, and it leaves offline laptop work out on purpose.

What OpenScion's roadmap leaves open

The repository includes a roadmap that lists what exists, what comes next and what is out of scope. New behavior has to start as a spec in docs/specs/ and get a test-first plan before any code is written. No date for a stable release has been given, and the source does not say whether anyone runs OpenScion in production. According to Crypto Briefing, Anthropic expects pressures like its merge rate to become common over the next six to 12 months.