They rebuilt the runtime,
and users got quieter

Bun 1.4.0 shipped on August 20, 2026. The official account kept the announcement to four words: "Bun 1.4 is here". Behind that line sat 2,036 commits since Bun 1.3.14. 1,375 of them touched at least one .rs file; only 21 touched a .zig file, and after July the Zig changes stopped entirely. Features came along for the ride, but the release itself was a swapped-out development substrate.[source][source]

For an infrastructure swap this size, the run-up was oddly routine. First the official account posted "Bun v1.4 is compiling". Two days later it slipped the date: "Bun v1.4 is delayed until Monday. Want to merge a few more things." On launch day Jarred Sumner wrote "things are uploaded"; his last post before the announcement read simply "3 hours". A million-line migration closed out the way most releases do — video edits, uploads, a few final merges.[source][source][source][source]

The scoreboard was anything but routine. The official summary ran: over 2,900 GitHub issues fixed, 1,517 more Node.js tests passing, idle CPU cut up to 5×, memory down as much as 35%, Linux startup as much as 50% faster — plus the rewrite from Zig to Rust itself. The team could have shipped the day the port compiled. They waited instead, holding the release until compatibility and operational performance reached the same baseline.[source]

That is why this report opens with a timeline. Set the Rust port at the origin and the rest attaches to it in order: the leak sweep, the shared allocator, the Node compatibility sprint, pnpm parity, the final delay. Bun 1.4 is what happened when follow-up work turned one enormous PR into a product.[source][source][source][source]

Bun lives in two worlds at once: JavaScriptCore's garbage-collected heap on one side, native code managing its own lifetimes on the other. Jarred published the bug list that split produced. A use-after-free in node:zlib. Pointer invalidation inside node:http2. ArrayBuffers detached mid-UDP-send. A double-free in the CSS parser. GC root leaks in fs.watch(). tlsSocket.setSession() leaking roughly 6.5KB of SSL session per call. Zig is not the villain of that list. At Bun's scale, keeping the GC-versus-manual-memory boundary correct at every call site had come to depend on sustained human attention, and attention slips.[source][source]

Jarred never framed the move as a repudiation of Zig. Bun's first Zig code dates to April 16, 2021; the initial version took about a year to build, in a world before LLMs. The Bun CLI now clears more than 22 million downloads a month. "Zig made Bun possible" and "going to sleep worrying about crashes" come from the same essay. The old choice held. The project simply grew until its failure costs and feedback loops called for a different one.[source]

"Compiler errors are a better feedback loop than a style guide." · Jarred Sumner

Rust won on a single axis: when errors get caught. In safe Rust, use-after-free, double-free, and missed frees on error paths surface as compiler errors, or Drop cleans them up. Bun's Zig codebase ran to 535,496 lines excluding comments, so a traditional rewrite would have frozen features and security fixes for a small team for the better part of a year. They chose a mechanical port instead: move the existing Zig over to Rust with minimal behavior change, and leave the architecture alone.[source][source]

"Jarred asked Claude to rewrite Bun in Rust" misses nearly everything that mattered. He kept roughly 50 dynamic workflows running for 11 straight days. The first three hours went into building PORTING.md, a map of Zig patterns to Rust patterns, and then he ran a trial on just 3 files before letting it loose on all 1,448 Zig files. In the main run, every implementing Claude got paired with two or more adversarial reviewer Claudes, and nothing was committed until review and fixes had cycled through.[source][source][source]

The most important design choice was splitting the context. The implementer saw the original Zig, the porting plan, and its own chain of reasoning. The reviewer saw only the diff, plus one instruction: assume this code is wrong and find out why. That split caught real bugs in code that already compiled — a use-after-free and a double-free after async uv_close, negative nanoseconds produced by trunc on pre-1970 timestamps, panics from an eager unwrap_or. Rather than let one model grade its own homework, the workflow built review streams with opposing interests.[source]

The run was messy. Early on, different Claudes ran git stash, stash pop, and reset --hard over each other's work, clobbering it. The fix was structural: 4 worktrees with 16 Claudes each, peaking around 64 agents in parallel. Code came out at up to roughly 1,300 lines a minute, and the port branch accumulated 6,502 commits, merges excluded. The reproducible lesson isn't the generation speed. It's that broken working habits got repaired with prompts and workflow rules, then rerun.[source][source]

