Anthropic replaced git with its own system, Scion Claude agents merge over 30,000 changes a day there

On 13 October 2026 Anthropic described Scion on its engineering blog: an in-house version control system that replaced git for its entire monorepo after a five-month migration. The reason is right there in the first paragraph. Writing code is no longer the bottleneck at Anthropic, because Claude produces so much of it that the infrastructure built for humans, meaning version control, builds and CI, started to choke.

In May 2026 Anthropic merged around 2,500 changes a day on average. By September it was over 30,000, a twelvefold increase in four months. The company doesn’t expect it to slow down, because in its words “the latent demand for merging code is practically infinite”, and every bottleneck it removes immediately increases the amount of code produced.

I’ve pulled together what’s known about Scion from Anthropic’s post and from coverage by The Pragmatic Engineer, The Register and Simon Willison. Further down I look at why git and GitHub struggle with agent traffic and what’s left for teams that merge far fewer than 30,000 changes a day, including a few commands worth setting up in CI today.

Scion at a glance

Question	Details
What it is	Anthropic’s internal, centralised version control system
Announced	13 October 2026 (post updated 15 October)
Scale	Over 30,000 merged changes a day (September 2026)
Build and migration time	5 months, a team of 7
Technology	Server and client in Rust, data in Google Spanner and Cloud Storage (per The Pragmatic Engineer)
Companion tools	Antique (code review), code search, repository permissions (IAM)
Availability	Internal only, no plans for a release or open source
Inspired by	Piper (Google), Sapling and its Mononoke server (Meta)

Why git stopped being enough for Anthropic

Git is a distributed system. Every clone is a complete repository that can compute a diff, show history and blame, and switch to any revision without a network connection. Anthropic acknowledges that for the vast majority of repositories this is the right design and a big part of why git became the standard.

Anthropic’s monorepo no longer fit those assumptions:

• the history of the main branch alone is almost 100 GB,
• a compressed working copy takes over 25 GB,
• CI alone runs about 25 million checkouts a day, not counting developer environments, agent sandboxes and research jobs.

If every checkout fetched the repository naively, Anthropic says that would mean over 600 PB of git traffic a day (25 million × 25 GB).

The company had already been through all the standard workarounds: shallow clones, sparse checkout, partial clones, internal mirrors (several hundred at the peak) and ready-made repository snapshots in blob storage. That bought some time, but snapshots drifted away from the tip of main between refreshes, history-dependent operations on partial clones took more and more effort to keep working, and the mirrors stopped scaling once the repository outgrew their disks and memory.

Like most companies, Anthropic was using git as a centralised system with one authoritative copy anyway, and nearly all its clients were agents and CI jobs that are online by definition. The features that make git great for distributed, offline work had started to get in the way of scaling. So the team asked what version control would look like if you designed it from scratch for clients that are always online.

How Scion works

Six design principles

1. Clients are always online. A client doesn’t keep a full copy of the repository and fetches data when it needs it.
2. Client-server asymmetry. The server answers questions about history and blame, creates commits and performs merges and rebases. The client keeps a bounded object cache, lays out working copy files and tracks changes, so it can compute very little on its own but needs far less data.
3. A full version control API. A CI job that wants to know who last changed a line, or how two commits relate, doesn’t need a local repository. Without that access, the automated bisect and revert pipelines wouldn’t be practical at this scale.
4. Everything scales horizontally. Repository data is distributed, and no full, materialised copy of it exists anywhere, not even on the server. There are no packfiles, so there’s no repository maintenance (gc, repack) either.
5. Commits are cheap, incremental and lock-free. Commit, rebase and merge happen on the server, so there’s nothing to push, and the cost of a commit grows with the size of the change, not of the repository. Branches and tags outside main and release branches are discouraged, because Anthropic sees global state that every server must agree on as a ticking scaling problem.
6. The working copy is optional and partial. Many reads and writes go through the API alone. When a job really needs files on disk, it gets a partial checkout (only the listed directories) or a virtualised one, where a file appears only when it’s first read.

