Skip to main content
bex.co
419
Blog

Anthropic Acquires Bun to Power Claude Code's $1B Run-Rate: What an AI-Lab-Owned, Still-MIT-Licensed JS Runtime Means for a git-push PaaS's Buildpack Neutrality

9 min readDora NodaDora Noda
Self-Hosting
PaaS
Claude
acquisitions
Engineering
Share
On this page

On December 2, 2025, Bun's creator announced that Bun — the JavaScriptCore-powered Node.js alternative millions of developers now have installed without necessarily choosing to — had been acquired by Anthropic. The timing wasn't incidental: Claude Code had crossed $1 billion in run-rate revenue the previous month, six months after its public launch, faster than ChatGPT (about eleven months) or Slack (over four years) reached the same milestone. Claude Code ships as a Bun executable. Every developer who installs it is running Bun, whether they know it or not.

Bun stays open-source, MIT-licensed, developed in public, same team, same GitHub. That's the reassurance Anthropic and Bun's team both led with. It's also not really the question that matters for anyone whose build layer auto-detects a bun.lockb file and hands a stranger's code to Bun's runtime without asking. The question is what changes when the company writing the runtime and the company running the single largest workload on it become the same company — and whether "still MIT" is actually the safeguard it sounds like.

What actually changed: partnership to ownership​

Before December 2025, Bun was Oven — Jarred Sumner's independently-run startup — and Claude Code was one of Bun's most visible success stories, a marquee case study for "look how fast this runs in production." That's an incentive alignment, but it's the ordinary kind: a big customer wants their vendor's product to stay good, and a vendor wants to keep a marquee customer happy. Plenty of open-source infrastructure runs on exactly that dynamic without anyone renaming the org chart.

What changed in December is that the vendor and the customer merged. Anthropic doesn't just have influence over Bun's roadmap the way any large user does — it owns the entity that sets the roadmap, employs the team that ships it, and is simultaneously the runtime's single largest workload by installed base. There's no longer a negotiation between two parties with occasionally-diverging interests. There's one balance sheet, and Bun's continued existence as a general-purpose runtime versus Bun's existence as "the thing Claude Code ships on" are decisions made inside the same building.

That structural fact is why the community reaction wasn't just "cool, more funding for an OSS project." Coverage from outlets like The New Stack and threads on Hacker News raised a specific, narrower worry: not that Bun would go closed-source or paid, but that its resourcing would quietly reorient — Claude Agent SDK integration and agentic-workflow features getting attention, while gaps unrelated to Claude Code's own needs (Windows platform maturity, memory behavior under long-running processes) drift down the priority list. The risk named wasn't malice. It was ordinary organizational gravity: the roadmap serves whoever's in the room, and now only one company is in the room.

Checking that fear against seven months of actual releases​

That worry is testable, and seven months of Bun's real release history is now on the record — so instead of treating the community's concern as settled either way, it's worth checking it against what Bun actually shipped.

The two specific gaps the community named — memory/GC behavior and Windows support — are exactly where Bun's post-acquisition releases put real effort. Bun 1.3 fixed GC over-scheduling that was driving idle CPU usage and cut JavaScript memory usage 10–30% through better GC timer scheduling; The Register covered a subsequent patch release specifically because it shipped memory fixes "as devs complain of leaks," meaning the complaints kept coming and kept getting answered in point releases, not shelved for a roadmap that never arrives. Windows support moved forward too: native ARM64 support landed, including cross-compilation of standalone executables targeting bun-windows-arm64 — the opposite of the neglect the community feared. Bun 1.3.13 alone (May 13, 2026) closed 82 issues and shipped bun test --parallel/--isolate/--shard/--changed, a 17x memory reduction in bun install's tarball streaming, and an 8x reduction in source-map memory use — general-purpose engineering work with no Claude Code-specific angle at all.

So on the narrow "will general-purpose Bun visibly stagnate" question, the first seven months say no. But the same period produced the single clearest piece of evidence that ownership changed something real, and it cuts a different way than either the optimistic or pessimistic read expects.

