Bun Rust Rewrite After Anthropic Acquisition: 22 Million Monthly Downloads Raise the Stakes

Bun has completed a Rust rewrite after its Anthropic acquisition, placing an AI-generated codebase beneath more than 22 million monthly CLI downloads.

The change is bigger than a routine programming language migration. Bun says Claude helped translate over 500,000 lines of Zig into roughly one million lines of Rust. The intensive porting process took 11 days.

That speed is the headline, but reliability is the real story. Bun now supports Claude Code, OpenCode, Prisma Compute, and developers who expect infrastructure to behave predictably. The rewrite asks whether compiler checks, automated reviews, and a huge test suite can make AI-generated systems code trustworthy.

It also creates an uncomfortable reversal. Zig helped one developer build Bun's broad feature set in a year. That same breadth later produced memory leaks, use-after-free defects, and maintenance pressure that Bun hopes Rust will reduce.

Bun's Rust Rewrite After Anthropic Acquisition Changes the Risk Profile

Bun did not change languages to add a fashionable label. It changed languages because recurring memory failures had become an operational burden.

Bun combines a JavaScript runtime, package manager, bundler, transpiler, test runner, and implementations of many Node.js APIs. That scope gives developers one tool for jobs that usually require several packages.

It also creates many boundaries between JavaScript and native code. JavaScript uses garbage collection, which automatically reclaims objects that are no longer reachable. Bun's native components must coordinate those objects with memory managed by lower-level code.

That coordination became a persistent source of mistakes. Bun creator Jarred Sumner listed recent defects involving use-after-free crashes, double frees, out-of-bounds access, race conditions, and unreleased memory.

A use-after-free occurs when software accesses memory after releasing it. The result can range from a crash to unpredictable behavior or a security vulnerability.

Bun v1.3.14 fixed examples across compression streams, HTTP/2 connections, UDP sockets, buffers, cryptography, TLS sessions, file watchers, and the CSS parser. These were not multiple versions of one isolated mistake.

Several failures appeared when JavaScript callbacks changed native state at an unexpected moment. Others came from cleanup code that did not run, ran twice, or ran after an allocation failed.

Bun already used several defenses. Its team patched the Zig compiler to support AddressSanitizer, a runtime tool that detects invalid memory access. The project ran those checks on every commit.

The team also used Fuzzilli continuously. Fuzzilli generates unusual JavaScript programs to expose engine and runtime failures that normal tests may miss.

Those systems found bugs after code had been written. Sumner wanted a programming model that rejected more ownership mistakes during compilation.

Rust's ownership system tracks which part of a program controls a value. Its borrow checker enforces rules governing references, while Drop automatically runs cleanup when a value leaves scope.

Safe Rust turns many use-after-free and double-free patterns into compiler errors. That offers earlier feedback than fuzzing, continuous integration, or production crash reports.

Bun's Rust rewrite therefore changes where its team expects failures to be caught. Some mistakes should now stop development before a binary runs.

The migration follows Anthropic's December 3, 2025, acquisition of Bun. Anthropic said Bun had become important infrastructure for Claude Code, which reached a substantial revenue milestone that November.

The official Bun acquisition announcement connected the runtime directly to Anthropic's coding strategy. That relationship raises the cost of instability.

Bun says its command-line interface receives over 22 million downloads each month. Vercel, Railway, and DigitalOcean also provide first-party support for the runtime.

Download counts do not equal active developers, production deployments, or unique machines. Automated builds can download the same package repeatedly. Still, the figure demonstrates the size of the distribution surface that Bun must support.

The first Rust version is not merely a new implementation behind a niche experiment. It sits under tools that operate inside repositories, build systems, and deployment pipelines.

That makes the Bun Rust rewrite after Anthropic acquisition a test of two promises. Rust should prevent common memory mistakes, while Claude should make an otherwise impractical migration economically possible.

The rewrite will be judged by whether both promises survive production use.

Twenty-Two Million Monthly Downloads Turn Stability Into the Product

At Bun's current scale, reliability is no longer a secondary engineering goal. It is part of the product developers install.

Bun began as Sumner's line-by-line port of esbuild's JavaScript and TypeScript transpiler from Go to Zig. He wrote his first Zig code in April 2021.

The original version took about one year to build. Sumner has credited Zig's simplicity and low-level control with making that pace possible before modern coding models existed.

That origin matters because the rewrite does not establish a simple winner between Rust and Zig. Zig enabled Bun to reach the market with an unusually broad feature set.

Bun then accumulated responsibilities that made manual lifetime management increasingly expensive. Its runtime embeds JavaScriptCore, the engine used by Safari, alongside several C and C++ libraries.

Those dependencies include networking, encryption, database, and compression components. About one-fifth of the earlier Bun codebase was already written in C++.