Changesets instead of commits

The basic unit in Scion is the changeset, an entry in a write-ahead log. Instead of pointing to the whole file tree like a git commit, it stores the list of files changed relative to the first parent, plus content-addressed pointers to compressed content in blob storage. Changesets are created on the server and are available everywhere straight away, and the server accepts them at very high throughput because there are no packfiles to ingest, no locks and no coordination between servers.

Questions a changeset alone can’t answer quickly (who last edited a line, which commits touched a file) are handled by derived data: blame indexes, path history and skip lists for the commit graph, all computed with one generic recursive mechanism from the values for a changeset’s parents. A new index is easy to add whenever it would speed up an operation, and because clients never see inside these structures, the server can change them without any client changes.

Three cache tiers

The Scion client (scn) doesn’t tell the server what it already has. It starts at the root of the tree, checks locally for missing subtrees and requests them recursively. Every request is for a specific object that never changes, so any cache can serve it and an interrupted fetch can resume. The infrastructure has three tiers: scion-daemon on every machine, scion-cache in every region (trees and files straight from memory) and the authoritative scion-server reading from Spanner and cloud object storage. All of them answer the same RPC calls, but Anthropic keeps the tiers in a fixed order so that a regional cache outage can’t flood the servers.

Results according to Anthropic

Metric	Result
Cache hit rate	Over 99% on every tier
CPU and memory compared to git mirrors	200 times less
Checkout in CI and research jobs	Seconds instead of minutes (two orders of magnitude faster)
CPU capacity recovered in CI	25%
git → Scion import pipeline rewritten by Claude Mythos Preview	20 times less memory, 4 times faster

Nick G., the post’s author, told The Pragmatic Engineer that every component can autoscale, but so far that hasn’t been needed, even though the merge rate grew more than tenfold this year. Most of the work is done by caches, because content-addressed data never changes once it’s written. For agents, though, the numbers matter less than the fact that bisect, revert or a diff against main are API calls rather than tens of gigabytes of cloning. An agent usually needs an answer more than a working copy.

Antique, the end of the merge queue and the new role of engineers

The team behind Scion also built Antique, a code review tool (with a Go backend and a React frontend, according to The Pragmatic Engineer), along with code search and a permissions system. Antique can express semantic approval rules, such as telling a comment-only change apart from a sensitive logic change, and Scion supports permissions on individual directories, so the most sensitive code can be protected without splitting the monorepo.

The part I found most interesting is dropping the classic merge queue. Anthropic asks what CI even means when hundreds of changes can land on main during a single test run. At 30,000 merges a day that’s about 21 changes a minute, so a 20-minute test run sees around 400 other changes land on main before it finishes. A global lock on the repository during tests couldn’t be reproduced at this scale, so Anthropic tests automatically after merge and before deployment. Conflicts between parallel changes do happen, but according to the company Claude can typically fix them faster than humans can even spot them.

The post also says a lot about how engineering work is changing:

• Seven people built Scion, Antique and several related systems, then ran the migration in five months. Anthropic writes that a project like this would once have taken the company years.
• Every engineer on the team would now rate Claude as a better coder than they are, so their job has moved towards architecture and guarding system constraints. Agents can break key invariants to match a pattern that should never have been allowed in the first place. During the migration, for example, several systems decided a change had merged by reading the commit log linearly instead of asking the code review tool.
• Review by another agent works well but can be short-sighted and push code towards over-engineering. Humans still review every change, but they judge its intent rather than every line.
• The team tests more than ever: hermetic simulations of infrastructure interactions, fuzzing, rate limiting. Claude also found optimisations that would have taken an expert days or weeks to analyse.
• Using Claude Tag, the team set up Slack channels where a “superfan” Claude obsessively watches one component, reads telemetry and logs, and according to Anthropic catches subtle problems that make classic alerts look one-dimensional.

Why git and GitHub are struggling with AI agents

Anthropic is an extreme case, but the same trend shows up on GitHub, which back in April paused sign-ups for Copilot Pro and Pro+ because agents were using more compute than the plans assumed. Three numbers from this year, all from GitHub itself:

