Cruller Picks Up the Zig Runtime Bun Left Behind

When Anthropic's Bun team rewrote their runtime in Rust this spring, roughly 700,000 lines of Zig became orphan code overnight. Now a solo developer has picked it up. Cruller forks Bun 1.3.14 — the last Zig-based release — ports it to vanilla Zig 0.16, and strips it down to the part that actually serves traffic. No package manager, no bundler, no transpiler, no test runner, no shell. What's left is JavaScriptCore, Bun.serve with HTTP/1 through HTTP/3, WebSockets, fetch, streams, and static file serving in a 73 MiB binary, about 18% smaller than the Bun release it came from.

As a product, Cruller is nowhere near ready. As an artifact, it's one of the more interesting things to happen in runtime land this year — because it's the first real test of what happens to a large pre-AI-era codebase when its corporate steward walks away from it.

The codebase Bun left behind

The backstory matters. Anthropic acquired Oven, Bun's parent company, in December 2025. By then the Bun team had already forked the Zig compiler to get roughly 4x faster debug builds, but couldn't upstream the work: the Zig project bans AI-generated contributions, and Bun's development had leaned hard into them. Add Zig's pre-1.0 breaking changes and the friction compounded. In May, Jarred Sumner published a Zig-to-Rust porting guide, insisting at the time that "we haven't committed to rewriting."

They committed. According to The Register's reporting, the rewrite landed in about 11 days using around 50 parallel Claude Code workflows, produced over a million lines of Rust, cost roughly $165,000 in API tokens, and passed Bun's existing test suite — more than a million assertions — across all platforms. Zig creator Andrew Kelley called the result "unreviewed slop," and pointedly argued the real divergence wasn't Zig versus Rust but "the diverging value systems of the two projects."

Whatever you think of Kelley's framing, the practical consequence is undisputed: Bun's Zig implementation is dead upstream. Sumner had said as much in May — if the port proceeded, the Zig code would be discarded entirely. Cruller's author, a Ziggit user going by solenopsys, decided that seven-figure-line-count investment shouldn't just evaporate, and that the salvageable core "makes more sense to turn into a convenient embeddable library."

What the fork actually is

The engineering is more disciplined than "someone forked Bun" suggests. Cruller cuts the Zig codebase from roughly 712,000 lines to 425,000 by deleting everything developer-facing: package management, bundling, the test runner, the shell interpreter, SQL clients. It keeps the webcore primitives (fetch, streams, Blob), the Valkey/Redis client, and JavaScriptCore itself as a pre-built vendored dependency, unchanged from Bun.

The more consequential move is the build. Bun compiled against its own patched Zig fork; Cruller builds with stock Zig 0.16 through a dedicated build016.zig harness, with a compatibility shim (bzrt_compat.zig) papering over stdlib APIs that changed between 0.15 and 0.16. Untangling a runtime this size from a forked compiler is genuinely useful work regardless of what happens to the project — it's the difference between "historical snapshot" and "code you can actually keep building."

Current status: Linux x64 only, glibc and musl container images, CJS/ESM execution working, HTTP smoke tests passing, and — per the author — performance parity with Bun 1.3.14 on the WebKit engine's crypto benchmarks. That last claim is the author's own and hasn't been independently benchmarked, so treat it as directional. The repo sits at around 90 stars and 25 commits.

The niche that might actually exist

Here's the honest assessment: as a Bun replacement, Cruller is a non-starter. If you run Bun in production, Rust-Bun is the supported line, and a one-maintainer fork of a 425k-line runtime — with a vendored JavaScriptCore blob whose security patch cadence is now one person's hobby — is not something you point traffic at. Zig 0.16 is still pre-1.0, which means Cruller inherits the exact churn Bun cited as a reason to leave, except now absorbed by a single developer instead of a funded team.

But the stated goal isn't "compete with Bun." It's an embeddable JSC-based server runtime as a Zig library, and that niche is real because nobody serves it well. Embedding Node via libnode is famously painful. Deno's deno_core gets you V8 from Rust, and Cloudflare's workerd gets you V8 from C++, but both drag in their host language's toolchain. QuickJS embeds beautifully and runs everywhere, and it's roughly an order of magnitude slower than a JIT engine on sustained workloads. A library that hands Zig programs a fast JSC engine plus a production-grade HTTP/WebSocket stack would be the first serious JS story in that ecosystem. Solenopsys's roadmap — QuickJS as a lightweight control plane, JSC for heavy npm workloads, io_uring message passing between runtime instances — is ambitious to the point of eyebrow-raising for one person, but the core library idea doesn't need the whole vision to be useful.

There's also a quieter use case: Cruller is now the most readable way to study modern JS runtime internals. Bun's Zig source was always open, but buried under a custom compiler fork and a mountain of tooling code. A 425k-line runtime-only tree that builds with stock Zig is a far better artifact for understanding how event loops, JSC bindings, and HTTP/3 serving actually fit together.

The uncomfortable symmetry

The tempting story is human-written Zig versus AI-generated Rust, but it doesn't hold. Solenopsys openly used AI as an "engineering assistant" for the 0.16 migration and testing, while keeping architecture and review decisions manual. Both sides of this fork used the same class of tools. What actually differs is stewardship: who reads the output, who answers for it, and who's still there when the next breaking change lands.

That's why Cruller is worth watching even if you never run it. AI assistance has collapsed the cost of rewriting, which means well-funded teams will abandon large codebases more often, which means more orphaned code worth salvaging — and the same assistance collapses the cost of the salvage. Whether one developer plus an LLM can genuinely maintain 425,000 lines of runtime is the experiment here, and nobody knows the answer yet. Check back in three Zig releases.