Anthropic's Scion vs Git: Why Anthropic Replaced Git, and What It Means for Your Team

For developers, platform and DevOps engineers, and anyone whose team is merging more AI-written code than it used to. If you are new to version control, the Salesforce admin series starts with what version control is and why it matters.

TL;DR

• On 13 October 2026, Anthropic said it had moved its main monorepo off Git onto Scion, a source control system it built in-house.
• The trigger was AI-scale volume: daily merged changes went from about 2,500 in May to over 30,000 in September 2026. The repository had almost 100 GB of history, and CI checked it out about 25 million times a day.
• Scion is centralised and always online. Commits, rebases and merges happen on the server, working copies are optional and sparse, and jobs can query the repository through an API without a checkout.
• Results Anthropic reports: infrastructure 200x smaller than its Git mirroring setup, CI checkouts in seconds instead of minutes, and a 25% CPU saving in CI.
• Anthropic says Scion is "by no means a suitable replacement for git for general use" and is sharing ideas, not software. Keep using Git. Borrow the ideas that fit.

What You'll Learn

• Why Git struggled at Anthropic's scale, in plain terms
• How Scion's design differs from Git's, side by side
• What Anthropic gave up, and why that would not suit most teams
• Which of Scion's ideas you can apply to Git today

The Problem

Git was designed so that every copy of a repository is complete: the full history lives on every developer's machine, and you can commit, branch and merge offline. For most teams that is exactly right.

AI coding agents change the numbers. When agents write and merge code all day, the repository grows faster, CI runs far more often, and every CI job that clones the repository pays for that full copy. Anthropic hit this early because Claude writes so much of its own code. Any team scaling up agent use will meet a smaller version of the same pressure.

Common Questions This Article Answers:

• Should I stop using Git because Anthropic did?
• How is Scion actually different from Git?
• What can my team copy from Scion without changing tools?

Quick Answer

Scion is Anthropic's answer to a problem very few teams have: a monorepo of almost 100 GB with tens of thousands of merges a day, mostly from agents. It drops Git's "every clone is complete" model for a central server that does the commits and merges, optional sparse working copies, and an API for repository queries. Anthropic itself says it only makes sense at that scale and is not offering it to others. For everyone else, the useful lessons work inside Git: check out only what CI needs, query the server instead of cloning where you can, use a merge queue, and keep testing after merge as well as before, because agents produce more concurrent changes than people do.

A few words you will see

Why Git Struggled at Anthropic

Anthropic's numbers, from its own engineering post:

At that volume, Anthropic estimated Git would need "over 600 PB of git traffic per day". Its summary of the problem: "The properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew."

The core issue is the full copy. Git's design assumes every client has the whole repository, so every CI job that clones it moves a lot of data, and every merge is computed on a client that first needed that copy.

How Scion Works

Anthropic describes Scion through a few design choices:

• Clients are always online. This is the first design principle, and it gives up Git's offline model on purpose.
• Changesets in a write-ahead log. A changeset stores the files that changed relative to its first parent, with pointers to the compressed file contents in blob storage. A Git commit instead points to a full snapshot of the tree.
• The server does the work. "Every commit, rebase, or merge happens on the server, so there's nothing to push."
• Working copies are optional and sparse. Clients can check out only the folders they ask for, or use virtualised checkouts where files appear on demand.
• Everything is an API. The queries the client uses are also exposed as an API, so many CI and automation jobs never need a local repository at all. A job that needs a diff asks the server for it.
• Derived data for history. Because a changeset only records what changed, Scion builds separate structures for blame, file history and walking the commit graph.

Merging without a global lock

The most surprising choice is about concurrency. Most large repositories use a merge queue that tests each change against the latest main before it lands. Anthropic writes that it could not replicate the industry standard of a global lock on the merge queue at its volume, so it invested in post-merge and pre-deploy automated testing instead. Concurrent changes can conflict, and Anthropic says "Claude can typically fix these conflicts faster than humans can even identify them."

At 30,000 merges a day, the safety net moved from "before merge" to "after merge, before deploy".

Scion vs Git, Side by Side

Anthropic credits prior art for huge monorepos, naming Google's Piper and Meta's Sapling.

