64 Claudes Running in Parallel for 11 Days: The Agent Engineering Behind the Bun Rewrite

A Runtime Rewrite Without Any Human-Written Code

On July 8, Bun author Jarred Sumner finally published the postmortem blog post he had delayed for nearly a month. Writing the code took only six days; writing the blog post took almost 30. That detail alone says quite a lot.

Here’s what happened: from May 3 to May 14, 2026, over the course of 11 days, Bun completed a full rewrite from Zig to Rust and merged it into the main branch in mid-May. This is a complete runtime covering the JavaScript/TypeScript transpiler, bundler, package manager, test runner, module resolver, HTTP/WebSocket client, and Node.js API layer—originally consisting of 535,496 lines of Zig code, plus roughly 20% C++ and several embedded C/C++ libraries.

The rewritten Rust version is about 780,000 lines long, with 6,778 commits and over one million lines of code changes. Throughout the entire process, not a single engineer manually wrote a line of application code. The work was done by 64 Claude Fable 5 instances running around 50 dynamic workflows inside Claude Code. The API bill came to $165,000 USD, roughly 1.119 million RMB.

Sumner estimated that if a small team had done this manually, it would have taken at least a year.

Why Rust Instead of Continuing With Zig

The direct motivation for the rewrite was not performance, but stability. This point is worth emphasizing, because many outside reports framed the migration as another “Rust wins again” story, but that’s not really what happened.

Bun is one of the very few projects that deeply mixes a GC language with manual memory management—JavaScriptCore (JSC) GC objects coexist with raw Zig pointers and also cross through a C++ layer. This hybrid model is almost entirely outside the assumptions most programming languages are designed around. Sumner put it plainly: he doesn’t blame Zig; other Zig users don’t have this problem because almost nobody uses it this way.

In the v1.3.14 fix list, Sumner listed a long series of memory issues: memory leaks, crashes, use-after-free bugs, async task race conditions, even incorrect help-text color rendering. His exact words were: “Our bug fix list felt awful. I was tired of going to sleep worrying about Bun crashing.”

Rust’s value here becomes very concrete—it can eliminate most memory safety issues at compile time. The tradeoff is writing unsafe code. Currently, about 4% of Bun’s Rust code consists of unsafe blocks, with 13,000 unsafe keywords spread across roughly 27,000 lines of code. Of those, 78% are only a single line long, and the vast majority involve C++ pointer passing or C library calls. In other words, the unsafe code is concentrated at FFI boundaries, while the application logic itself is almost entirely safe Rust. That distribution is healthy.

As for the results: all 128 reproducible bugs in v1.3.14 were fixed, and runtime speed improved by 2% to 5%. The performance gains are not spectacular, but this was never intended as a performance-focused rewrite. v1.3.14 became the final Zig release, while v1.4.0 debuted as a Canary release—the first Rust version of Bun.

How 64 Claudes Collaborated

This is the part developers should really study.

Sumner abstracted everyday engineering into a loop: 1) take a task, 2) write code, 3) have it reviewed, 4) apply feedback. He outsourced this entire loop to Claude Code’s dynamic workflows. At peak operation, the setup looked like this:

• 4 workflows running in parallel
• 16 Claude instances per workflow
• 64 Claudes simultaneously working across 4 git worktrees
• Each instance committing and pushing independently
• Peak output of roughly 1,300 lines of code per minute

1,300 lines per minute sounds completely counterintuitive in traditional engineering terms. But importantly, those “lines” were not produced in a single burst—they were distributed across dozens of parallel subtasks, each running the full “modify code → compile → test → revise” loop independently. The truly scarce resource was coordination, not typing.

Anthropic’s updated Fable 5 prompting guide from a few weeks earlier actually foreshadowed this. The document explicitly states that compared to Opus 4.8, Fable 5’s two major improvements are:

1. Improved defect-detection recall across codebases and repository history—meaning stronger reviewer capabilities
2. More reliable parallel sub-agent orchestration, enabling stable long-running communication with sub-agents

Combined with the documentation’s repeated emphasis on “asynchronous communication between orchestrators and sub-agents instead of blocking waits” and “long-lived sub-agents retaining context for cache reuse,” the methodology behind Bun’s rewrite becomes obvious. This was not a genius workflow Sumner invented out of nowhere; it emerged from the combination of model capabilities and Anthropic’s agentic engineering paradigm.

