Tools · · 2 min read

Claude Code now runs on a Rust rewrite of Bun — and Claude agents did most of the port

Since v2.1.181 (June 17, 2026), Claude Code has quietly shipped on a Rust reimplementation of the Bun runtime: 10% faster startup, a 20% smaller binary, fewer memory leaks. The meta-story is bigger — the 11-day, 6,778-commit rewrite ran on ~64 Claude Fable 5 agents for about $165K. Here's what changed and how to check your own build.

Claude Code has been running on a Rust reimplementation of Bun in production since v2.1.181 (June 17, 2026) — the first production service to ship on it, according to Bun’s own writeup. Most users noticed nothing. That’s the point. (Source: Simon Willison; Bun blog)

Key facts:

  • Bun was rewritten from Zig to Rust. The last Zig release was v1.3.14; the first Rust release is v1.4.0. (Source: Bun blog, 2026)
  • The rewrite took 11 days (May 3–14, 2026) and 6,778 commits. (Source: Bun blog)
  • It was driven largely by AI agents: ~64 Claude Fable 5 instances running in parallel across git worktrees, consuming roughly 5.9 billion input tokens and 690 million output tokens at an estimated $165,000 in API cost. (Source: Bun blog)
  • Claude Code v2.1.181 startup got about 10% faster on Linux (517ms → 464ms, p50). (Source: Bun blog)
  • Bun’s binary shrank about 20% on Linux and Windows, and repeated-build memory leaks were eliminated. (Source: Bun blog)
  • You can confirm your own build: strings ~/.local/bin/claude | grep -m1 'Bun v1'. (Source: Simon Willison)
Bun benchmark chart: Claude Code v2.1.179 starts in 517ms versus v2.1.181 on Rust Bun at 464ms, about 10% faster
Claude Code's cold-start dropped from 517ms (v2.1.179) to 464ms (v2.1.181, first release on Rust Bun) — production Linux p50 telemetry. (Source: Bun blog)

The engineering rationale is memory safety: Bun’s Zig codebase kept hitting heap-use-after-free, double-frees, and leaks from mixing garbage-collected JavaScript values with manually managed memory. Rust’s borrow checker and automatic cleanup close that whole bug class. Prisma’s Alexey Orlenko tested the Rust build against a connection pool that “couldn’t recover after a VM was paused and resumed” and reported “it handled them perfectly.” (Source: Bun blog)

What this means if Claude Code is your daily driver

Two separate takeaways, and the second one matters more.

  • The practical part is boring, which is good. If you’re on v2.1.181 or later you already got the faster startup and smaller footprint for free — no config change, no behavior change. The maintainer’s own summary: “Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.” Nothing to migrate. If you want to verify, run the strings check above.
  • The real signal is the port itself. A production JavaScript runtime — one now on millions of devices via Claude Code — was translated to a different language in 11 days by ~64 Claude agents for about $165K. That’s a concrete, priced datapoint for anyone weighing an agent-driven large refactor. The method wasn’t “prompt and pray”: it used a written porting guide, phase-by-phase progression (mechanical translation → compiler fixes → test fixes), compiler errors treated as a work queue, and separate adversarial Claude instances assigned to find bugs in the output.

If you’re planning your own big migration with a coding agent, that structure — explicit phases, a spec the agent follows, and a second agent whose only job is to attack the diff — is the transferable lesson. It’s the same “make the agent your daily driver, then scaffold it” thread we cover in making a coding agent your daily driver, and the cost side connects to reducing Claude Code token overhead — 5.9B input tokens is exactly where prompt caching pays for itself. The rewrite itself ran on Claude Fable 5, and if you’re comparing harnesses for this kind of work, see our Claude Code vs Codex head-to-head.

Sources

Source: Simon Willison