During compilation, roughly 16,000 errors became the work queue. In CI, failing files fell from 972 to 23 in two days, and the merge landed only after Buildkite build #54202 went green on all six platforms. On Debian x64 alone, that meant 1,386,826 expect() calls across 60,624 tests in 4,174 files, with macOS arm64 and Windows x64 each running over a million assertions of their own. No human read all million lines. Instead the team layered language-independent tests, isolated adversarial review, per-platform CI, and manual sampling.[source][source][source]

PR #30412 landing was less a finish line than the opening of a new development substrate. Days after the port, PR #30875 titled "Fix effectively every native-code memory leak in Bun": +5,004 / −1,822 across 285 files. Nobody claimed the Rust translation had made the leaks evaporate on its own. The new tooling and sanitizers surfaced real ownership bugs, and the team cleaned them out at scale.[source]

Bun 1.4's technical identity is verifiable boundaries and fast kernels; Rust purism was never the point. PR #31116 captures the day-after mood best: the morning after pushing a million lines, the team spent the sprint clearing 2,735 lint violations with no new feature in sight.[source]

Claude Code got the Rust port first. On May 21 Jarred wrote: "Been running Claude Code on the Rust port of Bun for the last few days. I can't tell a difference". He said it passed the entire suite on all platforms, and that he'd had to ask Claude to inspect the binary just to confirm he was really running the Rust port and not the Zig build by mistake. The follow-up landed on June 4: the port had rolled out to Claude Code internally the night before, and a full day went by without a single issue report.[source][source][source]

"otherwise, barely anyone noticed. Boring is good." · bun-in-rust#production

For a rewrite, "can't tell a difference" is about as close to a definition of success as there is. Claude Code has run the Rust port since v2.1.181. Linux startup came out 10% faster, and almost nobody registered it. Prisma Compute aimed the port at its own known failure mode — connection pools and memory leaks that never recovered after a VM pause and resume — and reported that the Rust build handled it correctly. The language underneath changed; the product on top just got quieter.[source]

There's more to the package manager in Bun 1.4 than a benchmark win. The benchmark still comes first. On the T3-stack Next.js example (25 direct dependencies, roughly 220 packages in the lockfile):[source]

The bigger change is PR #38333, and the title says it all: dedupe, prune, pm licenses, audit fix, --filter, --catalog, nested overrides, transitive updates, and workspace fixes, all in one PR. GitHub counts 390 files at +107,650 / −7,700, with 65 inline review comments. The PR describes roughly 1,100 new or ported tests and differential testing against pnpm across 26 update scenario families. Jarred put the goal in one line: "Brings Bun's package manager to parity with pnpm for monorepo workflows".[source]

The same PR rebuilt performance into the structure instead of layering it on top. The isolated linker used to rescan every store entry each time one finished; that became a per-entry intrusive waiter list. On a 2,259-entry repro, main-thread link CPU dropped from 0.85 to 0.33 seconds. On a synthetic 6,425-entry monorepo, from 5.5 to 0.85. The trade: no-op isolated installs got 1.9ms (3.9%) slower because links are rechecked. Both of Jarred's lines hold side by side — "the removed work grows quadratically", and the defense that "Everything added is otherwise off the plain-install path".[source]

The old compatibility argument ran on anecdotes — this npm package works, that one breaks. Bun 1.4 replaced it with Node.js's own test suite: 1,517 tests newly pass, and the suite runs on every commit. node:http, node:fs, node:cluster, node:timers, node:zlib, node:vm, and node:stream each sit around 97% of Node's tests. node:quic reached 99%. node:events, node:trace_events, and node:sqlite cleared 100%.[source]

The individual modules show how those numbers were earned. For node:http, the team threw out the old fetch-based shim and ported Node's _http_client.js directly, layering it over net/tls sockets, the Node HTTP parser, and Agent pools. The commit message records the Node HTTP suite climbing from about 55% to 82.3%, with 182 vendored tests added.[source]

The newer modules went further than API surface. node:vm climbed from 72% to 97%; worker_threads moved from about 37% to 73.9%. Outside the repo, the scoreboard turned into ecosystem support: Playwright, Next.js 16, Vitest coverage, OpenTelemetry, and Datadog profiling now run on Bun.[source][source][source][source][source]

The page never claims "100% compatible". Inspector sits at 22/110, the test runner at 28/81, diagnostics_channel at 36/69. Keeping strong and weak modules on the same screen matters: it lets users judge whether the compatibility their stack needs has actually arrived.[source]

