Buz Revives Zig-Era Bun With Sub-Second Rebuilds

A one-person fork of Bun called Buz surfaced this week with a claim that would have sounded like fantasy to anyone who hacked on Bun a year ago: sub-second incremental builds of a half-million-line JavaScript runtime. The fork itself is nowhere near usable — the author says so in the README, right above the warning about unpatched vulnerabilities. But as an exhibit in the ugliest toolchain divorce of 2026, it's the most pointed artifact yet.

How we got here

Quick recap, because the backstory is doing most of the work. Bun was written in Zig, became the language's flagship project, and was acquired by Anthropic in December 2025. Along the way the Bun team grew frustrated with debug compile times and maintained its own fork of the Zig compiler — parallel semantic analysis, multiple codegen units — that made debug builds over 4x faster. Zig upstream wouldn't take the changes, citing its policy against LLM-authored contributions.

Then in May 2026, Jarred Sumner ran roughly 64 Claude agents for 11 days and ported the entire codebase — about 535,000 lines of Zig — to Rust, at a reported API cost of around $165,000. The stated rationale was memory safety: use-after-free and double-free bugs that Zig makes possible and Rust's borrow checker makes compile errors. Bun v1.3.14 became the final Zig release; v1.4.0 shipped in Rust. Zig creator Andrew Kelley called the result "unreviewed slop" and argued the rot predated the LLMs. It got personal, publicly, and it's still going.

Buz forks from that last pre-Rust commit. It's a preservation project with an argument embedded in it.

What the fork actually does

The technically interesting move isn't the fork itself — it's the port to modern Zig. Stock Bun couldn't build on upstream Zig at all; it was welded to the team's own compiler fork. Buz's author (GitHub handle jazzzooo) got the codebase compiling against Zig's current master branch, consolidated the build graph into a single build.zig, deleted over 11,000 lines of dead code, and builds most dependencies — including JavaScriptCore and ICU — from source. The payoff is the headline claim: change a file, rebuild in under a second.

That number is author-reported and I couldn't independently reproduce it, but it's entirely plausible, and that's the part worth understanding. Zig's self-hosted x86_64 backend became the default for debug builds in 0.15.1, making debug compilation roughly 5x faster than the LLVM path. The 0.16 release in April 2026 matured incremental compilation further, and the Zig team has demonstrated ~30ms incremental rebuilds of real projects — including the Zig compiler itself. Run zig build --watch -fincremental on a codebase that plays nicely with the self-hosted backend and sub-second iteration on a 500kloc project is no longer a stunt. It's what the compiler was redesigned to do.

Which makes Buz a genuinely awkward data point. Bun spent years fighting compile times on a pinned, patched compiler, then cited developer velocity among the reasons the Zig era had to end. Buz suggests that a chunk of that pain was self-inflicted: the fix for slow Zig builds was shipping in upstream Zig, and Bun's fork strategy kept the project from receiving it. To be fair to Sumner, compile times were never the stated core rationale — memory safety was, and nothing about incremental compilation fixes a use-after-free. But the "Zig tooling was holding us back" narrative takes real damage here.

There's a second irony worth savoring. Buz's README requires that all contributions be LLM-assisted — a deliberate inversion of the upstream Zig policy that started this whole feud, running on Zig, hosted in a Zig community forum thread. The author openly credits heavy LLM use for making a one-person port of this scale possible at all. Whatever side of the AI-code argument you're on, both camps in this fight are now building with the same tools; they just disagree about whether to admit it at merge time.

Should you care?

If you're a JavaScript developer running Bun in production: no, not even a little. Buz targets x86_64-linux-gnu only, doesn't pass the full upstream test suite, ships a stale JavaScriptCore with known unpatched CVEs, and has 17 stars. If the Rust rewrite makes you nervous — and the "1M lines of generated code validated by the old test suite" methodology is a fair thing to be nervous about — your exits are Node or Deno, not a frozen fork of Bun 1.3.14. Runtimes live and die on security response, and Buz explicitly has none.

If you build native tooling, the calculus is more interesting. The strongest practical complaint about Zig for large projects — glacial edit-compile-test loops — is measurably dissolving. A contributor iterating on a bundler bug in Buz rebuilds in under a second; the same loop on old Bun meant minutes per cycle, which is the difference between staying in flow and context-switching to Twitter. Rust, meanwhile, still makes you pay for the borrow checker in compile time on every iteration. Safety versus iteration speed is a real trade-off again, not a rout.

My read: Buz the runtime is a dead end, and I'd bet against it ever passing Bun's test suite. Buz the benchmark is the most concrete public demonstration that Zig's incremental compilation has arrived on real, hostile, half-million-line codebases — not toy examples. That matters far beyond this feud. The JS runtime wars were never going to be relitigated by a fork; but the next team choosing a systems language for a compiler, bundler, or runtime just got a data point that didn't exist six months ago.