Rust cannot automatically make those external libraries safe. Foreign function interfaces, or FFI boundaries, connect Rust to code whose memory rules the compiler cannot fully verify.

However, Rust can concentrate those interactions inside explicitly marked unsafe sections. Developers can then identify where the compiler's ordinary guarantees no longer apply.

The language also makes routine cleanup more consistent. In Zig, developers commonly attach defer to individual call sites that must release a resource.

That explicit model gives engineers control, but it requires disciplined repetition. Rare error paths can skip cleanup or accidentally perform it twice.

Rust's Drop mechanism ties cleanup to an object's lifetime. Bun says that change already helped correct leaks involving file paths and build data.

One internal test repeatedly bundled a project containing 60 modules within the same process. Bun reported that v1.3.14 leaked about three megabytes during every build.

After 2,000 builds, the Zig version consumed 6,745 megabytes in Bun's test. The Rust implementation leveled off at 609 megabytes, according to the company.

That comparison has not been independently reproduced across varied workloads. It still illustrates the failure mode Bun is trying to eliminate.

A development server might rebuild code after every request or file update. Even a modest leak becomes serious when the process runs for days.

The same concern applies to coding agents. Claude Code may launch supporting processes repeatedly while inspecting files, running commands, and modifying a repository.

A runtime failure can interrupt the agent, corrupt an intermediate result, or leave developers debugging infrastructure instead of their application.

Claude Code moved to the Rust port before Bun 1.4 reached a general release. Bun says Claude Code version 2.1.181, released June 17, used the new implementation.

According to Bun's production telemetry, median Linux startup time fell from 517 milliseconds to 464 milliseconds. That represents about a 10 percent improvement.

Speed was not the central objective. The more meaningful claim was that most users did not notice the language change.

Invisible infrastructure migrations are often successful migrations. Applications should retain the same behavior while maintenance and reliability improve underneath them.

Prisma supplied another early production test. Its serverless database platform used the Rust rewrite for the Prisma Compute public beta.

Prisma said the earlier implementation encountered memory leaks and could not recover its connection pool after a virtual machine paused and resumed. Its engineers retested those scenarios against the port.

The new implementation handled those specific failure modes, according to Prisma's production assessment. Prisma also cautioned that unsafe code still requires audits and human review.

This combination captures the stakes better than the download count alone. The port has produced measurable improvements, but production confidence requires more than passing demonstrations.

Node.js and Deno also face pressure from Bun's progress, although neither is the central opponent in this story. Node.js remains the compatibility baseline for server-side JavaScript.

Deno already uses Rust around the V8 JavaScript engine. Its architecture offers a relevant comparison for managing a JavaScript runtime through Rust and native dependencies.

Bun must preserve Node.js compatibility while maintaining its performance claims and broader toolkit. A rewrite that reduces crashes but introduces behavior differences would simply exchange one reliability problem for another.

The team therefore chose a mechanical port instead of an immediate redesign. The new Rust code intentionally resembles the previous Zig architecture.

That decision reduced behavioral change during migration. It also carried old assumptions and low-level patterns into a language with different safety rules.

The result creates the central tension behind the project. Bun chose Rust for stronger guarantees, but its safest path to compatibility initially preserved substantial unsafe code.

Claude Replaced a One-Year Rewrite With an 11-Day Verification Loop

The notable mechanism was not raw code generation. It was a controlled loop that separated implementation, criticism, correction, and testing.

Bun estimated that a conventional rewrite would occupy three experienced engineers for about one year. During that period, feature work and compatibility improvements would slow or stop.

The existing Zig codebase contained 535,496 lines, excluding comments. A manual port would also create a long-lived branch that continuously drifted from the production version.

Sumner instead tested a pre-release Anthropic model called Claude Fable 5. He spent about three hours developing rules for translating Zig patterns, types, and lifetimes into Rust.

Claude recorded those decisions in a porting guide. A second generated document mapped expected lifetimes for fields across the codebase.

The team started with three files rather than immediately translating everything. One Claude instance implemented each port, two separate instances reviewed it, and another applied corrections.

This separation was deliberate. A model that produced a change may remain biased toward accepting its own reasoning.

The reviewing instances received the diff without the implementer's full context. Their assigned role was to search for incorrect behavior and regressions.

Sumner called this adversarial review. It resembles independent code review, but all participants were instances of the same model family.

The full operation used about 50 dynamic Claude Code workflows. At peak, four workflow groups ran simultaneously, each coordinating 16 Claude instances.

That meant roughly 64 agents worked at once. The port reached a reported peak of about 1,300 generated lines per minute.

The process was not smooth from the beginning. Agents working in the same repository used conflicting Git commands, including stash operations and a hard reset.

Sumner changed their instructions to prohibit broad Git operations. The system eventually used four separate worktrees, with agents committing specific files and sharing results through branches.

