Redesigning Source Control at Anthropic: Claude Outgrew Git

Anthropic replaced Git after Claude helped push its monorepo from roughly 2,500 daily merges in May 2026 to more than 30,000 by September. That surge makes Redesigning source control at Anthropic more than an infrastructure migration story. It shows what happens when AI generates code faster than development systems can safely absorb it.

The company built Scion, an internal source-control system designed around online agents, server-side operations, and sparse access to a giant repository. Seven engineers also built Antique, a new code-review system, plus several related services. Anthropic says the team completed the migration in five months.

The important conflict is not simply Scion versus Git. It is agent-scale code production versus development practices designed around human attention. Google and Meta have already built specialized systems for enormous monorepositories. Anthropic reached a similar destination through a different pressure source: swarms of software agents that never need to work offline.

Redesigning Source Control at Anthropic Started With 30,000 Daily Merges

Anthropic did not abandon Git because its engineers disliked Git. It abandoned Git because Claude changed the shape and volume of repository traffic.

According to Anthropic’s engineering account, daily merges increased more than tenfold between May and September 2026. The company presents that growth as continuing demand rather than a short-lived migration spike.

The resulting workload went far beyond commit creation. Anthropic’s main-branch history approached 100 GB, while a compressed working copy exceeded 25 GB. Continuous integration, or CI, performed about 25 million code checkouts each day before developer environments, agent sandboxes, and research jobs were counted.

Fetching those checkouts naively would generate more than 600 petabytes of daily Git traffic, Anthropic calculated. The company used shallow clones, sparse checkouts, repository snapshots, and several hundred internal Git mirrors to control that cost.

Those measures bought time, but the repository kept changing faster. Snapshots became stale between refreshes. Partial clones also complicated operations such as history searches, diffs, and blame, which identifies who last changed a line.

The company’s problem came from a mismatch between Git’s strengths and Anthropic’s dominant clients. Git gives every clone enough information to operate as a self-contained repository. That design supports offline development, local history, and decentralized collaboration.

Anthropic’s agents and automated jobs were already online. They did not need full local history or the ability to act as independent servers. Yet the infrastructure repeatedly distributed and maintained repository data as though every client were a human developer using a laptop.

Scion reverses that assumption. Its server performs history queries, creates commits, calculates diffs, and handles merges or rebases. A lightweight client maintains a bounded cache and materializes only the files required by the current task.

That difference matters when a research job needs one directory rather than the entire monorepo. It also matters when a CI service only needs a diff or a merge-base calculation. Scion can answer those requests through an API without creating a traditional working copy.

The new architecture has produced substantial internal gains, according to Anthropic. Each cache tier reportedly maintains a hit rate above 99 percent. The infrastructure uses 200 times less CPU and memory than the previous Git mirror fleet.

Anthropic also says CI and research checkouts fell from minutes to seconds. The change returned 25 percent of CI CPU capacity to the broader computing fleet.

These are company-reported measurements from an internal system. Outside researchers cannot reproduce them without access to Anthropic’s workloads, repositories, and infrastructure. Still, the numbers explain why another round of Git tuning no longer looked sufficient.

The system had to support more than a large repository. It had to support a repository whose primary writers, readers, and automated consumers operated at machine speed.

Claude Turned Software Infrastructure Into the Bottleneck

Scion’s real significance is that code generation stopped being Anthropic’s scarce resource. Review capacity, infrastructure, and judgment became the constraints.

AI coding assistants originally fit inside a familiar development process. A person requested a function, inspected the output, ran tests, and submitted a pull request. The assistant increased an individual developer’s typing speed without changing the surrounding system.

Anthropic describes a more advanced operating model. Claude reportedly iterates through research loops, optimizes complex programs, creates services, monitors production components, and assists with large migrations. Each activity can produce new changes or demand fresh repository access.

That pattern creates multiplicative pressure. One agent can launch another task while an earlier change moves through testing. Automated reviewers can request fixes, which produce additional changes. CI systems then create checkouts and invoke more repository queries for every candidate.

The graph highlighted by Simon Willison shows a sharp increase during 2026. Willison connected the acceleration to Anthropic’s newer internal model generations, while carefully distinguishing internal availability from public release dates.

Anthropic makes a more specific connection. It says Scion development began around the time Claude Mythos Preview and Claude Tag became available internally. Those models reportedly increased the need for Scion while helping the team build it.

One example involved the pipeline that moved data from Git into Scion. Anthropic’s engineers had written an initial prototype by hand. An early internal version of Claude Mythos Preview then rewrote the pipeline with little additional direction.

The replacement reportedly used 20 times less memory and ran four times faster. Anthropic says it preserved implicit requirements involving ingestion order and data structures. That claim is striking, but it remains a result described by the company rather than an independent benchmark.

The broader feedback loop is easier to establish. Faster code generation increased repository activity. That activity justified new infrastructure. Claude then helped construct the infrastructure, which removed another limit on code generation.