• April 2026. Kyle Daigle, GitHub’s COO, wrote that the platform saw 1 billion commits in all of 2025 and was now seeing 275 million a week, a pace of 14 billion a year if growth stays linear, which he added it won’t.
• August 2026. After the 17 August outage, which lasted 7 hours and 47 minutes, GitHub CTO Vlad Fedorov said monthly commits had grown from 1.4 to 2.9 billion since April. GitHub added over 3 million CPU cores and 120 PB of storage this year, and the outage came down to a lack of capacity in the Central US data centre.
• October 2026. GitHub said September alone saw 7.38 billion commits, more than five times as many as a year earlier, and GitHub Actions ran 3.26 billion times. That figure is well above the CTO’s 2.9 billion for August, and GitHub doesn’t say whether both were counted the same way, so I’d compare them with care.

Git was created in 2005 for people who clone a repository once, work on it for weeks and push a few commits a day. Agents work differently, and each of git’s assumptions starts to cost money when they do:

• Every clone is a full repository. An agent starts in a fresh sandbox, so every task begins with a new clone. GitHub writes that CI and code scanning fetch the same branch tip thousands of times a minute.
• Simple questions need local history. git blame, git log and finding the merge base are computed on the client, so a CI job needs history on disk. A shallow clone won’t do, and a full one is expensive.
• Negotiation and packfiles load the server. On git fetch the server works out the missing objects and builds a delta-compressed packfile. The response is different for every client, so it’s hard to cache, and it has to start over if the connection drops.
• Every write is global state. An agent in a tight loop commits after almost every action, and every push moves refs, which need agreement between replicas. In GitHub’s architecture (Spokes) every repository lives on five servers and every write involves all of them, so adding replicas for reads slows writes down.
• The repository needs maintenance. Periodic gc and repack compete with serving traffic when hundreds of agents write non-stop.
• Processes are built for human scale. Pull requests, line-by-line review and merge queues assume there are few enough changes for a person to look at them. The New Stack wrote in July that the merge gate turns into a liability as agents multiply.

GitHub is rebuilding its infrastructure on principles very similar to Scion’s. Its October post describes separating storage from compute: authoritative repository data goes to Azure Blob Storage, reads are handled by lightweight caching servers, only ref updates still need agreement between replicas, and compaction and garbage collection run on separate machines. In internal tests GitHub measures up to 35 times higher write throughput. It’s sticking with git and its protocol, so this still isn’t Scion, but the direction is shared: immutable objects in cheap storage, a cache layer in front of them and as little global coordination as possible.

Startups are answering the same problem. Entire, from former GitHub CEO Thomas Dohmke ($60 million seed round in February 2026), is building a distributed git network for teams where agents write code faster than people can review it. Cursor offers paid users Origin, its own git hosting with built-in agents, and Pierre Computer Company sells Code Storage, API-driven git infrastructure. All three stay git-compatible, which Scion doesn’t.

Downsides, risks and doubts

• No offline work. A Scion engineer replied on Hacker News that since its heaviest user is Claude, which is online by nature, offline support simply wasn’t a priority. That’s true for agents, less so for people on a train or a plane.
• Centralisation is a single point of failure. When the central server goes down, the whole company stops, as this year’s GitHub outages show. The tiered architecture is meant to prevent that, but the post describes no incidents, so nobody knows how Scion handles outages in practice.
• Dependence on one cloud. According to The Pragmatic Engineer, changesets live in Google Spanner and files in Google Cloud Storage.
• Nobody outside Anthropic can use it. Scion is closed, and The Pragmatic Engineer says it’s mostly a matter of bandwidth, since even an unsupported code drop takes a lot of work to do well. The company also writes that Scion “is by no means a suitable replacement for git for general use”. Whether Anthropic will contribute anything to git as code rather than ideas remains open.
• The whole ecosystem has to be rebuilt. Its own code review, code search and CI are one thing, but IDE integrations, GitHub Actions and every tool that assumes git stop working. Gergely Orosz compares it to Google, where engineers who leave can find they’ve lost touch with industry-standard tools.
• Main can be red. Without a merge queue, broken code can land on main, and Anthropic relies on Claude fixing conflicts quickly. The company doesn’t say what that costs, but it does admit its internal token spend far exceeds what any other business would realistically want to spend.
• Simplified history and reviewing intent instead of code. Scion records changes only against the first parent and discourages branches, and people judge what a change is meant to do rather than every line. That works for trunk-based development in a monorepo, but it means less control over the code.
• Are 30,000 merges productivity? In the Hacker News discussion (close to a thousand comments) a recurring question was whether this measures value or just a lot of traffic. All the numbers come from Anthropic and nobody has verified them independently.

