Anthropic Rebuilt Its Code System in Five Months as Merges Grew Tenfold
Anthropic moved to an in-house version control system, the tool that tracks code changes, in five months. The company says merges per day grew more than tenfold, a rate that changes requirements for merge queuing (lining up changes to land in order), contention handling (managing clashes) and client fetch performance (how fast developers download updates) Anthropic Engineering.
The account comes from "Redesigning source control at Anthropic," published on Oct. 13, 2026 at https://www.anthropic.com/engineering/redesigning-source-control Anthropic Engineering. The engineering index also lists the piece among its featured work.
At the center is Scion. Anthropic defines the unit of work in Scion as a changeset entered in a write-ahead log, a durable record where each change is ordered before it is applied Anthropic Engineering. A log gives a single durable sequence for concurrent writers, or many developers saving at once.
Anthropic states a Scion changeset contains most of what a git commit contains, the saved snapshot familiar to Git users Anthropic Engineering. The company notes room to diverge on storage, identity or metadata handling, or how changes are kept, identified and described.
For context, Mercurial is a distributed source control system similar to Git Meta Engineering. It is written mostly in clean, modular Python, making it deeply extensible, or easy to add to Meta Engineering. That extensibility kept several large installations viable for years through extensions, virtualized working copies and server-side sharding, ways to split load and limit downloads.
The broader context here is what happens when merge throughput outruns a general-purpose tool. Trunk contention, or backups on the main shared branch, rises. CI signal, the automated test result, must attach to an exact ordered candidate. Clients must sync without paying full-tree cost, or downloading the whole project, on every pull. Teams usually respond with layered caching, sparse profiles and stricter merge serialization before they consider replacement.
In my view, the five-month timeline is the detail to weigh alongside the architecture. Greenfield version control, built from scratch, is rarely fast. Data migration, tooling parity, IDE integration, code review, blame, bisect, access control and audit all have to move together. Five months implies narrow scope discipline and a willingness to cut compatibility where the log model required it. It also implies the pain of the existing path was concrete and measurable in queue time and retry load.
For platform teams elsewhere, the changeset-in-log pattern deserves attention. It separates the durable order of landed work from the graph developers edit against. That separation simplifies atomic landing, deterministic builds and reproducible checkouts, or saving all at once, building the same way each time, and recreating exact copies. It also concentrates complexity in the log writer. Throughput, availability and tail latency for that writer become primary service-level concerns, with replication, failover and backpressure design carrying more weight than client features.
Worth flagging is the compatibility signal in "most of what a git commit contains." Migration cost lives in edge behavior. Hooks, third-party integrations, signed commits, submodules, large files and history rewriting all break first. Keeping the changeset close to commit semantics lowers retraining cost and preserves mental models around diff, parentage and review. The remaining gap, however small, is where long-tail tooling work accumulates.
What this enables, if the operational core holds, is headroom. Tenfold growth rarely stops at tenfold. A system owned end to end can evolve fetch protocols, delta encoding and merge scheduling without waiting on upstream release trains. That control compounds over time for large monorepos and agent-assisted workflows that generate many more candidate changesets per human commit.