What Anthropic Gave Up, and Why Most Teams Should Not

Anthropic is direct that Scion is not for general use. The concepts "really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code," and it "diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle."

For a normal team, Scion's trade-offs would cost more than they save:

• No offline work. Every developer and every job depends on the central server being up and reachable.
• No ecosystem. GitHub, GitLab, pull request tooling, IDE integrations and most CI systems assume Git.
• A team to run it. Anthropic had a team of seven build Scion and the systems around it.
• Conflicts after merge. Dropping the merge-queue lock only works if you can detect and fix conflicts quickly after the fact, which Anthropic does with Claude and heavy automated testing.

What You Can Borrow Without Leaving Git

Anthropic's stated aim is for others to "apply some of the most successful parts of Scion to git without departing from the overall model." The ones most teams can use now:

1. Stop cloning everything in CI. Git supports shallow clones (git clone --depth 1), partial clones that fetch file contents only when needed (git clone --filter=blob:none), and sparse checkouts of only the folders a job needs (git sparse-checkout). Most CI jobs need a fraction of the repository.
2. Ask the server instead of cloning. For jobs that only need a diff, a file or a list of changed paths, your Git host's API can often answer without a checkout.
3. Use a merge queue before agent volume makes "it passed on my branch" meaningless. GitHub calls it a merge queue; GitLab's equivalent is merge trains.
4. Test after merge as well as before. Pre-merge gates catch most problems. When many agent changes land close together, a post-merge, pre-deploy test run catches the conflicts between them.
5. Measure your merge rate. If AI agents are multiplying your daily merges, you will see CI cost and queue times rise before anything breaks. Track both.

For Salesforce teams

Most Salesforce DX projects are nowhere near Scion's scale, so nothing here is urgent. Two points still apply. If agents start opening many small pull requests against your metadata repository, a merge queue and a post-merge validation deploy to a sandbox will save you from changes that pass alone and fail together. And CI jobs that only validate a few components can use sparse or shallow checkouts to cut run time. New to Git? Start with Git Basics for Salesforce Admins.

Frequently Asked Questions

Q: Can I use Scion?

A: No. Anthropic has not released it and says it is difficult to offer in a form that would be broadly useful, because it diverges so far from Git. It is sharing the design ideas instead.

Q: Is Git going away because of AI?

A: Not for most teams. Anthropic itself says Git's decentralised design "is the right design" for the vast majority of repositories. What AI changes is the volume of merges and CI runs, and Git already has features (partial clones, sparse checkouts, and merge queues or merge trains on the major hosts) that address much of that.

Q: How long did Anthropic's migration take?

A: Five months, by a team of seven, while the volume of code merged per day grew tenfold.

Q: What is the biggest idea to take from Scion?

A: Most automation does not need a full copy of the repository. Checking out only what a job needs, or asking the server directly, is where Anthropic saw its biggest gains: checkouts in seconds instead of minutes and a 25% CPU saving in CI.

Key Takeaways

• Scion solves an extreme problem: a monorepo of almost 100 GB with over 30,000 merges a day, mostly from AI agents.
• It trades Git's offline, distributed model for speed at scale: server-side merges, sparse working copies and API access.
• It is not for you, and Anthropic says so. It is internal, unreleased, and only makes sense at enormous scale.
• The lessons work in Git today: partial and sparse checkouts in CI, server-side queries, merge queues, and testing after merge as well as before.

What's Next?

Recommended Reading:

• What is Version Control and Why Every Salesforce Admin Needs It
• Git Basics for Salesforce Admins
• Salesforce in Claude: Token Cost of OrgPulse vs DX MCP vs the sf CLI, another look at what AI-scale work costs

Action Items:

1. Check how many merges your main repository takes per day now, and how that has changed since your team started using AI agents.
2. Look at your slowest CI job and see whether a shallow, partial or sparse checkout would cover what it needs.
3. If agents are opening many small changes, switch on your Git host's merge queue.

Resources & References

• Anthropic Engineering: Redesigning source control at Anthropic
• The Register: Anthropic reinvents source control as Claude floods the world with code
• Git documentation: git-sparse-checkout
• Git documentation: partial clone
• GitHub Docs: Managing a merge queue