Anthropic's Scion: Replacing Git for AI-Scale Development

Git's Breaking Point: The AI Code Deluge

Anthropic has a problem many companies would envy: Claude, their AI, writes code so prolifically that their developer infrastructure is collapsing under the weight. In May 2026, the company averaged around 2,500 code changes merged per day. By September, that number had exploded to over 30,000 daily merges—a more than tenfold increase in just five months.

This surge didn't just stress their systems; it broke them. Git, the decentralized version control system that powers modern software development, was never designed for this scale. As Anthropic's monorepo grew to nearly 100 GB of history and 25 GB compressed working copies, the company faced an impossible situation: 25 million daily checkouts for CI alone would generate over 600 PB of network traffic if fetched naively.

The result was Scion, a complete in-house replacement for Git. A team of seven engineers built Scion, a code review tool called Antique, code search, and an IAM system—then migrated the entire monorepo in just five months. It's a case study in how AI isn't just changing what we build, but how we build it.

Why Git Failed at Agent Scale

Git's fundamental design assumes distributed, offline work. Every clone is a complete repository, capable of computing diffs, reading history, and checking out revisions without a server. For most projects, this is a feature. For Anthropic, it became a liability.

"Nearly all of our clients are agents and jobs that are online by definition," the company noted. The properties that make Git excellent for distributed work were actively undermining Anthropic's ability to scale. They had deployed hundreds of internal git mirrors to handle the load, but these became increasingly difficult to operate as merge rates climbed. Seeds (repository snapshots) fell further from the tip of main between refreshes, and operations like diff and blame broke on partial clones.

Anthropic's insight was that they were using Git as a centralized system with one authoritative copy, but all the tools assumed decentralization. So they asked: what would source control look like if designed for always-online agents from the start?

Scion's Architecture: Server-Centric and Horizontally Scalable

Scion inverts Git's core assumptions. Instead of clients holding complete repositories, Scion's server answers questions about history, blame, commits, merges, and rebases. Clients maintain a bounded local object cache, lay out working copies on disk, and monitor filesystem changes—but compute very little themselves.

The unit of work is a "changeset," an entry in a write-ahead log. Unlike a Git commit that points to a full tree, a changeset stores only the files that changed relative to its parent, along with content-addressed pointers to compressed blobs. This structure enables high-throughput acceptance because there are no packfiles to process, no locking, and no cross-server coordination.

"Everything must be horizontally scalable," the team emphasized. Scion's data is distributed across Spanner and cloud storage; there's no fully materialized copy anywhere, even on the server. This eliminates the need for repository maintenance and allows any component to scale independently.

Checkout Architecture: 200x Smaller Footprint

Scion's checkout architecture is a tiered cache system. A client daemon (scion-daemon) stores objects for a node, starting from a periodically refreshed snapshot. It talks to regional cache servers (scion-cache), which stream objects directly from memory in the disk format the daemon needs. Only when a cache misses does it query authoritative scion-servers, which read from Spanner or cloud storage.

This design achieves over 99% cache hit rates at every tier. The infrastructure footprint is 200x smaller than their previous git mirroring setup in CPU and memory terms. CI and research jobs check out code two orders of magnitude faster—seconds instead of minutes—freeing up 25% CPU capacity in CI alone.

The system is also resumable and efficient. There are no multi-gigabyte packfile responses; every request is for a specific, immutable object that any cache can answer. Sparse and virtualized checkouts are natural because clients simply don't ask for trees they don't want.

Lessons Learned: Claude Built Its Own Solution

Perhaps the most striking aspect of this story is that Claude itself helped build Scion. The team's first version of the git-to-Scion ingestion pipeline was handwritten. Then they gave an early internal snapshot of Claude Mythos Preview the task of rewriting it. With no further instructions, Claude produced a version that consumed 20x less memory and ran 4x faster, while preserving all implicit invariants.

The team's engineers now rate Claude as better at writing code than themselves. But they found their role shifting from writing code to making design-level tradeoffs and, crucially, telling Claude "no." Agents would sometimes violate core system constraints or over-engineer responses to hypothetical concerns from adversarial reviews.

"Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code," the post explains. This shift enabled a seven-person team to accomplish what would traditionally take years and dozens of engineers.

Redefining CI, Security, and Review for Agents

Scion's implications extend beyond version control. The team found that traditional merge queues don't make sense at agent scale. Instead of a global repository lock, they invested in post-merge and pre-deploy automated testing. Concurrent changes can conflict, but Claude can fix conflicts faster than humans can identify them.

Security also got a rethink. Scion supports rich access control on repositories and individual directories, protecting sensitive code without losing monorepo benefits. Their code review tooling can express complex semantic constraints, differentiating comment-only changes from sensitive logical changes so human reviewers focus on what matters.

Operational excellence reached new levels with "superfans"—Claude instances tasked with obsessively monitoring single components. These AI monitors access telemetry and logs, detecting subtle issues that traditional alerts miss. The team has a scion-daemon superfan, a scion-cache superfan, and an Antique merge queue superfan, among others.

What This Means for the Industry

Anthropic acknowledges Scion isn't a general-purpose Git replacement. It only makes sense for truly enormous monorepos with tens of thousands of engineers or swarms of agents. The company's ability to spend tokens internally far exceeds what other businesses would realistically want.

However, they predict this class of problems will become commonplace within 6-12 months as AI coding tools proliferate. "We think the most impactful thing we can do is to share our thinking," the team stated. They're collaborating with GitHub, GitLab, and the open-source community to improve Git's server-side architecture.

GitLab has already responded, noting that Anthropic's experience "reinforces the architectural direction we've been pursuing." GitLab is building next-gen SCM for agent-scale performance while preserving Git compatibility. As Bill Staples, GitLab's CEO, put it: "AI agents are fundamentally changing the economics of software development."

Anthropic's Scion isn't just a new version control system—it's a blueprint for how development infrastructure must evolve when AI becomes the primary code generator. The bottleneck has shifted from writing code to managing it, and the tools that served human-scale development are no longer sufficient.