The Mononoke dispute and credit

Two days after publication Anthropic added a footnote that credits many of the techniques used in Scion to Mononoke, the server behind Meta’s Sapling, and its Bonsai data model. The original post mentioned only Piper and Sapling.

The update was a response to criticism. The person The Pragmatic Engineer describes as Mononoke’s creator accused Anthropic of copying the design, including the Bonsai model and the derived data concept, without proper credit, and not by accident, since some of the same people worked on both projects. Nick G. replied on Hacker News that the team named Sapling because that’s the name Meta uses publicly for the whole system, Mononoke included, that they hadn’t meant to hide anything, and that Mononoke deserves a lot of the credit. Nobody alleged a licence breach. Gergely Orosz points out that open source can be used freely within its licence, but he calls it poor form that it took a public complaint for Anthropic to acknowledge where the ideas came from.

What’s actually new about Scion

Scion isn’t the first centralised version control system. The Register and Simon Willison immediately compared it to Subversion, and large companies have built their own systems before: Google built Piper when it outgrew Perforce, Meta created Sapling after years on Mercurial, and Microsoft built VFS for Git for the Windows repository (about 3.5 million files and 300 GB). I see four new things in this story:

• Big-company problems arrive earlier. Google and Meta needed tens of thousands of engineers to hit the wall. Anthropic hit it with a few thousand employees, because each of them works with many agents. Gergely Orosz estimates the company produces as much code as an organisation with 35,000 to 70,000 staff.
• The client isn’t a person. Git assumes a person with a laptop who is sometimes offline. Scion assumes an agent that’s always online, gets a sandbox for a few minutes and needs answers rather than a copy of the repository.
• The bottleneck keeps moving. First it was writing code, then version control and CI, and now it’s review and verification. Dropping the merge queue shows where the next problem will be.
• Concrete proposals for git. Anthropic isn’t calling for anyone to abandon git. It suggests that a git server shouldn’t have to behave like a client, that platforms should offer a full server-side API (ideally standardised across GitHub, GitLab and others), and that partial and shallow clones should work better together. Whether GitHub, GitLab or the git project take that up remains to be seen.

Anthropic expects problems of this kind to become commonplace within 6 to 12 months, and GitHub’s numbers suggest that’s a realistic forecast.

What this means for you

If your team merges dozens or hundreds of changes a day, git and GitHub are here to stay and you don’t need to change anything. Anthropic itself writes that Scion’s concepts only make sense for truly enormous monorepos with tens of thousands of engineers or swarms of agents. A few lessons still apply to anyone running agents (Claude Code, Codex, Copilot) in CI or in parallel on their own machine:

• Don’t clone more than you need. A plain build usually only needs a shallow clone (--depth=1). For jobs that need history but not every file, use a partial clone with sparse checkout:

git clone --filter=blob:none --sparse https://github.com/company/repo.git

git sparse-checkout set src/app docs

• With several agents on one machine, use worktrees instead of extra clones. Each agent gets its own working directory on shared objects:

git worktree add ../repo-agent-2 -b agent-2

