When agents broke git: inside Anthropic's Scion migration

Last Updated: 15 October 2026

Key takeaways

The tweet that got 5.8 million views in a day was not about a model release. On 13 October 2026, Anthropic's engineering account posted a number most engineering teams would find unrealistic: the company was merging more than 30,000 code changes per day, up from around 2,500 in May. According to the tweet and the accompanying engineering post, that 12x jump is what pushed Anthropic off git entirely.

The post, "Redesigning source control at Anthropic" by Nick G. and the source control team, is a rare look at what happens to basic engineering infrastructure when most of the code is written by agents. The short version: agents broke git. Then agents helped build its replacement in five months, and a seven-person team migrated one of the world's largest monorepos onto it without stopping development.

Here is what actually happened, which numbers hold up, which deserve a grain of salt, and what it means for teams running agent swarms today, including ours.

Why agents broke git at Anthropic

Anthropic's workload sits far outside anything git was designed for. According to the engineering post, the main branch of their monorepo alone holds almost 100 GB of history, a compressed working copy is over 25 GB, and the company performs on the order of 25 million code checkouts per day for CI before counting developer environments, agent sandboxes and research jobs. Fetched naively, that would be over 600 petabytes of git traffic per day.

Git itself is not broken. Its distributed design, every clone is a complete, self-contained repository that works offline, is exactly why it became the standard, and Anthropic says so plainly. The problem is what happens when the clients are no longer humans who sync a few times a day but agent jobs that are online by definition and never stop committing. As Anthropic put it, the properties that make git excellent for distributed, offline work actively undermined their ability to scale as the repo grew.

The stopgaps came first. Shallow clones, sparse checkouts, promisor remotes, internal mirrors, snapshot seeds in blob storage: Anthropic used them all. At peak they operated several hundred git mirrors, and the mirrors failed in the end because the repo outgrew the mirrors' disks and memory. Seeds fell further behind the tip of main between refreshes, and keeping history-dependent operations like diff and blame working on partial clones took more and more care.

So Anthropic asked a different question: if the clients are agents and jobs that are always online, what would source control look like designed from scratch for that? Their answer is Scion.

How Scion works: the git mental model, inverted

Scion inverts git's core assumption. In git, you commit locally and push to share. In Scion, every commit, rebase and merge happens on the server, so there is nothing to push. The client is deliberately thin: it maintains a bounded cache of objects, lays out working copy files, watches the filesystem, and computes almost nothing itself. Blame, history and merge-base questions go to the server, over an API the internal tools also use, so many jobs never maintain any local repository at all.

The unit of work is the changeset, an entry in a write-ahead log. Where a git commit points at a tree, a changeset stores the list of files that changed relative to its first parent, plus content-addressed pointers into immutable, compressed blob storage. Metadata lives in Spanner, file contents in Cloud Storage. There are no packfiles, no locking, no cross-server coordination, and refs play no part in the write path; moving one is a compare-and-swap on a single Spanner row. Because the cost of a commit scales with the size of the change rather than the size of the repo, the server can absorb a merge rate no git forge could contemplate. Anthropic's example changeset in their own diagram has a telling detail: the author is Claude <[email protected]>.

On the read side, the checkout path is a three-tier cache. Every node runs a scion-daemon that starts from a periodic snapshot and serves the whole machine over a socket. It talks to a regional scion-cache that streams objects straight from memory, and only on a miss does the cache ask the authoritative scion-server fleet, which reads Spanner or blob storage. All three tiers answer identical RPCs, so the client never needs to know the topology, and every tier holds a cache hit rate above 99%. Nothing anywhere holds a fully materialized copy of the repository, and because nothing is a packfile, no repository maintenance exists at all.

One consequence worth flagging for architecture watchers: blame and path history are not stored, they are derived. Every piece of derived data is defined recursively over the changeset graph and computed server-side from a parent's value, lazily when possible. Anthropic has added new derived types (copy detection, path search) repeatedly without changing clients. It is a clean example of why encyclopedia-scale repos want a queryable source control service, not just a faster filesystem.

What the numbers actually say

Anthropic's results claims have specific numbers attached, and most are benchmark-style measurements of their own systems, which is worth remembering. The table below collects the ones from the post and its charts.

Three framings matter when reading these. First, the "600 PB a day" headline is a counterfactual, 25 million checkouts times 25 GB, a number used to explain why caching layers exist, not a claim anyone shipped that traffic. Second, the time savings for agents compound: at Anthropic's scale, 30 minutes of source control overhead per change request across thousands of agent-hours is a real fleet cost, which is why they quote freed agent hours per day. Third, every one of these numbers is Anthropic measuring its own system, published without an independent yardstick, which is normal for an engineering blog and still worth noting before quoting the multipliers as settled fact.

Claude built it, and Claude broke it first

The most quoted passage of the post is also the most important one for anyone watching agent-driven development. Scion started being built around the time Claude Mythos Preview and Claude Tag became available internally. Earlier in the year, the team had hand-written a git-to-Scion ingestion pipeline prototype and thought it was good, until they gave it to an early internal Mythos Preview snapshot and asked for a rewrite with no further instructions. It produced a version with 20x less memory use and 4x more speed while preserving all the implicit invariants around ingestion ordering and data structures. The team then ran that ingestion in a loop for months to keep git and Scion in sync during the migration, so the speedup had real operational value.

