Anthropic replaced Git when Claude pushed it past 30,000 code changes a day, and says the same wall is six to 12 months out
Anthropic's agents pushed its merge rate from about 2,500 code changes a day to more than 30,000, so the company replaced Git with an in-house system and published the design; here is what it measured, what it assumed, and which part of your own toolchain meets the same wall first.
Anthropic merged about 2,500 code changes a day in May. By September the daily figure passed 30,000, and on 9 September it reached 30,401. 1
Writing code had stopped being the constraint. The constraint moved to the machinery around the code — source control, builds and continuous integration — all of it designed for the pace of human committers. 1
So Anthropic replaced Git. Its monorepo, the single repository holding all of the company's code, now runs on an in-house system called Scion, built and migrated by seven engineers in five months. 1
The company expects other teams to hit the same wall within six to 12 months, and published the design so they can see it coming. 1
Hyperautomation Labs' walkthrough goes through those numbers and the design shift behind them.
Loading content card…
Where the bottleneck moved
A git repository is decentralized by design. Every copy is complete, any client can serve the repository, and a developer can commit with no network at all. 1
Anthropic's repository outgrew that design in every direction at once. The history of the main branch alone is almost 100 GB, and a compressed working copy of it is over 25 GB. 1
Continuous integration — the pipeline that builds and tests every change — performs around 25 million code checkouts a day there, before developer machines, agent sandboxes and research jobs are counted. Fetched naively, that is more than 600 petabytes of git traffic a day. 1
Every standard workaround was already in use: shallow clones, sparse checkouts, promisor remotes, repository snapshots kept in blob storage, and several hundred internal git mirrors at peak. As the merge rate rose, the mirrors stopped scaling and the snapshots drifted further from the tip of main between refreshes. 1
What Scion does differently
Six design commitments separate Scion from git, and they all follow from one observation: nearly every client here is an agent or a job, and those are online by definition. 1
- Clients are always online. The server is always reachable and clients fetch data when they need it.
- Client and server divide the work. The server answers history and blame questions, creates commits, and performs merges and rebases; the client keeps a bounded local cache and writes files to disk.
- Every query is an API. A job that needs the diff between two commits, or the last person to touch a line, asks the server instead of holding a copy of the repository.
- No machine holds the whole repository. Data is distributed with no packfiles to maintain, and no repository maintenance runs at all.
- Commits are cheap and lock-free. A commit, rebase or merge happens on the server, and its cost scales with the size of the change rather than the size of the repository.
- The working copy is optional. Sparse checkouts pull only the directories a job asks for; virtualized checkouts materialize files as they are read.
Each change lands as a "changeset" in a write-ahead log — a journal written before the change is applied, so the server can accept changes without locking — holding the files that changed relative to its first parent plus pointers to the compressed file contents in blob storage. 1
Questions a changeset cannot answer alone — who last edited a line, which commits touched a file — are answered by derived data structures computed recursively from the changesets, either eagerly or on demand. Because the client never sees their internals, Anthropic can add a new index without shipping a new client. 1
What it bought, and what it cost
The infrastructure footprint is 200 times smaller than the git mirroring it replaced, in CPU and memory. Code checkouts take seconds instead of minutes, and continuous integration alone recovered 25% of its CPU capacity. 1
Seven people built Scion, a review surface called Antique, code search, a permissions system for source control and half a dozen related tools, and finished the migration — while the volume of code merged each day rose tenfold. 1
Claude did much of that work. Told to rewrite an early prototype of the git-to-Scion ingestion pipeline, with no further instruction, a model returned a version using 20 times less memory and running four times faster. 1
Review changed shape rather than disappearing. Every change still gets a human reader, but that reader now judges the intent of a change instead of reading every line, and permissions can be set per directory so sensitive code keeps a tighter gate inside one large repository. 1
Operations changed shape too. Each component has a dedicated Claude watching its telemetry in a Slack channel — a daemon watcher, a cache watcher, a merge queue watcher — and the team reports that these catch issues its conventional alerts miss. 1
One long-standing practice was dropped on purpose. A global lock on the merge queue — the line of changes waiting to be tested against the latest code before they land — could not be made to work at this rate, so Anthropic tests after merge and before deploy instead. Concurrent changes are allowed to conflict, on the bet that an agent cleans up faster than a human notices. 1
The budget behind that timeline is the part other teams cannot copy. Anthropic says its internal ability to spend tokens far exceeds what any other business would want to spend, and that it spends them partly to test its own models. 1
The same curve, one layer up
This is one company's measurement, and the platform underneath everyone else is bending the same way. GitHub's chief technology officer wrote in April that agentic development workflows accelerated sharply from the second half of December 2025. 2
By February, GitHub was designing for 30 times its then-current scale, having started a 10x capacity plan in October 2025. Its published totals run to 90 million pull requests merged a month, 1.4 billion commits, and 20 million new repositories a month. 2
The same post records what happens when the queue machinery fails at that load: a merge queue regression on 23 April produced incorrect merge commits in 658 repositories and affected 2,092 pull requests before it was contained. 2
Merge queue design is where the change shows up first. Mitchell Hashimoto, advising a company living this problem, has said the human-cadence queue holds up to a point and buckles at a hundred times the churn, and that what breaks is throughput rather than review quality. 3
The queue vendor Mergify describes three answers: test several changes in parallel lanes instead of one at a time, batch passing changes into a single validation run that bisects on failure, and scope queues by directory so work in unrelated parts of a monorepo stops waiting in one line. 3
Git identifies a piece of work by the hash of its contents, so a rebase gives the same change a new identity — a mismatch that costs more once hundreds of changes are in flight. 3
What concurrency costs in the open is already measured. A study of 33,596 agent-authored pull requests across 2,807 repositories found that 40.2% of those repositories had two agent pull requests in flight at the same moment, and that those overlapping pairs account for 79.4% of all agent pull requests. 4
Replaying 747 of those merges, the authors measured a text conflict in 41.7% of cross-agent pairs against 19.8% of same-agent pairs. Source code made up 84.4% of the conflicted files, and close to 42% of the conflicts were structural, such as a file deleted on one side and modified on the other. 4
The announcement post on X drew 5.5 million views and 920 replies in its first day, which is where most of this argument is actually happening. 5
Where the evidence stops
Merge counts measure landed changes. Whether the code is right, whether it ships, and what it cost are separate quantities that the series cannot answer on its own.
Open-source projects supply the published check on that gap. A study of 1,130 agent-written and 1,130 human-written performance pull requests found agent submissions merged 54.4% of the time against 73.3% for humans, and agent submissions leaning more on static reasoning and less on benchmarks, 46.1% against 57.2%. 6
The speed figures are Anthropic's own, measured inside one company, and no outside replication exists yet. The Register's account of the post adds a confirmation the blog implies without stating: there will be no open-source release, because a system built for a repository this size would not suit anyone else. 7
The post's case also rests on a forecast: that demand for merging code is practically infinite. That claim is doing a large share of the work in a document otherwise built from measurements. 1
Commenters on the Hacker News thread objected that the volume is partly self-inflicted, with agents using git history as a coordination channel. An Anthropic engineer answered in the same thread that agents are not allowed to use source control that way, and that real growth in written software forced the rebuild. 8
A developer-tools founder read the shift this way: with git, a company keeps shipping while its forge is down, whereas with Scion the commit itself needs the server. That trade only makes sense once code changes faster than humans can supervise it, which is the premise the post is built on. 9
Where your team sits
- You own a monorepo. Pull two numbers before your next planning round: merged changes per day over the last six months, and CI checkouts per day. Anthropic's first number went from 2,500 to 30,000 in four months. 1
- You own the CI budget. At Anthropic's checkout volume, a naive fetch is 600 petabytes a day. The wins the post reports came from asking the server questions instead of checking the repository out. 1
- You run code review. Ask whether your tooling can tell a comment-only change from a logic change, and whether permissions can be set per directory. Those two capabilities are what let seven people supervise an agent-written codebase. 1
- You depend on a forge. GitHub said in April that a new API design for efficiency and scale was coming, alongside merge queue work aimed at repositories with thousands of pull requests a day. Ask for the date. 2
- You pay for tokens. Anthropic's timeline rests on an internal token budget it describes as unusual. Track cost per landed change next to merge rate, or the two numbers will diverge without anyone noticing. 1
- You own the product on top of all this. A team that lands a change in seconds runs at a different release cadence from a team waiting on a queue. Know which one your roadmap assumes. 3
A watching brief
- Whether GitHub ships the API it promised. Its April post promised a follow-up on a new API design for large repositories, and it has been investing in merge queues for repositories with thousands of pull requests a day. A shipped API is the cheapest version of this rebuild for everyone else. 2
- Whether a second company reports the same inflection. Anthropic's six-to-12-month estimate covers teams with far smaller repositories and token budgets. The next organisation to publish its merge curve tests that estimate. 1
- Whether the speed figures survive an outside look. The 200x footprint reduction, the seconds-not-minutes checkouts, the 25% CI capacity win and the 20x ingestion rewrite are all self-reported and unreproduced. 7
- Whether git itself absorbs any of it. The post proposes that a git server need not work the way a git client does, with richer server-side calls and sparser transfers. Those changes would reach every team that never builds a Scion. 1
- Whether merge rate tracks release quality. The open-source evidence shows agent pull requests merging less often than human ones. Watch for the same measurement inside companies with their own merge series. 6
The decisions, with the clock on them
| Decision | What the sources provide | The constraint that decides it | Act when |
|---|---|---|---|
| Whether to measure your merge rate and checkout volume now | A 12-fold rise in four months at Anthropic, and platform-wide acceleration at GitHub from late 2025 12 | Nobody can forecast a curve they have never plotted | Before your next capacity plan |
| Whether your CI keeps checking out the repository | 25 million checkouts a day and 600 petabytes of naive fetch traffic; server-side queries and sparse checkouts as the alternative 1 | Whether your forge exposes the queries, or only a clone | At the next CI cost review |
| Whether review gates on lines or on intent | Engineers reviewing intent instead of every line, plus per-directory permissions inside one repository 1 | Whether your review tooling can express constraints on approvals | Before the next agent gets write access |
| Whether the merge queue stays a single line | A global lock abandoned at agent rates; parallel lanes, batching and directory-scoped queues as the alternatives 3 | Queue wait time against your deployment cadence | When queue wait passes change latency |
| Whether to budget for tokens per landed change | An internal token budget Anthropic calls unusual for any other business 1 | Your own cost per merged change, which only you can measure | At the next tooling budget |
| Whether to build your own source control | Scion will not be released, and Anthropic says it would not suit most organisations 7 | Whether your forge answers the monorepo questions above | After the vendor answers, not before |
The merge trend, the architecture, the 200x footprint reduction, the checkout speeds, the 25% CI capacity win, the seven-engineer timeline and the six-to-12-month estimate all come from Anthropic's engineering write-up of 13 October 2026, which describes work inside one company and reports its own measurements. The Register adds the statement that Scion will not be released, and the comparison with Google's Piper, Meta's Sapling and Microsoft's VFS for Git. GitHub's figures come from its CTO's April 2026 post about its own availability work, and the queue designs described are a vendor's argument and an engineer's observation. The merge conflict and merge rate figures come from two academic studies of public repositories, which measure open-source behaviour rather than what happens inside a company. The claim that the merge volume is self-inflicted was made by commenters on Hacker News, and the answer to it is a single engineer's post in the same thread.
References
- 1Redesigning source control at Anthropic
anthropic.com
- 2An update on GitHub availability
github.blog
- 3
- 4
- 5
- 6
- 7
- 8Redesigning source control at Anthropic (Hacker News discussion)
news.ycombinator.com
- 9
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.