Git Wasn't Built for 30,000 Merges a Day. Anthropic Just Proved It.

Coding agents made code cheap. Anthropic's new source control system shows what breaks next, and which parts of its fix you can copy with plain git this week.

Every team that adopts coding agents eventually hits the same wall, and it isn't the model.

The agent writes the change in a few minutes. Then the change sits in a CI queue. Then a dozen jobs each clone the repository from scratch. Then a merge conflicts with three other merges that landed while the tests ran. Writing code got fast. Everything that handles code stayed the speed of a human team.

On October 13, Anthropic published the most extreme version of that story so far. In May 2026, the company merged about 2,500 code changes a day into its main repository. By September it was merging more than 30,000 a day, and in the engineering team's words, "source control became our biggest development bottleneck." So a seven-person team replaced git for that repository in five months (Anthropic Engineering).

You are almost certainly not merging 30,000 changes a day. The lesson still applies to you. When code gets cheap to write, the queue moves to whatever handles the code next, and the assumption that broke at Anthropic is baked into how most teams use git right now. Most of the fix is already sitting in git, unused.

What actually broke

Start with the numbers, because they explain the decision. The post says the history of Anthropic's main branch is "almost 100 GB," a compressed working copy is over 25 GB, and CI performs "on the order of 25 million code checkouts per day." Fetched the normal way, the authors estimate, that would be "over 600 PB of git traffic per day" (Anthropic Engineering).

Six hundred petabytes. Per day. For checkouts.

Before Scion, Anthropic was coping by running several hundred internal git mirrors, copies of the repository spread around so CI jobs didn't all hammer one server. That worked until the merge rate kept climbing and the mirrors themselves became the thing to babysit.

The post is blunt about the shift underneath: "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI." Claude writing code faster is what created the problem, and the post admits that too.

One thing the post does not do is split those 30,000 daily merges into agent-written and human-written changes. Keep that in mind. The growth is real; how much of it is agents is Anthropic's to say, and it hasn't.

Why git hits a wall here

Git made a design choice in 2005 that was smart for its time. The Anthropic post puts it in one line: "Git assumes that clients work offline and need a complete copy of the repository."

Think of a library where every reader has to carry the entire building home before they can read one page. That's a normal git clone. You get every file, every version of every file, and the full history, so you can work on a plane with no internet. For a human developer who clones once and works for months, that trade is great.

Now picture 25 million readers a day, most of whom need three pages and will throw the building away in ten minutes. That's CI in an agent-heavy shop. Each job wants a fresh, clean copy, runs its tests, and gets deleted. Carrying the whole library home for that is absurd.

Git's default also makes the server do the hard work of figuring out what you already have and packing up what you don't (a negotiation that ends in a big bundle called a packfile). With a 100 GB history and more than a thousand new merges an hour, that negotiation gets expensive fast.

What Scion does differently

Scion flips the library model. The client is assumed to be online, the server keeps the full building, and you ask for the pages you need. The post lists the design principles plainly: clients are always online, the server does the heavy lifting, every component scales out horizontally, commits are cheap and lock-free, and "working copies are optional and sparse" (Anthropic Engineering).

Three ideas carry most of the weight, and each one has a plain-language version.

Commits happen on the server. In git, you build a commit on your machine and push it. In Scion, the commit is created server-side and recorded as a changeset, a list of which files changed compared to the previous version, with pointers to where the file contents are stored. Nothing needs to be pushed, which removes a whole round trip for an agent that just wants to land a change.

You fetch by asking, not by negotiating. A Scion client requests the exact files and folders it needs. No "here's what I have, what am I missing" exchange, and no giant packfile.

Caches sit in front of everything. A small program on each machine talks to a regional cache, which talks to the authoritative servers. The post says each cache tier keeps a hit rate above 99%, so most requests never reach the core.

The results, as Anthropic reports them: the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI and research jobs check out code "in seconds rather than minutes." The post adds that CI alone gained about 25% in CPU capacity.

They also gave up something. Anthropic says it could not keep "the industry standard of a global repository lock," the merge queue that lets exactly one change land at a time after its tests pass. At 30,000 merges a day, waiting in single file stops working. They moved more checking to "post-merge and pre-deploy automated testing" instead. That is a real trade: a broken change can now land on main and get caught after, not before.

The insight: the queue moved

Here's the idea worth keeping. When code gets cheap to write, the first thing to break is whatever assumed a human pace on either side of the writing.

For years, nobody questioned a five-minute clone in CI, because a human opened maybe four pull requests a day. Five minutes times four is nothing. Give that same human three agents that each open twenty pull requests a day, with ten CI jobs per pull request, and those five-minute clones become most of your compute bill and most of your wait.

Anthropic hit this at a scale few teams will. The shape of the problem shows up much earlier, though, as slow pipelines, flaky merges and a CI bill that grows faster than your team.

Put this into practice

Scion is an in-house system, and the post doesn't announce a public release. The authors say it is "by no means a suitable replacement for git for general use." But their own advice to the rest of the world is telling: "A git server doesn't have to work the same way as a git client does," and "the various sparse and shallow features in git can be made to compose well."

Those features exist today. Here is the lowest-friction way to borrow the core of Scion's idea, smallest change first.

1. Measure your checkout time. Open your CI logs and find how long the checkout step takes on your biggest repository. If it's under ten seconds, stop here; your bottleneck is somewhere else. If it's a minute or more, keep going.