This loop pressures every part of the development lifecycle. A build service that handles human-paced changes can become expensive when agents create thousands of concurrent tasks. A review queue becomes less useful if the repository advances through hundreds of changes while a test suite runs.

Knowledge access also becomes part of the constraint. Agents need specifications, architectural decisions, incident history, and ownership context, not just source files. Teams building similar workflows need a searchable engineering knowledge base alongside faster code infrastructure.

Anthropic says it now uses persistent Claude monitors called “superfans” for individual Scion components. These agents watch telemetry and logs through dedicated Slack channels. Traditional alerts remain in place, while the agents look for patterns that fixed thresholds might miss.

That operational model moves engineering work upward. People define invariants, choose architectural boundaries, interpret failures, and decide what should reach production. Agents generate implementations and investigate telemetry within those boundaries.

The shift does not eliminate the engineer. It changes the scarce skill from producing code to deciding which code deserves to exist.

Scion Replaces Git’s Offline Model With an Agent-Scale Service

Scion gains throughput by giving up Git’s defining symmetry: a client no longer carries the repository’s full intelligence.

Git commits contain pointers to complete directory trees. Clients exchange compressed collections of objects called packfiles, allowing local repositories to preserve history and operate independently. This model remains appropriate for most software projects.

Scion uses a changeset, an entry in a write-ahead log that records changed files relative to a parent. File contents are compressed, content-addressed, and stored separately. Content addressing means the storage key derives from the data, so immutable objects can be cached safely.

Changesets are created on the server and become available across the system. They do not require a client to construct and upload a large packfile. They also avoid moving a global branch pointer during every commit operation.

Scion still supports references, meaning pointers such as branches and tags. However, Anthropic discourages most references beyond the main line and release branches. Globally coordinated state becomes increasingly expensive as commit rates climb.

The system calculates history information separately as derived data. It builds dedicated indexes for file history, blame, copying, and relationships within the commit graph. Those indexes can be generated immediately or deferred until a consumer requests them.

This separation lets Anthropic change an index without changing every client. It also allows the service to avoid computing data that no task needs.

Scion’s checkout protocol follows the same principle. Clients ask for particular trees and file objects rather than negotiating a complete picture of what they already possess. Regional cache servers can satisfy most requests because stored objects never change.

A daemon on each compute node shares cached objects among local jobs. Regional cache services then sit between those daemons and the authoritative Scion servers. Anthropic enforces this hierarchy to prevent a regional cache failure from overwhelming the central service.

Sparse checkouts only request selected directories. Virtualized checkouts create files when a process reads them. Some jobs skip the filesystem entirely and ask the API for a diff, history result, or merge base.

This design resembles earlier responses to monorepo scale. Google described Piper as part of the infrastructure supporting a huge, centralized codebase. Its published monorepo analysis documented the advantages of shared code, unified dependencies, and organization-wide changes.

Meta took another route with Sapling, a system that retains familiar distributed source-control concepts while scaling to its internal repository. Meta says its server can handle tens of millions of files, commits, and branches. The public Sapling design also supports Git repositories and local developer workflows.

Scion borrows lessons from both histories, but its main assumption is narrower. The dominant client is always online, often automated, and unlikely to need an entire repository. That makes the server a source-control database and computation service rather than a synchronization partner.

The tradeoff is dependence. A Scion client cannot reproduce Git’s full offline behavior because it deliberately holds less data and performs fewer operations locally. A network or central-service failure therefore matters differently.

Migration costs also extend beyond the command-line client. Anthropic had to build code search, identity and access controls, CI integrations, and Antique. A company adopting the same design would need to replace much of its development platform.

That explains why Scion is not an Anthropic Git alternative for ordinary teams. It is a vertically integrated system for one exceptional workload.

Faster Merges Make Code Review the Harder Problem

The unresolved question is not whether Scion can accept 30,000 changes. It is whether Anthropic can preserve accountability at that speed.

Anthropic says every Scion change still receives human review. Reviewers now focus on the intent of a change instead of reading every line. That choice follows from volume, but it also moves trust toward tests, agent explanations, and automated analysis.

Intent review asks whether a proposed change matches the system’s goals and architectural rules. Line review asks whether its implementation behaves correctly. Strong automated checks can connect those levels, but no test suite captures every hidden requirement.

Anthropic acknowledges that engineers often had to tell Claude “no.” Agents sometimes selected locally plausible patterns that violated system-wide constraints. Some generated components attempted to scan the commit log linearly instead of querying Antique for an authoritative merge time.

Adversarial review created another failure mode. Claude could respond to hypothetical risks with excessive validation and complexity. Human engineers had to decide when defensive programming stopped improving the system.

Those examples complicate the simple claim that better models directly produce better software. Agents can find valuable optimizations while also creating unnecessary mechanisms. High output magnifies both behaviors.

Anthropic says its team built simulations, fuzz testing, and rate limits for Scion. Fuzzing supplies unexpected inputs to expose defects, while hermetic simulations reproduce infrastructure behavior in isolated environments. These controls provide stronger evidence than merge counts alone.

