DEV Community

jamilxt
jamilxt

Posted on

Anthropic Rewrote Bun in Rust With 64 Claude Agents for $165K. The Real Bill Is Higher

In December 2025, Anthropic bought Bun, the JavaScript runtime with over 22 million monthly downloads, and then ported its entire codebase from Zig to Rust. The port was done in 11 days by 64 parallel Claude agents at a reported cost of $165,000 in tokens. Those numbers have traveled far, usually attached to a prediction: frontier AI providers will one day charge real per-token rates for software development, and developers who can still read code will become rare specialists.

The core facts check out. The conclusions deserve a harder look, because the $165K figure is narrower than it sounds, the process was not hands-off, and the model that did the work is not one you can buy. Here is what the sources actually say.

What actually happened

The primary source is Jarred Sumner's own engineering write-up, Rewriting Bun in Rust, published July 8, 2026 on the Bun blog. The verified facts from it:

  • Anthropic acquired Bun in December 2025. Sumner and the Bun team now work at Anthropic.
  • Bun was 535,496 lines of Zig across 1,448 source files. The runtime is now ported to Rust and ships as Bun v1.4, which passed 100% of Bun's existing test suite across platforms.
  • Sumner ran about 50 "dynamic workflows" in Claude Code continuously for 11 days (May 3 to 14, 2026). At peak, 64 Claude agents ran in parallel, organized as 4 workflow shards of 16 agents each, producing 6,502 commits. Peak output was roughly 1,300 lines of code per minute.
  • Pre-merge, the port consumed 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. Sumner prices that at "around $165,000" at API pricing.

The trigger was not fashion. Bun's bug tracker in the Zig era was dominated by use-after-free, double-free, and missed frees on error paths, the exact bug classes Rust's borrow checker turns into compile errors. There was also an upstream constraint: as Dennis Morello reports, Zig's core team has a no-AI-contributions policy, which became untenable once Anthropic owned the project and the team's engineering shifted to agent-driven.

Three corrections the headlines get wrong

1. The $165K is a pre-merge estimate, not the bill

The number covers tokens consumed up to the merge of the port branch. It excludes the compute that came after. Tom Lockwood's independent analysis of the repository found that six weeks after the merge there was still no stable release tag, the count of open pull requests from "robobun" (the Claude Code identity) had grown from 1,277 to 2,475, Anthropic employees were still writing fixes, and the Buildkite CI cluster had been running continuously. Lockwood estimates that if the effort is still consuming on the order of $10K a day, total spend is approaching $800K.

None of that contradicts Sumner, who only ever claimed the token figure "at API pricing" pre-merge. But if you are quoting this story as "a runtime rewritten for $165K," you are quoting the floor, not the total.

2. "They didn't really pay it" is true in two ways, not one

Yes, Anthropic ran the work on its own models, so the $165K is an internal accounting figure rather than cash leaving the company. The bigger detail most posts miss: Sumner states he used a pre-release version of Claude Fable 5 for much of the rewrite. That model was not available to any customer at any price during the port. So the $165K figure is also not a menu price. It is what the equivalent token volume would have cost on the public API, on a frontier model, under an expert's supervision. No one outside Anthropic could have run this exact project at this exact cost in May 2026.

3. It was not 11 hands-off days

The workflow design is the most instructive part of the write-up, and it is the opposite of "prompt and pray":

  • Before any code was written, Sumner spent about 3 hours with Claude producing a PORTING.md guide mapping every Zig pattern to its Rust equivalent, plus a LIFETIMES.tsv analyzing the memory lifetime of every struct field in the codebase.
  • A trial run ported 3 files first, not 1,448.
  • Every implementation was checked by 2 adversarial reviewer agents in separate context windows, given only the diff and told to assume the code was wrong, followed by a fixer agent. Sumner documents real catches, including a use-after-free and double-free around asynchronous libuv handle closes that compiled clean and looked plausible.
  • Early parallel runs collapsed because agents ran git stash and git reset --hard on top of each other. The fix was process-level: constrain each agent to file-specific commits, shard into worktrees.
  • Sumner monitored the workflows continuously for the full 11 days, reading outputs and correcting the loops.