In May 2026, one Anthropic engineer rewrote Bun's entire runtime — 535,496 lines of Zig — into Rust in eleven days, primarily for memory safety and stability rather than any Claude-specific feature. The mechanics are the story: four workflow shards ran in parallel, each driving sixteen Claude instances in separate git worktrees, sixty-four agents running at once, using a pre-release build of Claude Fable 5 that wasn't available to anyone outside Anthropic. The run burned through 5.9 billion uncached input tokens and roughly $165,000 in API spend, and the resulting Rust codebase hit 99.8% test compatibility on Linux x64 glibc. Sumner has said the same rewrite would have taken three engineers a year with tooling available before the acquisition.

That's the concrete shape of what "AI-lab-owned" actually buys a runtime: not a roadmap secretly bent toward Claude Code at general users' expense — the release notes don't support that story — but privileged access to unreleased frontier models and a scale of engineer-hours no independent Bun-sized team could otherwise afford. It's a real advantage, it shipped a genuinely general-purpose improvement (a memory-safer runtime benefits every Bun user, not just Claude Code), and it's also access nobody outside Anthropic's building gets to use on their own infrastructure. Both things are true at once, and neither is the version of the story anyone was arguing before the evidence came in.

What "still MIT, still built in public" actually commits Anthropic to​

MIT licensing and public development are the specific, checkable commitments in play here, and it's worth being precise about what they guarantee versus what they merely make possible.

What MIT guarantees: forkability. If Anthropic ever does let general-purpose Bun development stagnate in favor of Claude-only priorities, nothing in the license stops the community from forking the codebase and continuing it independently — the code, the commit history, and the right to redistribute are all already public and already unencumbered. That's not a hypothetical mechanism. It's the exact playbook that produced OpenSearch when Elasticsearch's maintainer moved off a permissive license, and OpenTofu when HashiCorp moved Terraform from MPL to the Business Source License. Both forks happened because the underlying code was already open enough to fork before the triggering event — the permissive license was the insurance policy that paid out, not a promise anyone had to keep.

What MIT does not guarantee: that Anthropic keeps fixing bugs that don't affect Claude Code, that the community gets a real vote on roadmap priorities, or that de facto favoritism — not a license violation, just where engineering attention quietly goes first — never happens. "Built in public" means the commits are visible, not that the priority-setting conversation is. A company can ship every commit to a public GitHub repo and still make every decision about what to build next in a private roadmap meeting. Transparency of output isn't the same as transparency of intent.

So "still MIT, still built in public" is worth holding Anthropic to precisely because it's the fallback that survives a bad outcome, not a guarantee that prevents one. It's insurance, not a promise.

What a Cluster-API-based build layer should actually do about it​

For a self-hosted PaaS with bun.lockb/bunfig.toml on its buildpack-detection roadmap alongside package-lock.json, the practical answer isn't to wait and see whether Anthropic's stewardship holds up before shipping Bun support. Vercel, Render, and Railway already auto-detect Bun today — a bun.lockb or bun.lock file is enough to get zero-configuration Bun install-and-run on all three — and nothing in the evidence above says that default has become unsafe. The risk the acquisition introduces is speculative and slow-moving, not present.

What it does mean is that a build layer shouldn't architect its trust in Bun as trust in Anthropic's continued intentions. Concretely: pin the Bun version a builder targets explicitly, the same way Dokploy pins a specific heroku/builder release rather than floating against "whatever the vendor ships this week" — a stale, tracked version is a known quantity in a way an auto-updating one isn't. Keep Node.js as an equal-citizen path in the same detect step rather than a legacy fallback, which costs nothing extra since Node.js compatibility is Bun's own stated design goal anyway — a repo without a bun.lockb just runs on Node, no fork required, no bet placed on Bun's trajectory either way. And treat the MIT license as the actual safety net: because the code is already forkable today, a platform's exposure to "what if Bun's priorities drift" is bounded by the cost of vendoring a fork, not by whether Anthropic keeps its word — which is a materially smaller bet than it would be against a closed-source or restrictively-licensed runtime.

The concrete tell worth watching for going forward isn't a headline announcement. It's the first feature that ships for Claude Code or the Claude Agent SDK measurably before it ships — or without ever shipping — for everyone else running bun install with no Anthropic product in sight. Seven months in, that tell hasn't fired. The Rust rewrite is the closest thing to a preview of what "AI-lab-owned" looks like in practice: resources and access no independent maintainer had, pointed — this time — at a problem every Bun user shares.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex
Back to all posts