Bun 1.4 Rewrote a 535,000-Line Codebase From Zig to Rust in 11 Days. 64 Claude Agents Did the Port.
Bun 1.4 Rewrote a 535,000-Line Codebase From Zig to Rust in 11 Days. 64 Claude Agents Did the Port.
Bun 1.4 shipped on August 19 as the first version of the JavaScript runtime written in Rust instead of Zig, a language migration across roughly 535,000 lines of code. The release notes are full of the kind of numbers that matter to anyone running a build pipeline: 5x lower idle CPU usage, up to 35% lower memory use, 50% faster startup on Linux, and CI installs on warm caches up to 7x faster. What's getting more attention than any of that is how the rewrite reportedly happened: 64 Claude agents, split into 16 loops across 4 worktrees, running for 11 days.
What actually shipped
Bun 1.3.14 was the last release written in Zig. Bun 1.4.0 is the first written in Rust, and the release notes frame it as a full-codebase migration rather than a gradual rewrite of individual modules. Alongside the language change, Bun 1.4 adds a set of built-in APIs aimed squarely at replacing common npm dependencies: Bun.WebView for headless browser automation, Bun.Image, Bun.markdown, Bun.Terminal, and Bun.cron(). Bun's own positioning is that these can replace packages like sharp, puppeteer, marked, node-cron, node-pty, and concurrently, folding functionality that used to require external dependencies directly into the runtime.
On compatibility, Bun reports 1,517 newly passing tests from the Node.js test suite, which it calls the largest single-version compatibility jump since Bun 1.0. New CLI commands include bun audit fix, bun dedupe, and bun prune, plus parallel execution with bun run --parallel and bun test --parallel, and Windows ARM64 support lands in this release too. The opt-in global virtual store is what's behind the 7x install-speed claim on a specific, stated scenario: a 1,400-package install with a lockfile already present, a warm cache, and node_modules wiped, which is close to a typical CI runner's conditions.
The part that's actually new: how it got built
Bun's own account of the rewrite process is that 64 instances of Claude worked in parallel, organized into 16 loops spread across 4 git worktrees, with each loop structured as one agent making fixes and two others reviewing before a fourth applied changes, running continuously for 11 days to move the roughly 535,000-line Zig codebase into Rust. That's the framing in Bun's blog posts ("Rewriting Bun in Rust" and the "Bun 1.4" release notes), and it's a genuinely notable claim: a production runtime used by a large share of the JavaScript ecosystem, rewritten in its entirety in under two weeks using a coordinated multi-agent workflow rather than a dedicated human rewrite team working over months or years.
It's worth being precise about what's independently verifiable here and what isn't. The performance benchmarks (idle CPU, memory, startup time, install speed) are the kind of numbers you can reproduce yourself against a released binary, and early third-party writeups have started doing exactly that. The 64-agent, 11-day workflow story is Bun's own account of its internal process, not something a third party audited or reproduced. That doesn't make it false, but it's a claim about methodology from the same company whose product benefits from the story being impressive, and it should be read with that in mind rather than repeated as an independently confirmed fact.
What actually matters for a solo operator's dependency list
Set the AI-workflow story aside for a second, because the more directly useful part of this release for anyone shipping a real product is the dependency consolidation. Every external package your build depends on is a piece of code you didn't write, don't control the release cadence of, and have to trust wasn't compromised in a supply chain attack, which has been a live and repeated problem across the npm ecosystem this year. Folding sharp, puppeteer, marked, node-cron, node-pty, and concurrently into the runtime itself doesn't just save install time, it shrinks the actual attack surface and audit burden of a typical project's package.json. That's a smaller, more boring benefit than "AI rewrote a runtime," and it's also the one you can act on this week if any of those packages are in your stack.
The performance numbers matter too, but mostly at scale. A 50% faster Linux startup and 5x lower idle CPU are genuinely useful if you're running Bun in a container fleet or a serverless environment where startup latency and idle resource use show up directly on a bill. For a single local dev environment, you'll likely notice the CI install speedup before you notice much else.
The honest take
I'd upgrade for the dependency consolidation and the Node compatibility jump before I'd upgrade because of the rewrite story. A full language migration, even a well-tested one, is exactly the kind of change where edge cases surface in production that didn't show up in the test suite, and "biggest compatibility jump since 1.0" is also, by definition, the largest surface area for something to have shifted in ways nobody's hit yet. If you're running Bun in anything load-bearing, treat 1.4 the way you'd treat any major runtime version bump regardless of how it was built: test your actual workload against it before you flip production over, and don't let the novelty of the engineering story rush that decision.
Author
Lukas
@lukcombinator