On October 13, 2026, Anthropic published an article introducing Scion, their next-generation internal source control system. What drove them to overhaul source control was a sudden surge in scale over just 4 months. In May 2026, Anthropic’s monorepo averaged 2,500 changes merged into main per day; by September 2026, that number had climbed past 30,000 per day. In just four months, daily merged changes grew more than tenfold. With more and more agents and automated jobs submitting code, engineering infrastructure designed for human scale began to buckle, with source control, build, and CI systems hitting bottlenecks first.
From a storage and bandwidth standpoint, git could no longer keep up. The history of Anthropic’s main branch was approaching 100GB, and even after compression, each working copy exceeded 25GB+. Combined with CI and automated jobs pulling code roughly 25 million times a day, doing a full clone every time would mean moving more than 600PB of code across the internal network daily. To prop up git, Anthropic had deployed hundreds of internal git mirror nodes, seeding from repository snapshots in object storage and then syncing increments. Even so, the system still went down frequently.
Why did battle-tested git fail here? Because from the day git was created, its core user was a human. When git was born in 2005, one of its central goals was to let developers keep working even when offline: carrying a laptop without internet for a dozen hours, you could still commit, switch branches, browse history from years ago, and diff any two revisions. To support this occasionally offline workflow, git chose a peer-to-peer architecture where client and server are equals: by default, every time you clone a repository locally, you download the entire commit history and file object graph from start to finish, and all history traversal, diff computation, and branch merging happen locally. As long as the user at the screen is a human who pulls code a few times a day and works in the same working directory all day long, this offline peer-to-peer design is remarkably elegant.
Inside Anthropic today, however, the primary user of source control has changed. The main force initiating over 25 million checkouts and submitting more than 30,000 changes a day is no longer a programmer typing on an airplane, but always-on agents and automated CI jobs inside the data center. These machine clients have two characteristics that are the exact opposite of humans: first, they are permanently connected to a high-speed data center network and have zero need for offline work; second, their lifetimes are extremely short—they often spin up a temporary sandbox just to fix one bug or run one test and destroy it right after, and many tasks only need to inspect the diff between two commits without even creating a local working directory.
When you use a peer-to-peer system designed for long-lived, frequently offline humans to serve a fleet of short-lived, always-on machines, every original design strength turns into a liability. In response, Anthropic assigned 7 engineers who spent 5 months writing Scion from scratch, migrating their entire monorepo off git while also rebuilding half a dozen surrounding systems, including the code review tool Antique, code search, source-level access control, and automated bisection and rollback pipelines.
Seeing 7 people replace an entire version control foundation in 5 months, many people’s first reaction is: why reinvent such a heavy wheel when you could keep adding caches and patches to the old system? We ran through this exact calculation not long ago in our companion piece, The Second-Order Dividend of CI: When Rewrites Get Cheap, Patching Stops Paying Off, using Anthropic’s own CI test selection service: once agents drive up repository traffic, the window of stability that patching buys on an old architecture shrinks rapidly; meanwhile, AI-assisted programming drastically lowers the timeline and headcount required to rewrite a system from scratch. With patch shelf life getting shorter on one end and the fixed cost of a rewrite dropping on the other, the break-even point—where you used to make do with patches until the system was truly beyond saving—has shifted much earlier. Scion simply extends that same economic calculation from peripheral CI services all the way down to the lowest-level version control system.
Since the primary user is a machine permanently on the internal network, the client no longer needs to carry the entire repository around like a human’s laptop. Scion dismantled the peer-to-peer client-server design altogether and split responsibilities cleanly between the two sides: the server holds the full history and performs all CPU-intensive heavy computation; the client keeps only a bounded local object cache, does almost no computation of its own, and often doesn’t even check out a local repository, calling server APIs directly to get its work done. Walking through four key scenarios—reading code, writing and querying, merging into main, and the division of human labor—shows how this “thin client, thick server” philosophy works in practice.
Specifically, for the most frequent operation—pulling code—when we use git on our computers, the git client negotiates with the server by reporting which commits it already has locally. The server then traverses and compares the commit graph on the fly to figure out which file and directory objects the client needs, compresses and packs them into a custom large file, and sends it over. That on-the-fly bundle is called a packfile. When humans pull code a few times a day, that’s fine. But with 25 million cold-start checkouts per day—each requiring negotiation with the server and on-the-fly object selection and packing into a packfile—this process quickly saturates the CPU and memory of hundreds of internal git mirror nodes. Worse yet, because the resulting bundle varies depending on each client’s local state at the time, intermediate layers cannot cache it like static files.
For tens of thousands of machines to share a cache without repacking
every time, every file needs a fixed address. Scion uses the hash of a
file’s content directly as its storage address: identical content
produces the exact same address, and changing a single character
produces a new address, so identical content is automatically stored
only once and deduplicated. Moreover, the content at a given address
never changes, so once any intermediate cache node has stored that
address, it can serve the client directly without ever asking the origin
server whether it has expired. This mechanism of using a content-derived
hash as the address is called content-addressed storage. Built on
content-addressed storage, Scion eliminates the packfile altogether: its
client tool scn does not report what it has during server
negotiation, but instead walks down from the root directory tree and
recursively requests whichever directory or file hash chunks it is
missing, and can resume seamlessly if a transfer is interrupted
midway.
With content-addressed storage as the foundation, every file and
directory becomes a never-expiring static chunk, allowing all those
hundreds of git mirror nodes—each maintaining a full repository and
computing packfiles on the fly—to be retired and replaced with a
three-tier cache. Why three tiers? Because inside the data center, large
swarms of jobs are reading the same batch of code at every moment: tiers
closer to the job are faster but hold less, while tiers closer to the
full dataset hold more but sit farther away. Scion’s approach is to
check the local host machine first, then check shared memory in the data
center, and only go to cloud storage as a last resort—each layer
stepping closer to the full source of truth. The first tier is a local
daemon, scion-daemon, running on every host machine.
Short-lived agent containers spun up one after another on the same host
share this local cache directly, so a file just fetched by the previous
job can be read locally by the next one. If the file isn’t on the host,
the request goes up to the second tier, the regional cache
scion-cache. It keeps frequently read hot data resident in
memory directly in its on-disk format and streams it out on a hit,
avoiding unpacking overhead. Only cold data that misses both of the
first two tiers reaches the third tier, the authoritative server
scion-server, which fetches from origin in cloud storage.
Externally, all three tiers expose the same homogeneous RPC interface
with strictly isolated fault domains, so the entire read path falls back
tier by tier just like a CDN.
Once the caching path is streamlined, the client no longer needs full clones and instead supports two on-demand fetch modes: when a job knows in advance which modules are involved, it pulls only the subdirectories needed for the current task to the local disk and leaves everything else untouched—sparse checkout; alternatively, it mounts an empty directory skeleton locally so all files appear to be present even though nothing has been downloaded yet, fetching individual files in the background on demand only when a process actually reads them—virtualized checkout. For CI jobs that only need to inspect a code diff, no directory needs to be created at all; they simply call the server API to get the diff. According to Anthropic’s measurements, each tier of this three-tier cache achieves a hit rate above 99%, and the total CPU and memory footprint of the source control infrastructure shrank by 200x compared to the old git mirror cluster. Single checkouts dropped from minutes to seconds, saving 25% of CPU across all of CI in the process, while eliminating periodic repository maintenance on both clients and cache layers.
The same principle applies to writing code and querying history. In day-to-day development, beyond making direct commits, you also join two lines of changes together (merge) or move your changes onto the tip of the latest main branch (rebase). In git, every commit stores a snapshot pointer to the entire directory tree; as a repository grows, the overhead of commit, merge, and rebase gets dragged down with it, while the server must coordinate locks to receive packfiles and update large numbers of branch pointers. The tension becomes even sharper on the query side: developer tools frequently trace who wrote each line of code (blame queries) or walk backward through history before a merge to find the lowest common ancestor of two branches (merge base). Having ephemeral agent containers traverse 100 GB of history locally to compute blame and merge base is simply a non-starter.
Scion moves both writes and heavy queries to the server, where the basic unit of every commit is a changeset. A changeset does not store a pointer to the entire directory tree; it records only which specific files changed relative to its first parent commit, along with content-addressed pointers to the contents of those files. When saving a changeset, the server does not mutate complex tree structures in place either; instead, like keeping a ledger, it sequentially appends a new record to the end of a log—an append-only write-ahead log (WAL). Whether it is a commit, merge, or rebase, the server generates a changeset directly and appends it to the end of the log, making it immediately visible upon write. Because it neither rewrites the full tree nor mutates old data in place, the cost of each write is proportional only to the number of files changed in that commit, regardless of how large the overall repository is.
To eliminate write contention, Scion also drastically cuts down the number of branch pointers. In Git, a branch pointer is a name that points to the latest commit—such as main for the main branch, or feature branch names created on the fly during development; these named pointers are collectively called refs. When thousands of engineers and swarms of agents create branches in a repository, you end up with tens of thousands of these names. The catch is that these names are globally shared state: the server has to coordinate what every name points to at any given moment, and once tens of thousands of changes try to move them concurrently, coordination itself becomes a bottleneck. Scion largely avoids using refs in day-to-day work; the repository has almost nothing beyond main and release branches, and commits made during development do not need to be registered as global branch names. As a result, creating a changeset requires neither receiving a packfile nor acquiring cross-node locks or moving a ref. Only at the moment of merging into main—when the global name main must be updated—does the server perform an atomic operation on a single row in Spanner, Google’s globally distributed strongly consistent database: it checks whether the old commit ID has changed and writes the new commit ID only if it hasn’t, a standard CAS operation.
Meanwhile, query data used for inspecting history—such as blame, path history, and commit-graph skip lists—adds no new facts of its own: as long as you have the underlying ledger of changesets, you can derive them at any time just like calculating an account balance from bank transactions, without anyone manually committing or maintaining them. Scion refers to all such secondary indexes that can be recursively computed from base commit records as derived data. The server uses a single unified mechanism to compute derived data, either precomputing it ahead of time or deriving it on demand. Because clients only call APIs and never see the internal data structures, the engineering team can upgrade indexes in the background completely transparently to clients. Indexes for copy detection and path-based search have already been added over time. During development, Claude also noticed that ancestry queries were failing to use an existing index and contributed an algorithmic optimization along the way.
Once reads and writes are solved, the third wall is the gate for merging into main. Large engineering teams typically place an automated gate in front of main where all pending changes line up in a single queue, run the full test suite one by one against the latest main, and only land in main after everything passes green—a queuing mechanism known as a merge queue.
When humans are making a few hundred commits a day, a merge queue works well; but when merges surge to 30,000 per day and the primary contributors are agents running around the clock, a traditional merge queue breaks down. If every merge has to wait in line to run tests, and the change at the head of the queue takes several minutes to finish testing, tens of thousands of changes behind it can only sit idle; worse, a monorepo has only one main, so this queue cannot be split across multiple machines to merge in parallel—under high concurrency, it effectively puts a slow global exclusive lock on the entire repository. To break this bottleneck, Anthropic shifted to post-merge, pre-deployment automated testing: changes are merged into main first, and automated bisection and rollback pipelines then identify and revert problematic commits. Merging directly under high concurrency does increase merge conflicts, but the team found in practice that Claude resolves conflicts automatically faster than human engineers can even recognize them.
The fourth bottleneck falls on humans. Those 7 engineers had to build Scion and half a dozen companion systems while simultaneously upholding code quality by manually reviewing every change to the system itself; meanwhile, company-wide merge volume had grown 10x, making it completely unrealistic to read AI-written code line by line. Yet leaving agents to write and review code entirely on their own runs straight into two anti-patterns: first, agents copy bad patterns from legacy code that shouldn’t have existed in the first place, violating architectural constraints—for instance, several internal systems previously determined when a commit landed not by calling the code review tool’s API, but by linearly scanning the entire commit log from start to finish, and agents writing new code simply replicated that bad habit; second, adversarial code review by agents is myopic—a nitpicking reviewer agent endlessly raises hypothetical risks, pushing Claude into over-engineering and piling on layers of excessive defensive checks.
Once they understood these two failure modes, the team decided to
review only the intent and system boundaries of each change rather than
reading the implementation line by line. An engineer’s primary
responsibility is to provide high-level system understanding, make
design decisions, and often simply say no to Claude. Correctness of the
underlying implementation is guaranteed by hermetic deterministic
simulation—which runs without external dependencies and precisely
controls concurrency interleavings—along with fuzz testing using random
and malformed inputs, plus rate limiting. Security is enforced through
repository-level and directory-level access controls, combined with rich
semantic approval rules in the review tool Antique. Day-to-day
maintenance is handled by a set of dedicated inspection instances built
on Claude Tag, affectionately called superfans internally, where each
instance watches over the health of a single component such as
scion-daemon, scion-cache, or the Antique
merge queue.
At the end of the blog post, Anthropic is also candid about Scion’s positioning and limitations: it is a system built along the lineage of Google Piper and Meta Sapling, not intended to replace general-purpose git; it only pays off in ultra-large monorepos and relies on an internal token budget far beyond that of a typical company, so they have no plans to open-source it as a product. For the broader industry, its main takeaways lie in several architectural ideas: a git server does not have to be homogeneous with its client, heavy computation can be moved into server-side RPCs, fetches can use a new negotiation protocol that doesn’t report local state, and shallow clones (fetching less history) can be combined much more effectively with sparse checkout (fetching fewer directories).
After the blog post went live, the community’s first reaction was: isn’t this just reinventing SVN, Perforce, or Meta’s open-source Mononoke? Scion and SVN/Perforce only look similar on the surface in being server-centralized; their underlying data models and horizontal scalability are very different. However, Scion’s core data model really is very close to Meta’s open-source Mononoke (Bonsai). Because the initial version of the blog post made no mention of Mononoke, former Meta engineer Rain published a first post and a second post questioning Anthropic’s omission of credit for Mononoke, sparking debate on the Hacker News thread. On October 15, Anthropic added a footnote explicitly crediting Mononoke and Bonsai.
This is primarily an attribution issue rather than code plagiarism or an open-source license violation. Whether the initial omission was intentional is something we cannot independently verify. Still, it points to a plausible explanation: the reason AI can rebuild a low-level system so quickly is very likely that predecessors already open-sourced mature designs that subsequently entered the model’s training data.
For a typical engineering team’s development pipeline, the first idea to drop is building your own version control system. Anthropic’s battle is fought on a 100 GB history, 25 million checkouts per day, 30,000 merges per day, and an internal token budget far beyond that of most companies. For most teams, even if your repository has already slowed down, simply configuring Git’s three built-in load-reduction switches—pulling only the most recent one or two commits in CI and agents (shallow clone), fetching the history skeleton first while skipping large blobs (partial clone), and pulling only the current directory to local disk (sparse checkout)—will eliminate the vast majority of pain points. Until you have wrung everything out of these native tools, building custom version control is just paying for scale you don’t have.
Once you set aside reinventing the wheel, there are three engineering judgments you can take away immediately from this rewrite—covering process, people, and economics.
First, audit your development workflow for implicit assumptions that the default user is a human. You don’t need to wait until you hit 30,000 merges a day to start optimizing: as soon as high-frequency agents plug into your pipeline, CI scripts that do a full repository checkout on every job, surrounding tools that query metadata by traversing the commit graph locally, and serialized merge queues that force all commits to wait in a single line for tests to finish will become bottlenecks one after another. Moving a portion of heavy testing from pre-merge to post-merge (pre-deployment), paired with automated bisection and rollback pipelines, is often far more effective than shaving a few seconds off an individual test run.
Second, shift human attention from reviewing syntax line by line to guarding intent and architectural guardrails. Prevent agents from propagating bad smells found in legacy code, and don’t put blind faith in adversarial review between agents; human engineers should focus on verifying business intent and module boundaries, firmly saying no when models over-engineer, while building a solid foundation of deterministic simulation testing, directory-level access controls, and automated rollback.
Third, recalculate the patch-versus-rewrite ledger for aging internal tools, while giving proper credit to open-source prior art. When patching a legacy internal system buys ever-shorter windows of stability, and mature architectural prior art is already out in the open in the community, pulling two or three engineers to rewrite a streamlined system in a few weeks with the help of models now makes complete economic sense—just keep in mind when you build that half the time saved comes from model capabilities, and the other half comes from the open-source designs predecessors left out in the sun.