Anthropic ditches git at 30,000 merges a day, while a Codex daemon downloads 500GB a day: the week agent volume outran the plumbing

30,000 merges a day: git stopped holding up as plumbing

The "wait, it went that far?" moment of the week came from Anthropic's engineering blog. In the company's internal monorepo (a setup that puts all of a company's code into one giant repository), daily merges grew from about 2,500 in May 2026 to more than 30,000 in September. That is roughly 12x. And the post states outright that the main driver of this growth is code written by agents. Humans typing by hand would never produce a 12x jump 😅

And git stopped holding up. The numbers are brutal. The history is about 100GB, and even a compressed working copy exceeds 25GB. CI (the system that tests code automatically) performs about 25 million checkouts a day, and naive fetches alone would have worked out to more than 600PB of git traffic a day. PB is petabytes, and 1PB is a million GB. This is no longer in the realm of "a bit heavy."

So Anthropic dropped git and moved entirely to Scion, its own version control system, along with Antique, a code review interface. Seven people built it in five months. The design rests on three premises: clients are always online, heavy computation happens on the server side, and the system scales horizontally (add machines and it gets faster in proportion). As a result, the post says, CI checkouts went "from minutes to seconds," a two-order-of-magnitude speedup, each cache layer's hit rate exceeds 99%, and CPU and memory usage is 1/200 of the old git mirror infrastructure. Rewriting the ingestion pipeline (the process that accepts and records changes) cut memory to 1/20 and made it 4x faster, and CI as a whole gained 25% headroom in CPU capacity.

This is primary-source material from Anthropic's official blog, so we report it as stated, but no third party can verify it. Scion will not be released publicly. We will come back to that point.

Dropping the global lock and letting Claude fix the conflicts

The part that made Haru go "huh" was this. Normally, large teams use a mechanism called a merge queue. It lines changes up in a row and tests and lands them one at a time. The industry standard puts a global lock on the entire queue (a lock that stops everything else while one item is being processed) to guarantee ordering.

Scion could not reproduce this, the blog states plainly. "We couldn't reproduce the global lock on the industry-standard merge queue, so we invested in automated post-merge, pre-deploy testing instead." In other words, they stopped inspecting changes one by one before landing them, and switched to landing them, testing in bulk afterward, and fixing whatever broke. The waiting line itself is gone.

So what happens when changes conflict? The answer is a single sentence: "Concurrent changes can conflict, but Claude can fix them faster than a human would notice the conflict." Because the cleanup after a conflict is handed to AI, there is no need to lock and queue. The volume that agents created is absorbed by agents, a loop that is, frankly, a habit-forming way of thinking 💡

Anthropic also says itself that it has no plans to offer Scion to other companies. It is "not a general-purpose git replacement" and is "for giant monorepos with tens of thousands of engineers and agents." The stance is to share only the concepts. So "let's adopt Scion too" is not an option, and what readers can take away is the thinking alone.

Hacker News asks: "So what are the humans doing?" and "Can you even bisect?"

The Hacker News thread drew 514 points and 512 comments. For all the excitement, the questions were harsh.

Anthropic's nickg-anthropic added that "the performance improvements came from looping on the ingestion process for months" and that "we run multiple tiers of orchestrators (agents that direct other agents) and agents, and are exploring ways to reduce conflicts." "Exploring" ways to reduce conflicts could also be read as: not solved yet 🤔

But many of the top comments were skeptical. piker's quip, "so what are the humans at Anthropic actually doing?", ranked near the top. It is no joke; it hits a sore spot, because the blog never discloses the share of those 30,000 merges written by agents. It says "mostly agents" without a number.

jacquesm wrote that "there is no way they have control over what is being built at that speed," and locknitpicker argued that "30,000 a day is not progress, it's a sign of code churn and spaghetti." The most concrete point came from sscaryterry: "by the time a bug is found two weeks later, more than 4,096 commits have piled up and bisect is effectively impossible." Bisect is the standard technique for finding which commit introduced a bug by cutting the history in half repeatedly, but at 30,000 a day, two weeks is more than 400,000 commits, and no amount of halving narrows the candidates. Speed breaks root-cause analysis.

mike_hearn questioned the decision to build at all: "Google ran tens of thousands of engineers on Perforce. Why not just pay for a P4 license?" Many also called it a rehash of Google's Piper or Meta's Sapling.

Then there are the blog's weaknesses. There is zero mention of failures or regressions during the migration. Post-merge conflicts are dismissed with the single line "Claude fixes them," and the frequency of conflicts and the number that could not be fixed are unknown. Scion is closed, so no third party can verify it. Frankly, it does read like a success story and nothing else.

Same week, Codex CLI catches fire over a daemon that runs and updates itself uninvited

The volume problem was not Anthropic's alone. OpenAI's Codex CLI (a coding agent that runs in the terminal) hit the top of Hacker News for eating up users' disk and bandwidth. This is not a "pipes are too small" story but a "pipes swell on their own" story.

According to Issue #48195 on GitHub, from Codex CLI 0.157.0 onward, merely opening an interactive session launches a resident daemon (a program that keeps running in the background) with no TTY (not tied to a screen). It copies a roughly 374MB package under ~/.codex and auto-updates five minutes after launch and every hour thereafter. The issue was filed on 9/25, and asks that daemon_auto_start be made opt-in (on only for users who choose it). On 10/12 it reached Hacker News with 599 points and 292 comments.

The reported real-world damage runs as follows. icantevenhold reported "12GB of disk, 11 binaries of about 300MB each." judge2020 said "the auto-updater kept downloading 500GB a day." A separate Issue #52067 reports "9 generations of old versions, 2.8GB in 13 days, growing about 200MB a day." The issue's comment thread on 10/12 and 10/13 reportedly continued with "this is the exact signature of malware," "1.3GB of downloads I never asked for," and "I've filed to pull every Codex license at my company." Once it gets to license cancellations, it is no longer a performance story but a trust story 😬

OpenAI's charliermarsh replied, "I've never touched the update subsystem, but this looks like an oversight. We'll fix it." In a separate Issue #51201, OpenAI's etraut-openai acknowledged on 10/11 a bug in which the restart during auto-update silently cut off four in-progress turns and downgraded permissions from Full access, with a fix planned for 0.163.0 or 0.164.0.

The workarounds available now are reported as four steps.

• Run codex features disable daemon_auto_start to turn off auto-start
• Run daemon stop to halt the resident process
• Kill the pid-update-loop process
• Delete ~/.codex/packages/app-server-daemon

As of 10/14, #48195 remains open, and the only fix version offered is for the permission downgrade bug in #51201. There were defenders such as dingaling911, who wrote "browsers auto-update too. It's standard now," but they were a minority.

Haru's take: nobody has the right answer yet for plumbing in the age of volume

Set the two stories side by side and it gets interesting. Anthropic, pushed by volume, dropped git, gave up on "preserving order," and bet on "AI fixes what breaks." OpenAI increased volume on users' own machines without asking and got yelled at. Both rest on the premise that agents move faster than humans, and the plumbing and habits on the human side have not kept up.

Honestly, Anthropic's blog is fun to read with its flashy numbers, but the absence of "how many conflicts did Claude fix, and how many could it not" nags. Without that, you cannot tell whether "dropping the lock turned out fine" or "they are calling it fine." Whether the Hacker News skeptics are right is something nobody can check as long as Scion stays closed.

The Codex side is more immediate. If 500GB a day were being downloaded onto your PC, of course you would be angry. It is good that they said "we'll fix it," but as of this writing the issue is still open. If you use Codex CLI, the first step is to check your version and the size of ~/.codex 🛠️

The volume of code agents write will keep growing. Which is exactly why the side that has to absorb it, the unglamorous plumbing of version control, CI, and auto-updates, looks set to be next year's main battleground. More than the flashy model news, isn't this what connects directly to the pain on the ground?