This failure is important because it shows that model capability alone did not produce the rewrite. The workflow required explicit constraints around shared state and destructive actions.

Teams considering similar migrations would need equally clear operational rules. An agent that writes correct code can still damage work by mishandling repositories, credentials, build systems, or deployment tools.

The migration generated 6,502 commits excluding merges, while Bun reported 6,778 total commits during the 11-day window. The landed diff added just over one million lines.

Those numbers describe activity, not quality. Small commits can improve traceability, but thousands of automated commits also overwhelm conventional human review.

Bun relied primarily on compilers, automated reviewers, and its existing test suite. That suite contained roughly one million assertions across supported platforms.

Before merging, the team reported 100 percent test completion in continuous integration. It said no tests were deleted or skipped.

On Debian, Bun recorded 1,386,826 expect() calls across 60,624 tests. macOS and Windows each ran over one million assertions.

A test suite written in TypeScript gave Bun an important advantage. The tests evaluated observable behavior without depending on whether the runtime underneath used Zig or Rust.

That architecture made a mechanical port measurable. Each translated component had to preserve results already expected by the same external tests.

Claude also processed compiler errors as a work queue. Bun split the Rust code into about 100 crates, which are separately compiled packages within a Rust project.

At one stage, cargo check produced about 16,000 errors. Workflows grouped those failures by crate, assigned them to agents, reviewed fixes, and repeated the process.

The compilation loop converted an intimidating migration into bounded tasks. Each error provided local feedback that an agent could act upon.

This approach worked especially well because Rust's compiler explains many ownership and type failures precisely. The compiler became both a gate and a source of structured instructions.

The process consumed 5.9 billion uncached input tokens and 690 million output tokens before the merge. It also read 72 billion cached input tokens.

Bun estimated the total at about $165,000 using API pricing. The amount does not include every organizational cost, including the original codebase, tests, human expertise, or later maintenance.

The comparison with three engineers for a year is therefore directional rather than complete. Claude did not create Bun's architecture, compatibility work, or test corpus from nothing.

It exploited years of accumulated engineering context. The migration's speed depended on that context being available in formats agents could read and validate.

This distinction matters for other teams. A mature test suite and well-defined behavior can make automated migration plausible.

A poorly tested system offers no equivalent oracle. Agents may produce code that compiles while silently changing the behavior users depend on.

Engineering teams also need durable records explaining agent decisions. A searchable knowledge base can preserve migration rules, review findings, and ownership assumptions beyond individual context windows.

The Bun project did this through porting documents, lifetime maps, commit history, and tests. Those artifacts were not administrative extras.

They were the system that made high-speed generation reviewable at all.

Rust Cannot Guarantee Safety Where Bun Still Uses Unsafe Code

The rewrite reduces several classes of risk, but it does not justify treating Bun as automatically memory-safe.

Bun's mechanical translation preserved low-level pointer operations and extensive interaction with C and C++ libraries. Those areas often require Rust's unsafe keyword.

An unsafe block allows operations that the borrow checker cannot validate. The programmer must uphold the necessary rules manually.

This does not mean every unsafe block contains a defect. Major Rust systems use unsafe code to implement efficient abstractions and connect with operating systems or native libraries.

It does mean Rust's most valuable guarantees depend on how those boundaries are designed, documented, and audited.

Sumner reported that about four percent of Bun's Rust code initially sat inside unsafe blocks. He described approximately 27,000 unsafe lines within roughly 780,000 lines of Rust.

He also said 78 percent of those blocks contained a single line. Many handled a C++ pointer or one call into a native library.

That framing is relevant, but block length does not establish correctness. A single unsafe pointer conversion can create a lifetime error that affects safe code elsewhere.

A public memory safety issue demonstrated the concern on May 14. The report showed a safe function erasing a slice lifetime and allowing a dangling reference.

Miri, an interpreter used to detect undefined behavior in Rust programs, flagged the example. Undefined behavior means the language places no reliable constraints on the result.

Bun's automated contributor reproduced the problem and identified a parallel lifetime hole. The proposed fix marked affected functions as unsafe and documented their lifetime requirements.

The response showed that the project could process a concrete report quickly. It also showed that compilation and the existing test suite had not prevented every invalid abstraction.

That gap supports the strongest skeptical argument against the rewrite. If automated tests missed memory errors in Zig, the same tests cannot prove a large Rust port is sound.

Rust adds compiler enforcement, but unsafe sections move responsibility back to engineers. A mechanical translation can preserve the original pointer discipline inside those sections.

Zig creator Andrew Kelley offered the sharpest public criticism. His rewrite response argued that Bun's problems reflected engineering practices and accumulated technical debt, not a failure of Zig.

