30,000 merged code changes per day, a main-branch history approaching 100 gigabytes, and 25 million checkouts daily — numbers that would have brought a classic Git setup to its knees long ago. That is exactly what happened at Anthropic. The company’s answer is called Scion, a completely new version control system that has fully replaced Git in its internal monorepo. The rollout of Anthropic’s Scion version control marks one of the clearest signs yet of how far autonomously working AI agents can shake the foundations of classic software development.
The case is notable because it doesn’t come from an academic thought experiment, but from the daily practice of a company whose own AI model, Claude, writes code at massive scale. According to Anthropic’s official engineering blog from October 13, 2026, the volume of daily code merges grew from around 2,500 in May 2026 to over 30,000 by September — a tenfold increase within a few months. Independent reporting, including from dev.to and ai-tldr.dev, confirms this account.
Table of Contents
Key Takeaways
- Anthropic fully migrated its internal monorepo from Git to its own newly built system, Scion, within five months.
- The trigger was Claude-driven growth in daily code merges, from around 2,500 to over 30,000.
- Scion relies on permanently connected clients, strong client-server asymmetry, and horizontal scalability instead of complete local copies.
- Anthropic says the infrastructure footprint for version control dropped 200x compared to the previous Git mirrors.
- Scion will not be open-sourced and is not intended as a general Git replacement — only relevant for extremely large monorepos.
Why Git Hits Its Limits in the AI Era
Git was originally designed for a world where human developers occasionally work offline, keep local copies of the entire repository, and generate a manageable number of commits. This model worked reliably for decades, even for very large projects.
At Anthropic, that balance tipped within just a few months. The decisive factor was no longer the number of human developers, but the amount of code Claude itself produced autonomously. Agent systems work around the clock, generate countless parallel code changes, and constantly need new, isolated working environments. Each of these sandboxes requires its own checkout of the repository.
The resulting load illustrates the scale of the problem:
- The history of the main branch now spans nearly 100 gigabytes.
- A compressed working copy exceeds 25 gigabytes.
- There are roughly 25 million code checkouts per day, spread across CI systems, agent sandboxes, and developer environments.
- Served naively via classic Git clones, these checkouts would generate more than 600 petabytes of traffic — per day.
To cope with this load, Anthropic previously ran several hundred internal Git mirrors. According to the company, this model became increasingly impractical: the operational overhead, synchronization problems, and sheer amount of redundant infrastructure were no longer in reasonable proportion to the benefit.
The Architecture of Anthropic’s Scion Version Control in Detail
Instead of continuing to patch Git, the responsible team opted for a radical fresh start. Scion’s core assumptions differ fundamentally from those of classic version control systems.
Always Online Instead of Offline-First
Git was designed for developers who also need to work without an internet connection. In a world where both human developers and AI agents work almost constantly connected, this assumption is no longer strictly necessary. Scion therefore assumes clients are permanently online, letting it skip many of the mechanisms Git maintains for offline capability.
Client-Server Asymmetry Instead of Equal Distribution
In Git, client and server essentially carry the same load: every client holds a complete copy of the history and can perform commits, merges, and rebases locally. Scion deliberately breaks with this symmetry principle. The compute-intensive operations — commits, merges, rebases — are handled by the server. The client holds only a bounded local cache.
Horizontal Scalability Without a Complete Repo Copy
A central design goal was that no complete copy of the entire repository needs to exist anywhere in the system. Instead, the whole architecture is built to scale horizontally. This allows load to be distributed across many smaller, interchangeable components instead of depending on a few large mirrors.
Sparse Working Copies by Default
The working copy itself is also optional and "sparse" by design in Scion. That means only the directories actually needed are materialized on local disk. For a monorepo of this size, that’s a decisive difference — nobody actually needs the company’s entire codebase locally for a single task.
"Scion is built for clients that are always online, and for servers that do the heavy lifting — not the other way around." This inversion of the classic Git model is the core of the entire architecture.
Changesets Instead of Classic Commits
The fundamental unit of data in Scion is called a changeset. Unlike a classic Git commit, which often implicitly references the entire tree state, a changeset stores only the files actually changed relative to its first parent.
Technically, it’s an entry in a write-ahead log. Each changeset contains content-addressed pointers into a separate blob store. This approach has several advantages for a system at this scale:
| Characteristic | Classic Git | Scion Changeset |
|---|---|---|
| Referenced data | Often the full tree state | Only changed files relative to first parent |
| Storage mechanism | Local object database on the client | Content-addressed blob storage, server-side |
| Protocol structure | Distributed object history | Write-ahead log as the core structure |
| Scaling direction | Vertical, per repo copy | Horizontal, across many servers |
This structure allows the history to be managed more efficiently, without every client or server having to physically hold the entire chain of changes ever made.
More Than Version Control: The Whole Toolkit
Notably, Scion wasn’t built in isolation. In the same five-month period, the team built three additional components that work closely with the new version control system:
- Antique: a code review tool specifically designed for reviewing AI-generated changes at scale. With tens of thousands of daily merges, a classic pull-request workflow no longer suffices. A related example of agent-friendly developer tooling at Anthropic is Claude Code Mods, Anthropic’s TypeScript extension system for its own AI coding agent.
- A new code search: necessary because classic search indexes quickly become stale or too slow for a monorepo growing this fast.
- An IAM system for source control: for granular control over who — human or agent — has access to which parts of the repository.
Together, these four components form what Anthropic sees as the new foundation for software development in an era of large-scale AI code generation.
Who Built Scion?
The team’s size relative to the project’s scope is also remarkable. The complete migration from Git to Scion, including the three additional tools, was carried out by just seven engineers. Nick G. is named as the lead author; the rest of the team consisted of S.G., R.K., Dan C., Garrett H., Ben L., Colin M., and Joe P.
That such a small team could build a production-ready version control system for a company of this size within five months is also presented by Anthropic itself as evidence of the productivity gains from AI-assisted development — though the blog post provides no additional quantitative figures beyond the facts stated.
The Measured Effect: A 200x Efficiency Gain
Perhaps the most tangible fact from the announcement concerns infrastructure costs. Anthropic states that Scion reduces the infrastructure footprint for version control by 200x compared to the previous setup with hundreds of Git mirrors. This figure illustrates just how inefficient the old mirror-based model had become relative to the actual demands of an AI-driven development process.
Scion Compared: Piper, Sapling, and the Limits of Transferability
Anthropic isn’t the first company to run into Git’s limits with extremely large monorepos. Google has long operated its own system called Piper, and Meta built a comparable in-house solution, Sapling, for its monorepo structure. Both systems follow a similar idea: at repositories with tens of thousands of developers and millions of files, the classic, decentralized Git model hits structural limits.
With Scion, Anthropic joins an existing tradition of large tech companies building their own version control systems for their specific scaling requirements. The crucial new factor at Anthropic, however, is that the primary trigger wasn’t growth in human developer teams, but growth in autonomously working AI agents.
Importantly, Anthropic explicitly states that Scion will not be open-sourced and is not intended as a general Git replacement for ordinary companies. By Anthropic’s own account, its Scion version control only makes sense for extremely large monorepos with tens of thousands of developers, or with swarms of AI agents producing code at a comparable scale. For most of the software industry, Git remains the sensible choice.
At the same time, Anthropic says it wants to share lessons learned with the broader Git community and with providers like GitHub and GitLab. Specifically mentioned are ideas like server-side RPCs and generally better scaling mechanisms for Git servers. That suggests at least some aspects of Scion’s architecture could eventually make their way into existing, widely used tools, even though Scion itself won’t appear as a standalone product on the market.
Why This Could Become Relevant for Other Companies
Even though Scion itself won’t become a mainstream product, the underlying development matters for many technically oriented organizations. More and more companies are using AI agents not just for autocomplete, but to independently create pull requests, write tests, and refactor code. Once these agents work in parallel at greater scale, the number of commits, branches, and checkouts grows at a pace classic version control infrastructure can’t easily sustain.
Relevant lessons from the Anthropic case for other teams:
- Load from CI systems and automated checkouts often grows faster than load from human users — that should be factored into capacity planning early.
- Mirror-based scaling approaches quickly hit economic and operational limits under exponential growth.
- Sparse checkouts and server-side processing can help within the existing Git ecosystem before a completely new system becomes necessary.
- Code review processes need rethinking once a significant share of changes no longer comes from humans but from agents.
Conclusion and Next Steps
The case of Anthropic’s Scion version control shows, in exemplary fashion, how fundamentally development processes can change once AI agents don’t just assist, but produce code themselves at scale. Within five months, and with a comparatively small team of seven engineers, Anthropic didn’t just build a new version control system — it built an entire accompanying toolkit for code review, code search, and access management.
For most companies, there’s currently no reason to replace Git. Still, it’s worth it for technical decision-makers to critically examine their own infrastructure: how would the existing version control system react if the number of daily code changes increased tenfold within a few months? Anyone who can’t reliably answer that question should plan scaling reserves early, evaluate server-side processing and sparse checkouts, and prepare their own CI and review processes for possible growth driven by AI agents — long before a overhaul like Anthropic’s becomes necessary.
