Anthropic went from about 2,500 code changes merged per day in May 2026 to more than 30,000 in September. Git couldn’t keep up. Instead of patching it, Anthropic replaced it in its internal monorepo with a new system called Scion.
If you’ve seen it described as “Claude’s new Git”, it’s worth clarifying that up front. Scion isn’t a product you can install, it hasn’t been released as open source, and according to Anthropic itself, it is not a replacement for Git for general use. It’s infrastructure built for a very specific case: a huge monorepo, millions of checkouts a day, and most of its clients are agents and automated jobs.
Don’t confuse it with Google Cloud’s scion project, either. That one is a tool for orchestrating coding agents. Two different things, same name.
This article summarizes the architecture Anthropic describes in its October 13, 2026 post, with the figures attributed to that source. They are internal numbers that I can’t verify independently, and I treat them that way throughout.
The numbers that broke Git
According to Anthropic, the main branch history of its monorepo is almost 100 GB, and a compressed working copy is over 25 GB. That’s big, but the real problem is checkouts: there are about 25 million CI checkouts a day. If each one were done with a naive clone, Git traffic would exceed 600 PB per day, according to the same post.
To cope, the team used what Git already offers: shallow clones (--depth), sparse checkouts, promisor remotes, and seeds stored as blobs. It helped, but at one point they were running several hundred internal Git mirrors at once, which became harder to operate as merge volume grew. The seeds also drifted from the tip of main and had to be refreshed.
Why Git doesn’t fit agents
The core idea of the post is simple to state: Git was designed for distributed, disconnected systems, but in Anthropic’s usage almost every client is always online.
Git assumes every client holds a full copy of the repository and works offline. That’s a virtue for a developer on a train. For a CI job that only needs the diff between two commits, a full copy is cost with no benefit. In practice, Git works like a centralized system with one authoritative copy, but pays the price of a decentralized one.
The design principles Anthropic describes follow from that:
- Clients are always online. The client fetches data when it needs it instead of keeping a full copy.
- Client-server asymmetry. The server handles history, blame, commits, merges, and rebases. The client keeps a bounded cache and the working-copy files.
- Source control as a service. Queries are exposed through an API, so many jobs need no local repository. Automated bisect and revert pipelines depend on this.
- Horizontal scaling without a full copy. Data is distributed, and no complete copy of the repository exists anywhere, not even on the server.
- Incremental, lock-free commits. Commits, rebases, and merges happen on the server, so there’s nothing to push. The cost scales with the size of the change, not the size of the repository.
Anthropic cites Google’s Piper and Meta’s Sapling as prior art.
The data model: changesets instead of commits
This is the most technically interesting part. In Git, a commit points to a full tree, which points to blobs and other trees. Every object is identified by a hash of its content. The Pro Git chapter on Git objects is the official reference if you want the details.
Scion changes the basic unit. The main entity is the changeset, an entry in a write-ahead log. Instead of pointing to a tree, a changeset lists the files that changed relative to its first parent, with content-addressed pointers to compressed blobs in storage.
| Aspect | Git | Scion (per Anthropic) |
|---|---|---|
| Basic unit | Commit pointing to a full tree | Changeset: list of changes relative to the first parent |
| Storage | Loose objects or packfiles that must be maintained | No packfiles, no repository maintenance |
| References | Ref files updated on disk | Compare-and-swap updates on a single Spanner row |
| Commit creation | On the client, then pushed | On the server, nothing to push |
| Blame and path history | Computed at query time | Precomputed derived structures |
What I find most elegant is the split between primary data and derived data. Blame, path history, skip lists for the commit graph, and path-based search indexes aren’t stored in the changeset. They’re computed from it using one generic mechanism: each type of derived data is defined recursively from its parents’ values. According to Anthropic, that makes it possible to add new types, compute them eagerly or lazily, and optimize them without touching the client.
The cost of that design is obvious: everything depends on the derived layer being well built and well maintained. It’s a bet on infrastructure over simplicity of the model. For Anthropic it makes sense. For a ten-person team, probably not.
Anthropic also cites Spanner as its storage layer, which fits an architecture that needs writes without cross-server coordination. If you want to understand that kind of database, the Spanner documentation on Google Cloud is the place to start.
A three-tier architecture
Scion is organized in three layers that answer the same RPC API, so the client doesn’t need to know the topology:
scion-daemon: one per node. It stores objects for all the jobs on that node and starts from a periodically refreshed snapshot.scion-cache: regional. It serves objects from memory, in the same on-disk format as the daemon.scion-server: the authoritative source. It reads from Spanner or cloud storage on cache misses.
Anthropic stresses that the layers are strictly separated to isolate failures. A regional cache failure shouldn’t take down the tier above it. It’s a familiar pattern in caching systems, but applied to version control it stands out.
The transfer protocol changes too. Instead of a multi-gigabyte packfile, the client starts from a root tree, checks which trees it’s missing locally, requests them recursively, and then does the same for blobs. Requests are for immutable objects, so any cache can answer them. Transfers are resumable. Sparse and virtualized checkouts work without special support.
Results Anthropic reports
Here are the figures the company publishes:
- Each tier maintains a cache hit rate above 99% and holds no long-lived state.
- The infrastructure footprint (CPU and memory) is about 200 times smaller than the previous Git mirroring setup.
- CI and research checkouts go from minutes to seconds, roughly two orders of magnitude faster.
- CI alone frees up 25% of CPU capacity.
My read: impressive results, but they need context. They’re internal metrics, compared against a system Anthropic describes as overloaded by design, and there are no public benchmarks to reproduce them. If your team has a 2 GB repository, these numbers say nothing about your case. What they do show is that the bottleneck of a huge monorepo is rarely the history algorithm. It’s how many times you copy the code.
No global lock: the merge queue changes shape
A traditional merge queue works with a global lock: one change goes in, everyone else waits. At 30,000 merges a day, that doesn’t scale. Anthropic says it hasn’t replicated that lock. Instead, it relies on automated tests after the merge and before deployment. Concurrent changes can conflict, but according to the post, Claude usually fixes those conflicts faster than a human could even detect them.
This is probably the riskiest decision in the post, and the one that will generate the most debate. Dropping strict serialization is reasonable when you have very good tests and a fast repair loop. Without those, it’s a recipe for breaking main often.
Antique and per-directory permissions
Alongside Scion, Anthropic built a code review tool called Antique. Its most interesting feature is semantic approval rules: it can tell a change that only touches comments from one that modifies sensitive logic, so human reviewers focus on what matters.
Scion also includes access control per repository and per directory, which lets you protect sensitive code without giving up the benefits of a monorepo.
Claude’s role in its own system
This is the most self-promotional section of the original post, so read it with some distance. Anthropic says several components were built with the help of internal models, including Claude Mythos Preview:
- Engineers wrote a prototype of the pipeline that imports Git history into Scion by hand. An early snapshot of Mythos Preview rewrote it to use 20 times less memory and run 4 times faster, while keeping the ordering and data-structure invariants.
- Claude found an algorithmic improvement in ancestry queries that an index had missed. According to Anthropic, an expert would have needed days or weeks.
- Claude helped build hermetic simulations of the infrastructure, plus fuzzing and rate-limiting tests.
- Claude agents monitor specific components, such as
scion-daemon,scion-cache, or the Antique merge queue, through Slack channels, using telemetry and logs.
What I find most honest in the post is that the engineers say they often had to tell Claude no. When the model proposed over-engineering based on hypothetical problems or broke system constraints, they pushed back. And the review work shifted toward the intent of a change rather than every line.
According to the post, the team was seven engineers who built Scion, Antique, and about six related systems, and completed the migration in five months while merge volume grew roughly tenfold.
What you can apply today
You won’t be running Scion in your project, but some of the ideas transfer to tools you already have.
Partial clones and sparse checkouts so CI doesn’t download the whole history:
git clone --filter=blob:none https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set services/apiWorktrees for parallel work without copying the whole repository. It’s the same idea of not duplicating the repo, applied at human or agent scale. A worktree shares the history but has its own working directory and its own branch:
git worktree add ../monorepo-feature-x -b feature/xClaude Code also has native support for worktrees in parallel sessions, which it creates under .claude/worktrees/. Keep in mind that a worktree doesn’t include ignored files like .env, so you need to copy them over and reinstall dependencies in each one.
[EXPERIENCE: have you used worktrees or parallel agent sessions on a project? What problems did you run into?]
My take
I think Anthropic’s post is valuable for its technical honesty and for what it leaves implicit. Three things stand out to me.
First: the real bottleneck is copying. Git isn’t slow at history. It’s slow when millions of processes ask for full copies of something they only need in part. Scion solves that by moving the logic to the server. It’s an architecture lesson that applies to almost any distributed system.
Second: agents change the assumptions. Git assumes humans who work offline, review changes slowly, and make a few commits a day. An agent makes hundreds of changes, needs to read the repository through an API, and has no reason to keep a local copy. If your workflow starts to look like that, Git’s model starts getting in the way.
Third: I worry about the habit of copying solutions built for someone else’s scale. Scion is designed for 25 million checkouts a day. Almost no team has that problem. The sensible move is to take the principles (don’t copy, don’t maintain mirrors, cache by content) and apply the standard tools: partial clones, sparse checkouts, and worktrees. For 99% of teams, that’s enough.
Anthropic says it wants to share its thinking so the Git ecosystem can adopt parts of the approach: server-side RPCs on platforms like GitHub or GitLab, a renegotiated fetch protocol, and sparse and shallow features that compose better. If that reaches Git itself, it will matter more than Scion.
Sources and further reading
- Redesigning source control at Anthropic, Anthropic’s original post, October 13, 2026
- Anthropic reinvents source control as Claude floods the world with code, coverage on Slashdot
- Anthropic unveils Scion, the source control system that replaced Git, summary by Pasquale Pillitteri
- Mark Kretschmann on X about the growth in merges
- Pro Git: Git Objects and Pro Git: Packfiles
- git worktree documentation
- git clone documentation, including
--filter - git sparse-checkout documentation
- Sapling SCM, Meta’s source control system
- Run parallel sessions with worktrees, Claude Code Docs
- Google Cloud Platform’s scion project, so it isn’t confused with Anthropic’s Scion