Still, merge volume is not a quality metric. A change can be tiny, experimental, generated, reverted, or unrelated to customer-facing progress. Thirty thousand daily changes reveal extraordinary activity, but they do not independently show reliability or business value.

Public developer reactions have centered on that distinction. In the Hacker News discussion, some readers questioned whether Anthropic should reconsider its monorepo. Others argued that intent, provenance, and continuous verification matter more than traditional commit mechanics.

An Anthropic engineer responding in that thread defended the monorepo’s consistent tooling and atomic changes. The same engineer clarified that Scion blocks textual conflicts but cannot eliminate semantic conflicts between concurrent changes.

A semantic conflict occurs when two individually valid edits produce incorrect behavior together. One change might alter a function and update its callers while another simultaneously adds a new caller. The files can merge cleanly even though the combined program is wrong.

Traditional merge queues reduce that risk by testing a proposed repository state before accepting the next batch. Anthropic says a global repository lock becomes impractical when hundreds or thousands of changes land during a test run.

The company has shifted investment toward post-merge and pre-deployment testing. That approach allows repository throughput to continue while checks determine what can safely reach production.

This is the central tradeoff in Redesigning source control at Anthropic. Scion removes serialization from source control, but some form of serialization still exists at deployment, data migration, or human decision points. The risk moves rather than disappears.

Anthropic says Claude can resolve concurrent conflicts faster than people can identify them. That response addresses repair speed, not the cost of an undetected interaction. Safety depends on how quickly monitoring detects a problem and how effectively systems isolate or reverse it.

Directory-level access controls and semantic approval rules help. Antique can distinguish a comment-only change from a sensitive logic change, according to Anthropic. Human attention can then concentrate on changes with greater consequences.

The remaining verification gap is substantial. Anthropic has not published independent defect rates, rollback frequency, incident trends, or the proportion of changes written and reviewed by agents. Without those measures, outsiders cannot compare throughput gains against downstream risk.

The most useful lesson for other teams is therefore not to chase Anthropic’s merge count. It is to measure the entire path from specification to deployment. Useful indicators include escaped defects, review latency, failed changes, rollbacks, duplicated work, and time spent restoring context.

A personal AI workflow can help engineers preserve decisions and provenance as agents generate more material. However, stored context only helps when teams connect it to enforceable tests, ownership, and review policy.

What Anthropic’s Source-Control Experiment Changes Next

The next phase will test whether agent-scale development becomes a transferable engineering model or remains an expensive Anthropic exception.

The first signal to watch is Anthropic’s promised discussion of Antique. Source control explains how changes are stored and retrieved, but code review determines how intent, ownership, and approval survive extreme volume.

Details about Antique’s review model would strengthen Anthropic’s argument if they show clear provenance and risk-based human intervention. The argument would weaken if review depends mostly on model summaries without measurable validation.

The second signal is software quality over time. Anthropic’s infrastructure claims will carry more weight if the company publishes rollback rates, escaped defects, service incidents, or other outcome measures alongside merge throughput.

Stable or improving reliability would support the idea that agents can increase change volume without proportionally increasing risk. A rise in regressions or emergency repairs would suggest Scion accelerated production faster than governance.

The third signal is how Git platforms and large engineering organizations respond. Most companies will not replace Git, but they can adopt server-side metadata APIs, virtualized workspaces, risk-aware review, and better support for parallel agents.

Meta’s Sapling already demonstrates one path that maintains compatibility with familiar workflows. Microsoft’s Scalar and related Git improvements demonstrate another, extending Git for large repositories instead of replacing its data model.

Anthropic itself expects these pressures to spread within six to twelve months. That forecast is a company judgment, not a measured market trend. Its relevance depends on whether other organizations reach similar limits without Anthropic’s internal token access and unusual concentration of Claude usage.

Scion also introduces a strategic dependency that competitors might avoid. Anthropic controls the model, repository service, review surface, observability agents, and deployment workflow. This integration speeds iteration, but it makes the development environment harder to reproduce or replace.

For most organizations, Git will remain the sensible default. It has broad interoperability, mature tools, portable history, and offline resilience. Scion’s architecture only becomes attractive when repository traffic has already overwhelmed those advantages.

The more immediate change concerns management. Engineering leaders must stop treating generated code volume as the objective. More output creates value only when teams can review, test, deploy, observe, and reverse it safely.

Developers should also expect their work to shift. Anthropic’s account places greater weight on system design, architectural constraints, evaluation, and refusal. The engineer increasingly defines the boundary within which an agent can move quickly.

Redesigning source control at Anthropic therefore offers a warning alongside its performance story. Once code becomes cheap, every weak specification, missing test, and unclear ownership boundary can be reproduced at machine speed.

The useful question is not whether your team needs Scion. It is whether your existing review, CI, and knowledge systems would remain trustworthy if agents produced ten times more changes next quarter. Measure that capacity now, identify the first failing control, and strengthen it before higher merge volume arrives.