This was a mechanical, line-for-line port with behavior frozen against a language-independent test suite, supervised full-time by the person who knows the codebase best. That is close to the best case that exists for agentic coding. Greenfield enterprise systems with shifting business rules do not have a reference implementation to port from.

What the $165K actually proves about cost

Even corrected, the numbers tell a clear story. Sumner's own estimate for the manual alternative is a small team of full-context engineers for about a year, a year in which bugfixes and features would have been frozen. One expert plus agents compressed that to 11 days of generation plus an ongoing stabilization tail. As a pure engineering-economics result, agent-driven development won this round, inside a company that makes the agents.

Two caveats keep that conclusion honest. First, token spend does not scale down with project size the way salaries do. A $165K token bill for a well-specified port implies real per-feature token budgets for daily iterative work, and pricing pressure moves that bill in both directions. Second, the post-merge tail is not optional: tests passing is not the same as a shipped, stable release, and the Bun repo is still working through that tail in public.

The quality debt the headlines skip

Morello's write-up on Bun 1.4 canary adds the number that will follow this migration for years: about 4% of the new Rust code sits in unsafe blocks, roughly 13,000 unsafe keywords. A comparable hand-written Rust project carries around 73. Most are single lines wrapping C or C++ interop, and the count is expected to fall as the port is refactored toward idiomatic Rust. But the ratio is the point: AI translation achieved functional correctness at speed and left a structural audit backlog behind it. Passing tests was the easy part. Verifying memory-safety guarantees at scale is the expensive part, and it is being done by humans, after the merge, now.

Is this repeatable outside Anthropic?

The Pragmatic Engineer's coverage of the rewrite asked the question that decides how much this story applies to anyone else: how repeatable is the process? Strip away the specifics and the Bun port depended on four conditions that most teams cannot check off.

  • A frozen reference implementation. Every Rust file had a Zig original to be measured against, plus a language-independent test suite of about a million assertions that predates the port. Most software work is not a translation of something that already exists.
  • A frontier pre-release model. Claude Fable 5 was not purchasable in May 2026. Teams running today's work on public API models are working a generation behind the one that produced this result.
  • One irreplaceable expert. Sumner wrote the original Bun transpiler in Zig by hand over a year, pre-LLM. The person who ran the loops was the person with the deepest possible context on the code being ported, and he watched the output full-time for 11 days.
  • Adversarial review as infrastructure. Two reviewer agents per implementer, separate context windows, diffs only, plus the human reading the loop. The throughput of 64 agents is meaningless without the review pipeline behind them.

That is why the honest conclusion is narrower than the loud one. This was a best-case agentic project: mechanical, well-specified, expertly supervised, and cheap by comparison with the alternative. It proves agent-driven development can win the economics on favorable work. It does not tell you what agentic work costs on unfavorable work, which is what most enterprise development is.

What this means for developers

A prediction follows naturally from this story: frontier providers will eventually charge unsubsidized per-token rates for serious development. It is directionally reasonable and unverifiable. Two parts of it are worth sharpening:

  • The assembly analogy cuts both ways. The claim is that developers who can read code will become as rare as assembly programmers today. Assembly specialists are rare, and they are not poorly paid. Compiler, firmware, and security engineers who work at the abstraction floor command a premium precisely because most developers cannot. If code reading becomes rare, it likely becomes more valuable, not less.
  • The gate is hardware, not just policy. The open-weights escape hatch is real. Kimi K3, GLM 5.2, and DeepSeek's open models have shown capable open-weight coding models running on hardware a studio can own. Whether that ecosystem stays competitive with frontier agents is a more open question in 2026 than any single rewrite can settle.

One counterweight deserves more attention: the rewrite also demonstrates how much review capacity matters. Sixty-four agents producing 1,300 lines a minute are only usable because two adversarial reviewers checked every implementation and one expert human read the loop the whole way down. If the next generation of developers cannot do that reading, they also cannot run this process. The skill this story predicts will disappear is the same skill its own evidence says was indispensable.

Sources

Top comments (0)