The changes chart for the Scion and Antique directories shows the same shape as the monorepo at large: 12,257 merged changes to those two codebases since January, climbing steeply through the year. According to the post, every engineer who worked on the system would now rate Claude as better at writing code than they are, and the humans' role consolidated around system-level design and tradeoffs, plus one blunt verb: telling Claude no. Agents, they report, will violate core constraints to satisfy a familiar pattern, like reading the commit log linearly to find when a change merged instead of asking the review tool, and adversarial review can push the system into over-engineering against hypothetical concerns.

Quality assurance got rebuilt around the same density of machine attention. The team built hermetic simulations of every non-trivial infrastructure interaction they had ever encountered, plus fuzzing and rate limiting, on a timeline where that would normally be unthinkable. Claude also surfaced algorithmic optimizations, one to ancestry queries that their own indexes had missed, that the post says would have taken an expert days or weeks, "and then did it all again the next day."

And operationally, they staffed monitoring with Claude too: a "superfan" agent per component, a scion-daemon superfan, a scion-cache superfan, an Antique merge-queue superfan, each tasked in a Slack channel with obsessively watching telemetry and logs for anything strange, on the theory that a model that never tires of looking at graphs catches subtle issues that threshold alerts miss.

What the skeptics say, and where they have a point

The Hacker News thread on the post reached 817 points, and the objections there are worth taking seriously because Anthropic's numbers cannot be independently checked from outside.

The sharpest metric critique is the oldest one in software: commit counts are no better than line counts as a measure of progress. Much of the 30,000 daily merges is plausibly research, eval and test scaffolding rather than product, and Anthropic does not claim otherwise; it is a self-reported volume number from the one company on earth with an uncapped internal token budget. The defense of the number is narrower but solid: the claim worth tracking is infrastructure throughput, how many changes a system of record can absorb per day, and that did need to rise 12x.

The architecture critique has more bite. Server-side everything, commit, rebase, merge, sounds like Subversion with extra steps, and it removes git's offline history model entirely. Several commenters argued a mandatory always-on API adds a dependency and an agent-coordination surface they do not want. Anthropic's answer in the thread is honest: offline commit buffering is possible, but the client would have to reimplement server capabilities like blame and merge-base ancestry, and since Claude, the heaviest user, is necessarily online, it was not worth building. That is a real tradeoff, not a universality claim, and teams adopting it should treat it as such.

The review question is the one most people actually care about: is anyone looking at this code? Anthropic's post says plainly that people still review every change request, but for intent rather than line by line, with directory-level permissions and semantic approval rules in Antique separating comment-only changes from sensitive logic. Whether intent-level review of agent-written code is adequate at 30,000 changes a day is not a question anyone outside Anthropic can currently answer, and the honest position is Anthropic's own: they will know by outcomes.

Finally, the closed-source objection. Scion is not available, and Anthropic argues offering it broadly would not help anyone because it requires migrating the entire development lifecycle with bespoke review, search and CI components. That is a defensible reason and still a disappointment for teams who wanted to kick the tires. What they offer instead is a direction for the ecosystem: keep the git client, rebuild the servers. Comprehensive server-side RPCs, possibly standardized across forges; a negotiation protocol redesigned around what the client wants rather than what it has; sparse and shallow features that compose. Anthropic credits Google's Piper and Meta's Sapling as prior art and closes by inviting GitHub, GitLab and the open source community to treat agent-scale source control as a shared problem. There is already a small commercial ecosystem forming around that thesis, including jj-based offerings, which suggests the "post-git server" space Anthropic is pointing at is real.

What this means for teams running agents today

Nobody reading this has a 100 GB monorepo history or 25 million daily checkouts. Anthropic says this directly: they do not expect most organizations to face these problems in the near term, and Scion is not a general replacement for git. But the shape of the bottleneck is already familiar to anyone running a real agent fleet, and it shows up at much smaller scale.

The pressure points arrive in an order. First, agents assist humans and git is fine. Next, agents write significant code and the git chores, stale worktrees, push races, rebases stacking up, become the per-agent limit long before the model's capability is. Eventually, if the swarm keeps growing, the system of record itself becomes the constraint, which is where Anthropic now is. Most teams today are in the middle stage, which means the highest-return investments are ahead of the VCS: API access to repository questions so agents do not need full checkouts, intent-level review gates, post-merge test investment, and per-component monitoring agents.

We see the early version of this ourselves. In our dual DGX Spark setup running DeepSeek V4 Flash at about 60 tokens per second, the model is rarely the bottleneck. The git chores around it are: keeping worktrees warm, untangling push races, rebasing one agent's work under another's. Nothing at Anthropic's scale, but the same direction, and it is why the Scion post reads less like a curiosity and more like a preview.

The five-month migration is itself part of the argument. Seven people replaced the most load-bearing tool in the engineering org while the org's output grew 12x underneath them. A migration like that was historically a multi-year program. Whatever you think of the destination, the speed is the signal that agent-scale development changes not just what gets built but what can be rebuilt.

Git is not dead, and nothing here says it is. The reasonable read is narrower: when your clients are machines that never sleep, some design bets that made sense for humans stop making sense, and the first infrastructure you will feel it in is the one closest to the code.