• Ask the API instead of cloning. You can get a branch comparison or the blame of a single file from the GitHub API (REST compare, the blame field in GraphQL) without a local copy.
• Push less often. An agent can save checkpoints locally and push one tidy change.
• Plan for a GitHub outage. After this year’s downtime, a repository mirror and the ability to deploy without GitHub no longer count as paranoia.
• Point human attention where it’s needed. CODEOWNERS and branch protection rules for sensitive directories are a simple version of what Anthropic does in Antique.

Summary

Scion is Anthropic’s answer to a problem most companies don’t have yet: AI agents write code so fast that git, designed for people working offline, became a brake. Anthropic reversed git’s assumptions: the client is a thin cache, the server answers questions through an API and creates commits itself, and immutable data is easy to cache.

Scion won’t replace git and won’t leave Anthropic, but it shows clearly where git and GitHub will crack as agents multiply. GitHub is already rebuilding its infrastructure in a similar spirit, and new companies are building git hosting for agents. The most practical takeaway for now: before you point a fleet of agents at your repository, check how many times a day each of them clones it.

Frequently Asked Questions

What is Anthropic Scion?

It is an internal, centralised version control system that Anthropic moved its monorepo to from git. It was designed for AI agents that are always online: the server handles commits, merges and history queries, while the client keeps only a bounded cache and, when needed, a partial copy of the files.

Will Scion replace git?

No. Anthropic writes that Scion "is by no means a suitable replacement for git for general use" and only makes sense for enormous monorepos. Instead, the company suggests git platforms adopt some of its ideas, such as a full server-side API.

Can I download or try Scion?

No. Scion is closed and Anthropic has no plans for a public release or open source. It has published only its design principles and a description of its data structures.

Why does git struggle with AI agents?

Git assumes every clone is a full repository and that computation (blame, diff, merge) happens on the client. Agents start in fresh sandboxes, so they clone the repository for almost every task, commit after almost every step and are always online. With a large repository that means huge traffic, server load and contention on writes.

What is Antique?

It is the code review tool Anthropic built alongside Scion. It lets the team define semantic approval rules, such as telling comment-only changes apart from sensitive logic changes, so people can focus on the changes that matter most.

Is Anthropic leaving GitHub?

Internally, yes: the monorepo is entirely on Scion and smaller repositories are being migrated. According to The Pragmatic Engineer, public projects such as the Claude Code repository, skills and plugins stay on GitHub. Anthropic also says it wants to work with GitHub and GitLab on scaling git.

Sources

1. Anthropic: Redesigning source control at Anthropic https://www.anthropic.com/research/redesigning-source-control
2. The Pragmatic Engineer: The Pulse: Anthropic builds its own source control system https://blog.pragmaticengineer.com/the-pulse-anthropic-builds-its-own-source-control-system/
3. The Register: Anthropic reinvents source control as Claude floods the world with code https://www.theregister.com/a/5302943
4. Simon Willison: Redesigning source control at Anthropic https://simonwillison.net/2026/oct/13/redesigning-source-control-at-anthropic/
5. Simon Willison: Kyle Daigle (GitHub) quote on commit volume https://simonwillison.net/2026/Apr/4/kyle-daigle/
6. GitHub Blog: The August 17 outage, and the work ahead https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/
7. GitHub Blog: Building Git infrastructure for agent-scale development https://github.blog/engineering/infrastructure/building-git-infrastructure-for-agent-scale-development/
8. The New Stack: Your merge gate was a compromise. Coding agents are making it a liability https://thenewstack.io/merge-gate-coding-agents/
9. Engineering at Meta: Sapling: Source control that's user-friendly and scalable https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/
10. Brian Harry (Microsoft): The largest Git repo on the planet https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
11. TechCrunch: Former GitHub CEO raises record $60M dev tool seed round at $300M valuation https://techcrunch.com/2026/02/10/former-github-ceo-raises-record-60m-dev-tool-seed-round-at-300m-valuation/
12. IT Brief: Cursor rolls out Origin code hosting to paid users https://itbrief.com.au/story/cursor-rolls-out-origin-code-hosting-to-paid-users
13. Pierre Computer Company: Code Storage https://code.storage/