There’s also a practical reason Sumner could afford 64-way concurrency: the Bun team had already been acquired by Anthropic in December 2025. That $165,000 API bill was effectively an internal transfer. Whether independent developers can realistically reproduce this setup is a separate question.

Effort, Workflows, and Subagents: The New Core Toolkit

The most practically useful concept to emerge from this exercise may be the idea of the dynamic workflow. It differs fundamentally from familiar approaches like “multi-turn dialogue,” “Chain-of-Thought,” or “ReAct”:

• Traditional agent loops are single-agent systems: one agent repeatedly thinks, acts, and observes
• Dynamic workflows are multi-agent orchestration: an orchestrator dynamically spawns sub-agents based on the task, sub-agents independently run their own loops, and report back asynchronously

The key difference lies in the word “dynamic.” The workflow shape is not a fixed DAG predefined in advance; the orchestrator continuously reshapes it based on current progress, failures, and dependencies. This closely resembles real human team collaboration: when a project manager sees a subtask stuck, they temporarily assign another person to help; when one module finishes early, people get reassigned downstream.

Combined with Fable 5’s effort parameter (low / medium / high / xhigh), this enables very practical cost-quality tradeoffs:

• Simple boilerplate transformations: low or medium
• Refactors requiring understanding of cross-file dependencies: high
• Complex architectural decisions or difficult unsafe boundaries: xhigh

Anthropic’s official guidance says that lower effort settings on Fable 5 often already outperform the previous generation’s xhigh, making it unnecessary to max everything out blindly. That matters in cost-sensitive scenarios.

Staying Grounded: This Is Not Universally Replicable

My view on this event is: the methodology is worth learning from, but it should not be mythologized. Several prerequisites need to be made explicit.

First, Bun has an extremely comprehensive test suite. That is the foundation that allowed 64 Claudes to write code in parallel at high speed. Without tests, there is no feedback signal; without feedback, parallelism simply means parallel bug generation. Sumner did not emphasize this in the blog post, but anyone who has done serious refactoring knows this is the real critical factor.

Second, Zig → Rust is a migration with semantic mapping, not creation from nothing. The original code defined the behavioral boundaries. The AI performed “translation + refactoring,” not “design.” Asking AI to design a JavaScript runtime entirely from scratch is still far beyond current capabilities.

Third, $165K is only acceptable inside Anthropic. For ordinary teams, that amount could fund a senior engineer for half a year. The real question is: what kinds of migrations generate enough time-to-market acceleration to justify the cost? Infrastructure runtimes might. Internal enterprise CRUD systems probably won’t.

Fourth, concentrating unsafe code at FFI boundaries is a good sign, but it also suggests that pure Rust projects stand to gain even more from AI-driven migration. Once AI must reason about complex unsafe lifetimes, things become much less straightforward.

A Signal: Infrastructure Rewrites Are Shifting From “Don’t Touch It” to “Maybe Worth Trying”

Looking further ahead, the significance of the Bun case is not the 11 days or the $165,000. It is that it changes the default answer to a certain class of decisions.

In the past, the answer to “Should we rewrite this old system in a new language?” was almost always “No,” because the ROI simply didn’t work out. That default answer is now beginning to weaken. When rewrite costs fall from “a year of team labor” to “two weeks of API bills,” long-postponed technical debt—aging runtimes, historical cross-language interoperability burdens, core components written in niche languages like Zig, OCaml, or Nim—returns to the discussion table.

Interestingly, Sumner spent nearly a month writing the blog post, five times longer than writing the code itself. He admitted that publishing it required “working up the courage,” because the industry remains uneasy about large-scale AI rewrites. Hacker News debates about “technical debt” and “loss of craftsmanship” have never really stopped.

But the fact remains: it already happened. One million lines of code, 128 bugs fixed, and a runtime serving 22 million monthly downloads now running in production. Once that precedent exists, a second and third team will follow the same path. The daily work of software engineers will shift more rapidly from “90% writing code” toward “90% reviewing code,” whether people are ready for it or not.

References

• Claude Fable 5 Wrote Over 1 Million Lines of Code in 11 Days: Rust Refactor of the JavaScript Runtime Bun - IT Home: Chinese coverage of Sumner’s blog post by IT Home, including core statistics
• oven-sh/bun - GitHub: Main Bun repository, where you can inspect the v1.4.0 Canary release and the commit history of the Rust rewrite