Kelley also questioned whether a massive body of model-generated code received sufficient human scrutiny. His critique became personal in places, which distracted from the technical question.

That question remains valid: What level of independent review should infrastructure require before teams trust an AI-generated rewrite?

Bun says each line received reviews from two separate Claude instances. Yet model review is not equivalent to independent human judgment.

Instances of the same model can share blind spots, training patterns, and incorrect assumptions. Separate context windows reduce anchoring, but they do not create truly independent expertise.

Automated reviewers caught several plausible bugs before the merge. One involved an asynchronous close operation that would have freed a resource twice.

Another mishandled negative timestamps. A third used an eager Rust method that would panic while parsing certain CSS color expressions.

These examples show that adversarial review contributed real value. They do not reveal how many defects all reviewing agents missed together.

The debate should not collapse into a choice between accepting or rejecting AI-generated code. The more useful question concerns assurance.

Teams already trust compilers, static analyzers, fuzzers, formal models, and automated test systems. Coding agents can join that collection without becoming the final authority.

Prisma's position offers a practical middle ground. It deployed the port for its public beta and reported improvements under known failure scenarios.

At the same time, Prisma said unsafe code needs auditing and translated code needs review. It recommended refactoring non-idiomatic sections into pieces humans can understand.

Bun has made a similar commitment. Its initial objective was behavior preservation, followed by gradual work to reduce unsafe usage and adopt more idiomatic Rust.

That sequence is defensible, but it delays part of the safety payoff. Until the unsafe surface shrinks, the migration remains an ongoing engineering program.

The argument also extends beyond memory safety. A runtime can fail through incorrect module resolution, incompatible APIs, networking behavior, performance regressions, or subtle differences between operating systems.

Rust does not prevent logical errors. Neither does a million-assertion test suite prove correct behavior for every JavaScript package in circulation.

Bun therefore needs external workloads, independent audits, fuzzing, and long-running production deployments. Each provides evidence that internal validation cannot supply alone.

The Bun Rust rewrite after Anthropic acquisition should be treated as a promising migration under active verification. Calling it either a complete safety success or automated failure would outrun the available evidence.

Three Signals Will Decide Whether Bun's Rewrite Worked

The next stage is less dramatic than the 11-day port, but it will determine whether the rewrite becomes a model or a warning.

The first signal is Bun 1.4's behavior across ordinary production deployments. Bun v1.3.14 was the final Zig release, while v1.4 introduced the Rust implementation.

Teams should watch crash reports, memory consumption, compatibility regressions, and rollbacks after wider adoption. A successful release should reduce memory failures without creating a new category of behavioral bugs.

The early Claude Code and Prisma deployments strengthen Bun's case. They do not cover the full variety of package combinations, operating systems, native modules, and workload patterns.

Broad use will expose code paths that Bun's internal suite never reached. Stable results over several release cycles would provide stronger evidence than launch benchmarks.

The second signal is the size and design of Bun's unsafe Rust surface. Raw counts need context, because FFI-heavy runtimes cannot eliminate unsafe code completely.

The more meaningful question is whether unsafe operations move behind small, documented interfaces. Each interface should state the lifetime, aliasing, ownership, and thread-safety assumptions callers must respect.

Independent audits would strengthen this work. Public Miri findings, sanitizer results, and fuzzing outcomes should also receive visible fixes with regression tests.

If unsafe usage declines while Bun preserves performance and compatibility, the rewrite's safety argument becomes stronger. Repeated lifetime failures inside safe interfaces would weaken it.

The third signal is whether another mature project reproduces Bun's migration method. Bun had an unusually favorable starting point: extensive tests, one principal architect, and an owner with access to a pre-release model.

A second successful migration would need to show more than fast code generation. It should document human review, defect discovery, operational controls, and post-release maintenance.

If those results repeat, AI-assisted language migrations could become a normal option for projects trapped behind years of rewrite cost.

If Bun remains an isolated demonstration, its lesson will be narrower. The achievement would still matter, but it would say more about Bun's test infrastructure than general software development.

The broader contest is not Rust against Zig. It is machine-generated velocity against the evidence required to trust foundational software.

Bun moved that contest from toy projects into a runtime with more than 22 million monthly downloads. Anthropic also placed the result inside Claude Code before the public debate had settled.

That choice gives Bun valuable production feedback. It also makes Anthropic responsible for proving that its coding agents can maintain what they generate.

Developers should follow release notes, unresolved safety reports, and independent deployment results before making high-risk migrations. They should also test their own dependencies under realistic loads.

The Bun Rust rewrite after Anthropic acquisition has already shown that an AI-assisted port can cross a previously prohibitive scale boundary.

The open question is whether its verification process can keep pace with its generation process. Watch Bun 1.4's field performance, unsafe-code audits, and the next large project that attempts the same method.