2. Use a shallow clone in throwaway CI jobs. A shallow clone downloads only the latest commit, not the history.

git clone --depth=1 <repo-url>

If you use GitHub Actions, you probably already have this: the official actions/checkout step defaults to fetch-depth: 1 (actions/checkout README). Check that nobody set it to 0 (full history) without a reason. GitHub's own guidance is to use shallow clones only for builds that delete the repository right after, and never for day-to-day development (GitHub Blog, Derrick Stolee).

3. Use a blobless clone for developers and long-lived build machines. A blobless clone downloads all the history and folder structure plus the files your checkout needs, and skips every other version of every file until you ask for it. It's git's closest thing to Scion's "ask for the pages you need."

git clone --filter=blob:none <repo-url>

Git calls this partial clone, and your git host has to support it (GitHub does, per the GitHub Blog guide above). When a command needs a file it doesn't have, git fetches it from the server on the spot, and checkout batches those fetches together (git partial-clone docs). Commands that read old file contents, like git log -p or git blame, can be slower the first time, because they fetch what you skipped.

4. Check out only the folders you work in. In a monorepo, an agent fixing the billing service doesn't need the mobile app on disk. Sparse checkout limits the working copy to the folders you name.

git sparse-checkout set services/billing libs/shared

Cone mode, the default, means you name whole folders rather than file patterns, which keeps it fast (git sparse-checkout docs). In GitHub Actions, actions/checkout takes a sparse-checkout input for the same thing.

5. Or let Scalar set it up for you. Scalar ships with git and configures a large repository in one command: it clones only commits and folder structure by default, turns on sparse checkout with just the top-level files present, and schedules background maintenance (git scalar docs).

scalar clone <repo-url>

Your code lands in a src folder inside the directory Scalar creates. Expand what's checked out with git sparse-checkout set as you need more.

6. Re-measure. Compare the checkout step before and after. If it barely moved, your time is going to tests or builds, and that's where to look next.

Honest limitations

Every Scion number is Anthropic measuring Anthropic. The 200x, the seconds-not-minutes, the 99% cache hit rate: none of it has an outside benchmark, and the post doesn't claim one. It's a credible engineering write-up, not an audited result.

The scale gap matters. The authors say this approach only makes sense for enormous monorepos, and that Anthropic's internal token spend is unusually high. If your repository is 2 GB, a custom version control system is a terrible idea. Even sparse checkout may not be worth the confusion for a small repo.

Git's tools have sharp edges of their own. The sparse-checkout docs say in capital letters that the command is experimental and its behavior "will likely change in the future" (git sparse-checkout docs). Partial clone requires you to be online with the server reachable whenever git needs a missing file, and fetching objects one at a time can be slow (git partial-clone docs). Plain git grep searches only the files in your sparse working copy, so it can miss paths outside it unless you search the index with git grep --cached. Shallow clones break anything that needs history, like a release script that reads the last tag.

And the merge-queue trade is the one I'd think hardest about. Dropping a global lock in favor of post-merge testing means accepting that main can be briefly broken. Anthropic decided that was worth it at 30,000 merges a day. At 300, a merge queue is probably still the better deal.

Finally, the post is careful about AI review in a way worth copying. Anthropic uses adversarial AI review heavily (models reviewing changes and arguing against them), and the post says that review "can also be myopic," at one point pushing the team toward an overly defensive design. Humans still review every change, but they now focus on the intent of the change. More agents didn't remove the human from the loop. It changed what the human looks at.

Where this leaves you

You don't need Anthropic's merge rate to have Anthropic's problem. You need agents producing changes faster than your pipeline was designed to absorb them, and most teams using coding agents at all will get there.

So start with one number: how long does a fresh checkout take in your CI today? If the answer surprises you, the commands above are an afternoon's work to try. If it doesn't, find the next step in your pipeline that assumed a human was driving, and time that one instead.

Sources: Anthropic, "Redesigning source control at Anthropic" (October 13, 2026) · Git documentation: partial clone · Git documentation: git-sparse-checkout · Git documentation: scalar · GitHub Blog, "Get up to speed with partial clone and shallow clone" · actions/checkout README

Medium metadata

Title: Git Wasn't Built for 30,000 Merges a Day. Anthropic Just Proved It.

Alternates to test:

• Coding Agents Made Code Cheap. Your Git Setup Didn't Get the Memo.
• Anthropic Replaced Git. Here's the Part You Can Copy Today.
• Git Isn't Built for Agent-Scale Development Anymore

Subtitle options:

1. Coding agents made code cheap. Anthropic's new source control system shows what breaks next. (picked)
2. What a 12x jump in daily merges taught Anthropic, and the git settings any team can borrow.
3. The bottleneck moved from writing code to everything that handles it.

Description: Anthropic's merges grew from 2,500 to 30,000 a day and broke git. Here's why, and the git features that borrow its fix.

Tags (priority order):

1. Git: the core subject and the commands readers will search for.
2. AI Agents: the cause of the volume and the audience's main interest.
3. DevOps: CI checkout cost is the practical payoff.
4. Software Engineering: broad reach for the infrastructure argument.
5. Anthropic: timely, named source of the news.

Article type: A (spike) with a B insight: a real, dated engineering release plus a plain mental model (the queue moved).

Publish plan: Post at 7 to 8 AM ET, let Medium distribute for 2 to 6 hours, send to subscribers only if it is performing.