For web applications, the most direct change in Bun 1.4 is Web Streams going native. A download pipeline moving 64MB in 4KB chunks hit 1,519MB/s on Bun 1.4 — 204MB/s on Node 26, 530MB/s on Deno 2.9. The subprocess pipeline climbed from 505MB/s in Bun 1.3 to 751MB/s, and peak RSS fell from 207MB to 65MB. Every number comes from the same script run on each runtime.[source]

Response.clone() is a practical win for frontend servers and proxies. In builds, the gap widened with scale. The test runner now splits work across files, isolates each shard, and schedules by the timings it recorded on your last run — then, when the code changes, it looks at which tests those changes actually touch.[source]

Read top to bottom, the new APIs in Bun 1.4 can look scattershot. Bun.Image, Bun.WebView, Bun.markdown, Bun.cron, Bun.Terminal, then JSON5, JSONL, JSONC, XML, TOML, Archive, and a set of ANSI string utilities, all landing at once. One thread ties them together: take the small tools and native addons every JavaScript project installs on day one, and fold them into vetted, built-in runtime features.[source]

For frontend engineers, the emblem is Bun.WebView. On macOS it drives the system WebKit; across macOS, Linux, and Windows it can also steer an installed Chrome, Chromium, or Edge over CDP. Navigate, click, evaluate, screenshot — the whole demo runs in 5 awaits, and click events arrive carrying isTrusted === true. This goes further than replacing Puppeteer or Playwright: browser automation is now a runtime primitive.[source]

Bun.Image handles JPEG, PNG, WebP, GIF, and BMP through a sharp-like API with no native addon to install — and it beats the library it replaces: 1.38× faster converting a 1080p PNG to a 400×400 JPEG, 1.19× going from JPEG to WebP. That speed shows up across the new surface, too. On a roughly 200KB feed Bun.XML parses about 5× faster than fast-xml-parser or xml2js; Bun.wrapAnsi outruns the JavaScript implementation by as much as 88×; and on CJK text Bun.stringWidth lands anywhere from 7× to 56× ahead.[source][source][source][source]

The editorial takeaway should stop short of "you don't need npm packages anymore". The more accurate reading: Bun keeps narrowing the boundaries between runtime, package manager, bundler, test runner, browser automation, and image and document processing — widening the set of paths it can observe and optimize inside a single binary.[source]

"One engineer can do a lot more today than a year ago." · bun-in-rust#what-s-next

Ending this story at "AI wrote a million lines" loses the important half. One engineer wired together a test regime, role separation, a compiler, sanitizers, fuzzing, and real production canaries, then used that structure to steer a migration nobody would have attempted before. The verification structure built the product, more than the generation speed did.[source][source][source]

Here is the part usually left out of a byline. This report was assembled by a mass-ulw run, DAG dag_f27ee8d6, 8 nodes. Five collection lanes ran as one parallel wave: blog digest, repo window stats, PR stories with review quotes, Jarred's X posts, and StyleGallery layout patterns. They fanned in to a Korean synthesis node, which fed a visual-engineering build node, which fed a final mechanical verification node. Fan-out, fan-in, verification wave. It's the same shape Bun's roughly 50 workflows and 64 parallel agents converged on over 11 days, except here it was declared up front instead of discovered by trial.

Failure showed up on schedule. Provider aborts hit mid-run, and nothing got rebuilt: no new run key, no fresh graph. The broken nodes were recovered in place, one through amend, others through revived children, while every finished node kept its cached result. Compare that with footnote 3½ above. Bun's Claudes fought over a shared working directory with git stash and reset --hard; a graph whose lanes have disjoint write scopes can't have that fight in the first place.

The doctrine extended to prose. The Korean edition's polite-tone rewrite ran as a 5-chunk parallel fan-out, each chunk gated by tag-parity checks so the markup came back intact. Split first, route second: the question is never "which model", it's "how do I make more small lanes."

Output stayed a claim until verified. The English edition went to an independent second model under a checklist loop; the first pass came back FAIL, targeted fixes were applied to exactly the failing items, and only a re-run earned SHIP. Same spine as "make sure Claude didn't change the tests", and same completion contract start-work enforces. The report wasn't graded by its own author.

Graph engineering is the repeatable part. mass-ulw is the spine expressed as a graph, hyperplan as an argument, start-work as a ledger: lanes that fail alone, outputs treated as claims, recovery that is surgical. That's why what took a company 11 days of false starts is now an evening's declared graph.

The whole graph is open source. Run the same pipeline yourself at github.com/code-yeongyu/oh-my-openagent.