# Anthropic und Bun: Die Runtime, die in deiner Claude-Code-Binary wohnt

> Anthropic hat Bun gekauft, Claude Code wird als Bun-Executable ausgeliefert — und Bun 1.4 ist in elf Tagen von einer KI nach Rust portiert worden. Ich habe die Binary auf meinem Rechner aufgeschraubt und nachgesehen, was davon stimmt.

Source: https://www.jpkc.com/db/blog/bun-anthropic-claude-code/

Ich bin über die Release-Notes zu [Bun 1.4](https://bun.com/blog/bun-v1.4) gestolpert und habe dort zwei Dinge gelernt, die mir beide neu waren: Bun gehört seit Dezember 2025 zu Anthropic. Und Claude Code — das Werkzeug, mit dem ich einen großen Teil meiner Arbeitswoche verbringe — wird als Bun-Executable ausgeliefert.

Das zweite hat mich mehr überrascht als das erste. Ich benutze Claude Code täglich, ich habe [ausführlich darüber geschrieben, wie ich es konfiguriere](https://www.jpkc.com/db/blog/claude-code-konfiguration/), und mir war nie aufgefallen, dass da gar kein Node.js läuft. Also habe ich die Binary auf meinem eigenen Rechner aufgemacht und nachgesehen.

Dieser Artikel ist das Ergebnis. Er erzählt die Vorgeschichte von Bun, den Kauf und die Begründungen beider Seiten, er nimmt meine eigene Claude-Code-Binary auseinander, und er ordnet ein, was Bun 1.4 dir als Entwickler wirklich bringt — inklusive der Stellen, an denen ich nach der Recherche skeptischer bin als vorher. Wo ich Zahlen nenne, habe ich sie entweder selbst gemessen oder die Primärquelle danebengelegt. Wo ich etwas nicht belegen konnte, sage ich das.

## Die Kurzfassung

| Frage | Antwort | Beleg |
|---|---|---|
| Wurde Bun wirklich gekauft? | Ja, angekündigt am **2. Dezember 2025** | [Bun-Blog](https://bun.com/blog/bun-joins-anthropic), [Anthropic-Newsroom](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) |
| Was genau? | Oven, die Firma hinter Bun — Anthropics erste echte Firmenübernahme | [RedMonk](https://redmonk.com/sogrady/2026/06/04/bun-two-lessons/) |
| Kaufpreis? | Nie genannt | — |
| Bleibt Bun Open Source? | Ja, MIT — Zusage von beiden Seiten, Stand heute gehalten | [LICENSE.md](https://raw.githubusercontent.com/oven-sh/bun/main/LICENSE.md) |
| Steckt Bun in Claude Code? | Ja, nachweisbar an der Binary | eigene Messung, siehe unten |
| Ist Bun noch in Zig geschrieben? | Nein — seit Mai 2026 in Rust, portiert von Claude | [Bun-Blog](https://bun.com/blog/bun-in-rust) |

## Wie Bun entstand

Bun ist das Werk von Jarred Sumner. Auf seiner eigenen Seite beschreibt er sich als jemand, der bei Anthropic an Bun und Claude Code arbeitet, davor Frontend-Engineer bei Stripe war und „long before that, a Thiel Fellow and a high school dropout". Die Thiel-Fellowship-Klasse 2014 ist belegt, damals war er 18.

Der Auslöser für Bun war kein Runtime-Plan, sondern Frust. Sumner baute ein Minecraft-artiges Voxel-Spiel im Browser, und sein Iterationszyklus dauerte 45 Sekunden — größtenteils Wartezeit auf den Next.js-Dev-Server. Er portierte daraufhin den JSX- und TypeScript-Transpiler von esbuild von Go nach Zig. Seine eigene Zusammenfassung: „Three weeks later, I had a somewhat working JSX & TypeScript transpiler." Die Runtime kam erst später dazu, weil der Dev-Server Server-Side-Rendering brauchte.

Das GitHub-Repository wurde am 14. April 2021 angelegt. Zig wählte er wegen Comptime, guter Dead-Code-Elimination und fehlender versteckter Allokationen — und weil er mit Rust „just wasn't very productive" war. Für die Engine entschied er sich gegen V8 und für JavaScriptCore, die JavaScript-Engine aus WebKit: QuickJS hat keinen JIT, V8 bringt „this fixed startup time cost" mit, während JavaScriptCore „a really good balance of fast startup time, but with a very, very good JIT" biete.

Nach über einem Jahr privater Beta kam am 5. Juli 2022 die öffentliche Vorstellung mit Bun v0.1.0 — 20.000 GitHub-Sterne in der ersten Woche. Ende August 2022 stellte Sumner die Firma dahinter vor: **Oven**, finanziert mit 7 Millionen US-Dollar unter Führung von Kleiner Perkins. Das erklärte Ziel war „a stable release of Bun in under six months". Daraus wurden zwölfeinhalb Monate: **Bun 1.0 erschien am 8. September 2023**, mit dem Anspruch, ein „fast, all-in-one toolkit for running, building, testing, and debugging JavaScript and TypeScript" zu sein. Später kam eine Series A über 19 Millionen Dollar unter Führung von Khosla Ventures dazu — wann genau, hat nie jemand öffentlich datiert; sie muss nach Ende September 2023 liegen. Gesamtfinanzierung: 26 Millionen.

Ein Detail, das dir bei der Lizenz begegnen wird: „Bun itself is MIT-licensed" steht seit den ersten READMEs unverändert da. Weil aber JavaScriptCore und WebKit statisch gelinkt werden und unter LGPL-2 stehen, führt GitHub die Lizenz als „Other/NOASSERTION". Das ist kein Lizenzwechsel, sondern eine Eigenart statischen Linkens.

## Der Kauf

Am **2. Dezember 2025** veröffentlichte Sumner den Beitrag „Bun is joining Anthropic". Der erste Satz: „TLDR: Bun has been acquired by Anthropic." Anthropics eigene Newsroom-Seite trägt zwar den Stempel „Dec 3, 2025", die Meldung lief aber am selben 2. Dezember — Reuters schrieb „said on Tuesday", und die Anthropic-URL landete eine Minute vor dem Bun-Blogpost auf Hacker News. Wer die eintägige Differenz zur Dramaturgie ausbaut, baut auf einem CMS-Datum.

Übernommen wurde nicht bloß ein Repository, sondern die Firma Oven. Für Anthropic war das die erste echte Firmenübernahme — das Humanloop-Team war im August 2025 dazugekommen, ausdrücklich ohne Assets und ohne geistiges Eigentum. **Konditionen wurden nie genannt.** The Information berichtete von einem Betrag im niedrigen dreistelligen Millionenbereich; das ist eine anonyme Quelle hinter einer Paywall und keine bestätigte Zahl.

Bemerkenswert ist, wie explizit die Zusagen ausfielen. Unter „What doesn't change" listet der Bun-Blogpost fünf Punkte auf: Bun bleibt Open Source und MIT-lizenziert, wird weiterhin sehr aktiv gepflegt, dasselbe Team arbeitet daran, die Entwicklung bleibt öffentlich auf GitHub, und die Roadmap bleibt auf Performance, Node-Kompatibilität und die Ablösung von Node.js gerichtet. Anthropic selbst gab nur eine schriftliche Zusage: „Bun will remain open source and MIT-licensed."

Die Begründungen sind auf beiden Seiten lesenswert, weil sie unterschiedlich ehrlich sind.

Anthropics Chief Product Officer Mike Krieger sagt: „Bun represents exactly the kind of technical excellence we want to bring into Anthropic." Flankiert wird das von der Zahl, dass Claude Code im November 2025 — sechs Monate nach der allgemeinen Verfügbarkeit — eine **Run-Rate von einer Milliarde US-Dollar** erreichte. Achte auf das Wort: Run-Rate ist ein hochgerechneter Jahresumsatz aus einem kurzen Zeitraum, kein realisierter Jahresumsatz.

Sumners Begründung ist konkreter. Erstens technisch:

> „Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent."

Und zweitens wirtschaftlich, in einer Offenheit, die du selten zu lesen bekommst: „Today, Bun makes $0 in revenue." Dazu der Satz, dass „wir haben 26 Millionen eingesammelt" keine gute Antwort auf die Frage sei, ob es Bun in fünf oder zehn Jahren noch gibt. Anthropic erspare Bun das Kapitel „VC-finanziertes Startup versucht, Monetarisierung zu finden". Wichtig für die Einordnung: Sumner betont ausdrücklich, dass es keine Notlage war — „We had over 4 years of runway to figure out monetization. We didn't have to join Anthropic."

Zustande kam der Deal nach einem vierstündigen Spaziergang mit „Boris from the Claude Code team", gefolgt von rund drei weiteren. Danach führte Sumner dieselben Gespräche mit mehreren Wettbewerbern. Sein Fazit: „I think Anthropic is going to win."

## Warum ein KI-Labor eine JavaScript-Runtime kauft

Die naheliegende Antwort — „damit Claude Code nicht kaputtgeht" — ist die richtige, aber nur die halbe.

Der zweite Strang ist die **Auslieferung**. Ein Agent, der überall laufen soll, will als eine Datei ankommen, nicht als Node-Installation plus `node_modules`. Genau das leistet `bun build --compile`: Runtime und Anwendung in einer Binary. Anthropic schreibt selbst, die Zusammenarbeit habe „directly drove the recent launch of Claude Code's native installer" — der Kauf hat also einen Auslieferungsweg ermöglicht, den es vorher nicht gab.

Der dritte Strang ist Sumners These, dass die Laufzeit- und Toolingschicht wichtiger wird, wenn Agenten den Code schreiben, testen und ausführen: Menschen sind von der einzelnen Zeile entkoppelt, also muss die Umgebung „fast and predictable" sein. Ob das trägt, wird sich zeigen. Belegbar ist die Richtung immerhin an Bun 1.4 selbst: Die neuen Profiling-Reports `--cpu-prof-md`, `--heap-prof-md` und `--metafile-md` geben Markdown aus, ausdrücklich damit du es in ein Sprachmodell einfügen kannst.

**Was Bun ausdrücklich nicht liefert, ist Sandboxing.** Es gibt kein Berechtigungsmodell wie Denos `--allow-*`. Das Sandbox-Issue im Bun-Repository ist seit dem 20. Oktober 2023 offen, zwei explizit auf KI-Agenten gemünzte Anträge vom Januar 2026 wurden als Duplikate geschlossen. Bun 1.4 hat genau ein sandbox-nahes Feature: Unter Windows läuft Bun in einem AppContainer, sodass ein einbettendes Programm es mit einem Lowbox-Token einsperren kann. Präzise formuliert: Bun hat kein Runtime-Berechtigungsmodell, macht sich aber von außen sandboxbar.

Das ist konsistent, denn Anthropic hatte die Antwort auf diese Frage längst woanders gebaut. Das Paket `@anthropic-ai/sandbox-runtime` (Seatbelt, bubblewrap, Windows Filtering Platform) erschien am **20. Oktober 2025** auf npm — sechs Wochen **vor** der Bun-Übernahme. Sandboxing findet außerhalb der Runtime statt, und das war schon entschieden, bevor die Runtime gekauft wurde.

Ein Kontrast, der mir hängen geblieben ist: Anthropic hat das Model Context Protocol am 9. Dezember 2025 an eine Stiftung der Linux Foundation abgegeben. Bun hat es gekauft und behalten. Beides im selben Monat.

Und Bun ist kein Einzelfall. OpenAI kündigte am 19. März 2026 an, Astral zu übernehmen — die Leute hinter `uv` und `ruff` — für das Codex-Team; abgeschlossen ist dieser Deal, Stand heute, noch nicht. Cloudflare übernahm am 4. Juni 2026 VoidZero, die Firma hinter Vite. Dasselbe Muster in drei Ökosystemen innerhalb von sechs Monaten.

## Claude Code aufgeschraubt

Hier wird es konkret. Alle folgenden Zahlen habe ich am **31. August 2026** an **Claude Code 2.1.251, Linux x64** gemessen. Sie gelten ausschließlich für diese Version und diese Plattform — Claude Code aktualisiert sich im Hintergrund selbst, und in einer Woche stimmt hier vermutlich keine einzige Byte-Angabe mehr.

Die Datei unter `~/.local/share/claude/versions/2.1.251` ist ein ELF-Binary mit **214.326.616 Bytes** (SHA-256 `fd5f10ff…61f7`). Außer der C-Standardbibliothek und dem dynamischen Linker — libc, libm, libpthread, librt, libdl, ld-linux — braucht sie keine externe Abhängigkeit. Kein Node, kein `node_modules`. Zum Vergleich auf derselben Maschine: `/usr/bin/node` ist 126.458.664 Bytes groß.

Wie sich die 214 MB verteilen, ist schon die halbe Geschichte: `.text` belegt 60.614.268 Bytes (28,3 %), `.rodata` 23.958.180 Bytes (11,2 %) — und eine Sektion namens `.bun` **127.166.362 Bytes, also 59,3 % der ganzen Datei.**

Der bekannteste Bun-Marker ist der Trailer `\n---- Bun! ----\n`:

```bash
grep -abo -- '---- Bun! ----' ~/.local/share/claude/versions/2.1.251
```

Das liefert zwei Treffer, bei Byte 4.095.681 und 214.267.787. **Nur der zweite ist ein Beweis.** Der erste liegt im `.rodata`-Stringpool zwischen gewöhnlichen Literalen wie `UnknownFormatCode` und `import.meta.main` — das ist die einkompilierte Kopie der Konstante, nicht ihre Verwendung. Wer „der Marker steht zweimal drin" als doppelte Bestätigung liest, macht aus einem sauberen Beleg ein angreifbares Argument.

Der eigentliche Beweis steckt in der Sektionstabelle:

```bash
readelf -S -W ~/.local/share/claude/versions/2.1.251 | grep '\.bun'
# [29] .bun PROGBITS 0000000005511000 5311000 794679a 00 WA 0 0 16384
```

Es gibt eine ELF-Sektion namens `.bun`. Sie beginnt bei Datei-Offset 87.101.440, ist 127.166.362 Bytes groß — und endet damit exakt bei Byte 214.267.802. Das ist genau das Byte, an dem der 16 Byte lange Trailer endet. In Buns Quelltext steht dazu `const TRAILER: &[u8] = b"\n---- Bun! ----\n";` und im Linux-Zweig `elf_file.write_bun_section(bytes)`.

Die 32 Bytes vor dem Trailer sind Buns `Offsets`-Struct, und es geht byte-genau auf: `byte_count` 127.166.306 plus 8 Bytes Padding plus 32 Bytes Struct plus 16 Bytes Trailer ergibt exakt die Sektionsgröße. Aus dem Struct lässt sich die Modultabelle lesen — 102.492 Bytes, geteilt durch 52 Bytes je Satz, ergibt **exakt 1.971 Module**. Einstiegspunkt Nummer 5 heißt `/$bunfs/root/cli` und stammt laut Bytecode-Herkunftspfad aus `/$bunfs/root/src/entrypoints/cli.js`.

**1.792 dieser 1.971 Module (90,9 %) tragen vorkompilierten JavaScriptCore-Bytecode**, zusammen 76.296.752 Bytes. Sourcemaps sind keine enthalten, und das Flag für Cross-Compile-Bytecode ist nicht gesetzt — der Build lief also mit `--bytecode` und nativ auf Linux x64.

Vier weitere Funde, die ich interessant fand:

**Die Engine ist JavaScriptCore, nicht V8.** Gezählt mit `grep -a -o … | wc -l`: `JSC::` kommt 2.613-mal vor, `JavaScriptCore` 163-mal, `V8 JavaScript` null-mal. Der einzige `v8::internal`-Treffer ist ein WebKit-Symbolname mitten in einem JSC-Symbolblock. (Die Zählmethode gehört dazu — je nachdem, ob du Vorkommen oder Zeilen zählst, bekommst du deutlich andere Werte.)

**Die eingebettete Bun-Version gibt es öffentlich nicht.** Im Binary steht zweimal `bun-v1.4.1` — beide Male in Buns eigenem Selbst-Upgrade-Pfad, samt Download-URL und einer 40-stelligen Revision. Das GitHub-Tag `bun-v1.4.1` liefert 404, die eingebettete Download-URL liefert 404, der Commit-Hash lässt sich nicht auflösen, und npm kennt als neuestes `bun@1.4.0`. Der ehrlichste Beleg steht direkt daneben im Binary: „Welcome to Bun's latest canary build!" Es ist ein Vorabstand, kein Release.

**Nachprüfen lässt sich das zur Laufzeit nicht.** Bun bietet normalerweise eine Hintertür: `BUN_BE_BUN=1` lässt eine Standalone-Executable sich wie die `bun`-CLI verhalten. In Anthropics Build fehlt dieser String vollständig — der Aufruf gibt brav `2.1.251 (Claude Code)` aus.

**Das npm-Paket liefert exakt dasselbe Binary.** Der SHA-256 meiner lokalen Datei ist byte-identisch mit dem entpackten `package/claude` aus `@anthropic-ai/claude-code-linux-x64@2.1.251` und mit der Prüfsumme im offiziellen Release-Manifest. Das deckt sich mit der Doku: „The npm package installs the same native binary as the standalone installer […] The installed `claude` binary does not itself invoke Node."

Und eine Größenentwicklung, die ich hübsch finde — laut den offiziellen Manifesten schrumpfte das Linux-x64-Binary innerhalb von acht Versionen um 163 Megabyte:

| Version | Größe (Bytes) |
|---|---|
| 2.1.243 | 377.568.472 |
| 2.1.250 | 223.604.056 |
| 2.1.251 | 214.326.616 |

### Die Zahl, die ich fast falsch geschrieben hätte

Mein erster Messversuch ergab: `claude --version` läuft in 0,04 bis 0,05 Sekunden durch, `node -e ''` braucht 0,12 bis 0,15. Faktor 3, schöne Zahl, ab in den Artikel.

Beide Werte waren falsch, und der Fehler lag an der Uhr. **Unter WSL2 springt `gettimeofday` rückwärts** — eine saubere Messschleife lieferte mir daraufhin sogar negative Laufzeiten. Erst mit `clock_gettime(CLOCK_MONOTONIC)`, 50 Durchläufen und warmem Page-Cache wurden die Werte stabil. Wenn du auf dieser Plattform mit `time` oder `date +%s%N` misst, misst du unter Umständen Müll.

Was dabei herauskam, auf einem Ryzen 5 3500U unter WSL2, Median aus 50 Läufen:

| Aufruf | Median | max. RSS |
|---|---|---|
| `/bin/true` (fork+exec-Boden) | 2,1 ms | — |
| `node --version` | 7,8 ms | — |
| `claude --version` | **16,8 ms** | 35,6 MB |
| `node -e ''` | **43,6 ms** | 43,0 MB |
| `claude --help` | **567,7 ms** | 160,5 MB |

Die letzte Zeile ist die wichtige. Dieselbe Binary, derselbe Prozess — **Faktor 34.** `--version` ist ein Schnellpfad, der das eingebettete Bundle gar nicht lädt. Wer aus 17 Millisekunden „Claude Code startet in 17 ms" macht, erzählt Unsinn. Die belastbare Zahl für den echten Sessionstart kommt aus Anthropics Produktionstelemetrie und steht im Bun-Blog: **517 ms auf 464 ms, Linux p50**, beim Wechsel von Claude Code 2.1.179 auf 2.1.181. Zehn Prozent schneller durch den Rust-Port. Sumners Kommentar: „barely anyone noticed. Boring is good."

Trotzdem sagt die Tabelle etwas. `node -e ''` ist Nodes absolute Untergrenze — V8 hochfahren, leeres Skript, fertig. `claude --version` tut strikt *mehr* und ist dabei 2,6-mal schneller. Die Unfairness des Vergleichs geht also zu Nodes Gunsten, und das Ergebnis überlebt sie.

Der eigentliche Grund dafür ist schöner als jede Startzeit: **Die 214 MB werden nicht gelesen, sie werden gemappt.** `claude --version` verursacht 1.787 Minor Page Faults, fasst also rund 7 MB tatsächlich an; `claude --help` kommt auf 19.555, rund 78 MB. Der Modulgraph ist in 1.790 einzeln nachladbare `chunk-*.js` zerlegt, und Bun holt gezielt die Seiten des Startpfads vor. Eine 214-MB-Datei, von der beim Start drei Prozent angefasst werden — das ist die Erklärung, nicht der schiefe Node-Vergleich.

Genau solche selbst gemessenen Zahlen fühlen sich sicher an und werden deshalb nicht geprüft. Mir ist das bei einem früheren Artikel schon einmal passiert, und ich [schreibe seitdem jede eigene Messung mit in den Widerlegungsauftrag](https://www.jpkc.com/db/blog/faktentreue-review/) — diese Tabelle ist der Grund, warum sich das lohnt.

Was ich guten Gewissens sagen kann: Claude Code braucht keine Node-Installation und kein `node_modules` — die 1.798 JavaScript-Bündel liegen in der Datei, nicht auf der Platte, und ein Aufruf mit `env -i`, also ohne jede Umgebungsvariable, läuft unverändert durch. (Dass dabei kein `PATH` nötig ist, beweist übrigens nichts: Ein absolut aufgerufenes ELF-Binary braucht nie einen.) Die Binary trägt die vollständige Struktur einer mit `bun build --compile` erzeugten Standalone-Executable. Was ich **nicht** sagen kann: dass Anthropic diesen Befehl benutzt. Das sagt keine Primärquelle. Belegt sind „ships as a Bun executable" (Sumner) und „the bundled Bun runtime" (Changelog) — der Rest ist meine Herleitung aus der ELF-Struktur, und die kennzeichne ich als solche.

## Der Rewrite, der in elf Tagen passierte

Zwischen dem 3. und 14. Mai 2026 wurde Bun von Zig nach Rust portiert. Nicht von einem Team über ein Jahr, sondern von rund 50 dynamischen Claude-Code-Workflows, in der Spitze etwa **64 parallelen Claude-Instanzen** in vier getrennten Worktrees. Am 14. Mai landete das Ergebnis im Main-Branch.

Die Zahlen aus Sumners eigenem Bericht: 535.496 Zeilen Zig portiert, rund 780.000 Zeilen Rust dabei entstanden, etwa 13.000 `unsafe`-Vorkommen (rund 4 Prozent, davon 78 Prozent einzeilige Blöcke), API-Kosten von ungefähr **165.000 US-Dollar**, 19 bekannte Regressionen — alle behoben. Das Review-Verfahren war adversarisch mit getrennten Kontextfenstern: ein Implementer, mindestens zwei Reviewer, keine Rollenvermischung. „The reviewer's only job: find bugs & reasons why the code does not work."

Sumner legt in demselben Beitrag offen, dass Bun zu Anthropic gehört und dass er für einen großen Teil der Arbeit eine Vorabversion von Claude Fable 5 benutzt hat.

Die Kritik kam prominent. Zig-Erfinder Andrew Kelley nannte das Ergebnis „1 million lines of unreviewed slop" und stellte die Frage, ob eine Testsuite, die für Zig-Code nicht ausreicht, plötzlich für eine Million ungeprüfte Zeilen ausreichen soll. Zwei Dinge gehören dazu, wenn du ihn zitierst: Kelley ist **nicht** gegen die Portierung nach Rust — „When Jarred announced the Rust rewrite, we were ecstatic." Und er datiert seine Kritik ausdrücklich vor die KI-Nutzung: Jarred „was already writing slop well before he had access to LLMs". Er kritisiert das Ausliefern ungeprüften Codes, nicht den Sprachwechsel.

Eine Kausalkette, die naheliegt und trotzdem falsch ist: Zigs strikte No-LLM-Policy steht **seit dem 22. November 2025** im Code of Conduct — zehn Tage *vor* der Anthropic-Übernahme. Sie ist keine Reaktion auf Bun.

## Was Bun 1.4 bringt — und was nicht

Bun 1.4 erschien am **20. August 2026**. Stand heute gibt es kein Patch-Release; `latest` auf npm ist 1.4.0.

Bevor du irgendeine Zahl aus diesem Release-Post übernimmst, musst du eine Eigenart kennen, über die ich bei der Recherche mehrfach gestolpert bin: **Bun-Major-Posts sind kumulative Rückblicke auf alles seit dem letzten Major, keine Listen dessen, was in `x.y.0` neu ist.** Der Post sagt das selbst („everything we've shipped since Bun 1.3.0"), und jeder Abschnitt trägt ein Versionsbadge. Ein guter Teil dessen, was in der Berichterstattung als „Bun 1.4 bringt X" auftaucht, kam in Wahrheit in 1.3.x:

| Feature | Tatsächlich seit |
|---|---|
| `Bun.Image` (sharp-Ersatz) | 1.3.14 |
| `Bun.WebView` (Browser-Automatisierung) | 1.3.12 |
| `bun test --parallel` / `--isolate` / `--shard` | 1.3.13 |
| `nativeDependencies`, `ignoreScripts` in `package.json` | 1.3.2 |
| Execute-only-Binaries auf Linux | 1.3.12 |
| glibc-Minimum auf 2.17 | 1.3.13 |

Wirklich neu in 1.4 sind unter anderem der Rust-Port selbst, `bun test --timings`, `bun audit fix`, `bun pm diff`, `bun dedupe`, `bun prune`, `bun pm licenses`, der eingebaute React Compiler und die experimentellen Android-Builds.

Dieselbe Vorsicht gilt für die Schlagzeilenzahlen. „+1.517 Node.js-Tests", „über 2.900 Issues behoben", „5× weniger Idle-CPU", „bis zu 35 % weniger Speicher", „50 % schnellerer Linux-Start" — das sind **Werte für die Spanne 1.3.0 bis 1.4.0**, also rund elf Monate Arbeit, nicht Ergebnisse des Rust-Rewrites. Der Rust-Post beziffert den Anteil der Portierung selbst deutlich nüchterner: 2 bis 5 Prozent Tempo.

Und im Detail wird es noch nüchterner. Die 5× weniger Idle-CPU gelten laut Fließtext „for a small 'hello world' app"; für eine echte Anwendung nennt derselbe Absatz das Doppelte statt das Fünffache — nämlich Claude Code, dessen Produktions-CPU von p99 24 % auf 10 % und p50 5,8 % auf 2,5 % fiel. Die 35 Prozent Speicherersparnis stehen nur im Intro und werden von keiner Tabelle im Post gestützt; die HTTP-Server-Tabelle nennt 13 bis 48 Prozent.

Beim Start lohnt sich das genaue Hinsehen, weil zwei Zahlen direkt untereinander stehen: **Bun 1.4 startet unter Linux doppelt so schnell wie Bun 1.3.14** (5,1 ms gegen 10,9 ms) und **rund fünfmal so schnell wie Node.js 26** (27,2 ms). „Bun 1.4 startet doppelt so schnell wie Node" wäre falsch, „fünfmal so schnell wie Node" ist richtig.

Sämtliche dieser Zahlen sind Herstellerbenchmarks aus Buns eigenem Repository. Unabhängige, methodisch saubere Fremdmessungen zu Bun 1.4 habe ich nicht gefunden — die TechEmpower-Benchmarks wurden im März 2026 eingestellt, und was sonst kursiert, ist überwiegend SEO-Content ohne nachvollziehbare Methodik. Dazu kommt eine Interessenkette, die offengelegt gehört: Anthropic besitzt Bun, das Bun-Team arbeitet bei Anthropic, der Rewrite entstand mit einem Anthropic-Vorabmodell, und der vorzeigbarste Erfolgsbeleg stammt aus Anthropics eigenem Produkt. Der Claude-Code-Changelog ist deshalb **keine** unabhängige Bestätigung, auch wenn er sich wie eine liest.

Ein Befund, der die Marketing-Erzählung ganz gut relativiert: Vor 1.4 war Bun bei regex-lastiger Arbeit dramatisch *langsamer* als Node. Das Paket `isbot` brauchte in Bun 1.3 218 Mikrosekunden pro Aufruf, Node 26 nur 1,47. `marked.parse()` auf 80 KB Markdown fiel von 912 auf rund 6 Millisekunden. Für einen Static-Site-Generator, der im Kern Markdown parst, wäre Bun bis Mai 2026 also potenziell die schlechtere Wahl gewesen.

## Was das für dich als Entwickler heißt

Der All-in-one-Anspruch ist real: eine abhängigkeitsfreie Binary mit Runtime, npm-kompatiblem Paketmanager, Jest-kompatiblem Test-Runner und Bundler. TypeScript und JSX laufen ohne Build-Schritt. Bun 1.4 zieht 15 typische npm-Abhängigkeiten in die Binary — sharp, puppeteer, marked, node-cron, node-pty, concurrently, npm-run-all, tar und weitere.

Für mich als jemanden, der [seit sechs Jahren statische Seiten mit Eleventy baut](https://www.jpkc.com/db/blog/warum-11ty/), ist der realistischste Nutzen aber gar nicht der Runtime-Wechsel, sondern **Bun als reiner Paketmanager**. Das funktioniert, weil `bun install` laut Doku „a Node.js compatible node_modules folder" erzeugt, „without using Bun's runtime", und weil `bun run` Shebangs respektiert: Eleventys `cmd.cjs` beginnt mit `#!/usr/bin/env node` und läuft damit weiter unter Node — die Bun-Runtime erzwingst du erst mit `--bun`.

Der Umstieg ist trivial: `bun install` migriert `package-lock.json`, `yarn.lock` und `pnpm-lock.yaml` automatisch nach `bun.lock` und lässt das Original stehen. Genau das ist allerdings auch die Falle — nichts hält beide Lockfiles synchron. Wer abwechselnd `bun install` und `npm ci` benutzt, installiert aus zwei unabhängigen Auflösungen.

Was gegen einen vollen Umstieg spricht, ist konkret benennbar:

- **Eleventy dokumentiert Bun nirgends.** Die Runtime-Seite nennt Node.js 18+ und sagt „Eleventy runs great on Deno"; Bun kommt nicht vor. Umgekehrt listen Buns Ecosystem-Guides Astro, Next, Nuxt, Vite und SvelteKit — aber kein Eleventy. Das ist kein Ausschluss, aber es gibt auch keine Zusage.
- **`node --test` ist wackelig.** Bun besteht von Nodes eigener `test_runner`-Suite nur 28 von 81 Tests. Wenn deine Tests wie meine über `node --test` laufen, bist du außerhalb der sicheren Zone.
- **Bun ist nicht zu 100 % Node-kompatibel**, und sagt das selbst. `node:sea` fehlt ganz, `node:cluster` verteilt HTTP-Last nur unter Linux, `node:worker_threads` ignoriert `resourceLimits`, `bun:ffi` ist ausdrücklich experimentell.
- **`module.register` ist ein No-op.** ESM-Loader-Hooks greifen unter Bun schlicht nicht — ohne Fehlermeldung. `registerHooks` fehlt dagegen ganz und wirft. Ein stiller No-op ist das unangenehmere Fehlerbild.
- **Beim Hosting ist die Lage uneinheitlicher, als Bun es darstellt.** Vercel unterstützt die Bun-Runtime seit Oktober 2025 als Public Beta, Netlify erkennt ein Bun-Lockfile — Railways eigene Doku sagt dagegen „Railpack does not yet detect Bun projects automatically".

Ich habe Bun für diesen Artikel bewusst **nicht** auf meinem Arbeitsrechner installiert. Alles oben stammt aus Primärquellen; wo ich „das läuft" schreibe, meine ich „das ist dokumentiert", nicht „das habe ich in meinem Repository durchlaufen lassen".

## Sicherheit: der Teil, der mich am meisten beschäftigt

Ich habe [ausführlich über mein Setup gegen Supply-Chain-Angriffe geschrieben](https://www.jpkc.com/db/blog/nodejs-npm-absichern/) — Socket Firewall vor jedem Paket-Fetch, `ignore-scripts=true`, exakte Pins, `npm ci` statt `npm install`. Wie schlägt sich Bun in dieser Disziplin?

**Besser als npm, schlechter als das Marketing.** Die Doku sagt: „Because running arbitrary code is a security risk, Bun does not execute arbitrary lifecycle scripts by default." Der Haken steckt im Wort „arbitrary". Bun bringt eine eingebaute Allowlist mit — `src/install/default-trusted-dependencies.txt`, aktuell **exakt 367 Paketnamen**, darunter `sharp`, `esbuild`, `node-sass`, `puppeteer` und `electron`. Für die läuft `preinstall`, `install` und `postinstall` ohne Rückfrage.

Wie das schiefgeht, lässt sich an einem realen Fall zeigen: **`mbt` steht auf dieser Liste** — wegen seines legitimen `install`-Hooks. Und `mbt@1.2.48` war am 29. April 2026 eines der vier kompromittierten SAP-Pakete; der Angriff lief über einen zusätzlich eingefügten `preinstall`-Hook. Ein Standard-`bun install` hätte diesen Schadcode ausgeführt. Das `ignore-scripts=true` in meiner `.npmrc` hätte ihn geblockt.

Zwei Konfigurationsdetails, die leicht untergehen und beide wichtig sind:

1. **`trustedDependencies` ersetzt die Default-Liste, es erweitert sie nicht.** Wer `trustedDependencies: ["sharp"]` setzt, entzieht damit den anderen 366 Einträgen das Vertrauen. Das ist meistens gewollt — aber nur, wenn du es weißt. Der saubere Opt-out ohne Dauer-Flag ist `trustedDependencies: []`.
2. **Bun liest deine vorhandene `.npmrc`**, inklusive `ignore-scripts=true` und `save-exact=true`. Deine bestehende Härtung wirkt also weiter.

Beim Vergleich der Voreinstellungen liegt npm hinten, Bun in der Mitte, pnpm vorn: pnpm 10 deaktiviert `postinstall` in Dependencies komplett, pnpm 11 setzt zusätzlich eine Quarantäne von 1440 Minuten für frische Pakete. Bun kennt `minimumReleaseAge` seit 1.3, der Default ist aber `null` — also aus. Achtung bei einem Vergleich: Bun rechnet in **Sekunden**, pnpm in **Minuten**.

Zwei Dinge, die ich für erwähnenswert halte, weil sie in keiner Übersicht stehen:

**`bun audit` scheitert still.** Auf Bun 1.4.0 nachgemessen: `bun audit --severity=critical` erzeugt keinen Fehler und ändert nichts am Ergebnis — `bun audit --severity=bogusvalue` genauso wenig. Dasselbe gilt für `bun audit --ignore <CVE>`. Beide Formen stehen in offiziellen Bun-Release-Notes, die aktuelle CLI-Doku verlangt dagegen `--audit-level` und schreibt ausdrücklich, dass CVE-IDs nicht matchen. Wenn du eine dieser Zeilen aus der Doku in eine CI-Pipeline kopierst, bekommst du einen grün aussehenden Lauf ohne jede Filterwirkung.

**Und der bitterste Befund für einen Bun-Artikel:** Bun ist 2025 und 2026 dreimal als *Werkzeug der Angreifer* aufgetaucht. Bei Shai-Hulud 2.0 (November 2025, 796 kompromittierte Pakete) injizierte der Wurm `setup_bun.js` und `bun_environment.js` über einen `preinstall`-Hook — die Analyse von Datadog formuliert den Zweck unmissverständlich: „Install the Bun JavaScript runtime, likely to evade standard Node.js monitoring, and use it to run an obfuscated payload." Dasselbe Muster bei der SAP-Welle im April 2026 und beim keyv-Angriff im August 2026. Dass eine Runtime schneller startet und weniger Aufmerksamkeit erregt als Node, ist eben auch für die andere Seite ein Vorteil.

Zu Socket Firewall, dem Werkzeug in meinem eigenen Setup: Das README listet npm, yarn, pnpm, pip, uv und cargo — Bun steht nicht dabei, und das entsprechende Issue ist ohne dokumentierte Umsetzung geschlossen. Daraus zu schließen, `sfw` schütze Bun nicht, wäre allerdings falsch: In der Messung respektiert Bun 1.4.0 `HTTPS_PROXY` und akzeptiert die MITM-CA von Socket Firewall (`NODE_EXTRA_CA_CERTS` oder `SSL_CERT_FILE` genügt), und ohne die CA bricht der Install genau an der Firewall-Grenze ab. Die ehrliche Formulierung lautet: Es funktioniert, es ist nur nicht zugesagt.

Zuletzt eine Unbequemlichkeit, die ich nicht weglassen will. Der offizielle Installationsweg für Bun ist `curl -fsSL https://bun.com/install | bash` — ein ungeprüfter Shell-Pipe von einer Website, in einem Artikel, der ansonsten jeden Paket-Fetch durch eine Firewall leitet. Immerhin lässt sich die Version pinnen: `bash -s "bun-v1.4.0"`.

## Was mich beunruhigt

Drei Stränge, und sie sind unterschiedlich stark.

**Das Team.** Von den fünf Zusagen ist eine unter Druck geraten. RedMonk hat im Juni 2026 gemessen, dass von rund sieben identifizierbaren Oven-Beschäftigten vor der Übernahme mindestens vier nicht mehr beitragen; ein weiterer aktiver Committer ging von 745 auf einen Commit zurück. Wichtig ist, wie vorsichtig die Quelle selbst formuliert: „The team, on the other hand, *appears* to have gone its separate ways" — und ausdrücklich: „There are many potential reasons for this mini diaspora, and they may have little if anything to do with the project, AI, the acquisition or any of the above." Weder Anthropic noch Bun haben je Zahlen zum Personalübergang genannt. „Anthropic hat das Team zerschlagen" hat keinerlei Grundlage.

**Die Autorenschaft.** Über 80 Prozent Bot-Commits klingt dramatisch, und die Kausalität wird dabei fast immer falsch erzählt. Der Kipppunkt lag laut RedMonk **im August 2025** — vier Monate *vor* der Übernahme. Sumner bestätigt das: „We haven't been typing code ourselves for many months now. Even pre-acquisition this was pretty much accurate." Was zeitlich tatsächlich an die Übernahme gekoppelt ist, ist etwas anderes: der Einbruch der **externen** Beiträge. Der Bot `robobun` ist heute mit 2.587 Commits zweitgrößter Contributor — hinter Jarred Sumner mit über 8.500.

**Die Governance.** Das ist der Punkt, den ich am belastbarsten finde, weil er ohne jede Spekulation auskommt. Es gibt für Bun keine Stiftung, kein neutrales Governance-Modell, keine Trademark-Regelung und keine Rückfallzusage für den Fall, dass Anthropic die Richtung ändert. Das Repository liegt weiterhin unter `oven-sh`, das Copyright lautet inzwischen „© 2026 Anthropic, PBC". Zum Vergleich: Cloudflare hat bei VoidZero zusätzlich eine Million Dollar für einen von Cloudflare *und* VoidZero unabhängigen Vite-Fonds zugesagt. RedMonks Kernsatz dazu trifft es: Unternehmen setzen auf Stiftungs-Software nicht, weil sie schneller entsteht, sondern weil sie nicht einem einzelnen Anbieter gehört.

Als Vergleichsfälle taugen fünf belegte Übernahmen, und ihre Bandbreite ist genau der Punkt:

| Fall | Was passierte |
|---|---|
| npm → GitHub/Microsoft (2020) | Zusagen gehalten |
| MySQL → Oracle (2009/10) | Fork MariaDB durch den Gründer |
| Docker Desktop (2021) | Für große Firmen kostenpflichtig |
| Terraform → HashiCorp/IBM (2023–25) | MPL → BUSL, Fork OpenTofu |
| Redis (2024/25) | BSD → SSPL, Fork Valkey, später AGPLv3 als zusätzliche Option |

Von „nichts passiert" bis „Lizenzwechsel und Spaltung" ist alles vertreten. Ein Fork von Bun ist bis heute weder passiert noch nötig geworden.

## Was dagegen spricht, sich zu sorgen

MIT bleibt MIT. Das Fork-Recht besteht unabhängig davon, wem das Repository gehört, und es ist die eigentliche Versicherung — Simon Willison bringt es auf „fork and move on". Anthropic hat im selben Monat, in dem es Bun kaufte, MCP an eine Stiftung abgegeben; das Unternehmen kennt den Unterschied also. Und der strukturelle Anreiz ist echt und öffentlich nachprüfbar: Wenn Bun kaputtgeht, geht Claude Code kaputt.

Der ehrlichste Kommentar dazu stammt aus dem Lager der Skeptiker. William Johnston, der für sich entschieden hat, seine Projekte von Bun auf pnpm umzustellen, schreibt trotzdem: „Bun is not bad. Bun is excellent." Und über Sumners Anreiz-Argument: „In December, that sounded reassuring … I still think that argument has merit, but now cracks are showing." Genau so würde ich es auch formulieren.

## Mein Fazit

Ich bin mit einer Überraschung in diese Recherche gegangen — „Claude Code ist ein Bun-Build?" — und mit drei Erkenntnissen herausgekommen, die alle nichts mit der Schlagzeile zu tun haben.

**Erstens:** Der Beleg war die ganze Zeit auf meiner Festplatte. Eine ELF-Sektion, ein 16-Byte-Trailer und ein Offsets-Struct, das byte-genau aufgeht — 1.971 Module, 90,9 Prozent davon als vorkompilierter JavaScriptCore-Bytecode. Das ist die Art Nachweis, die mir lieber ist als jede Pressemitteilung, weil du sie selbst nachvollziehen kannst.

**Zweitens:** Die interessanteste Zahl dieses Artikels ist die, die ich fast falsch hingeschrieben hätte. 17 Millisekunden gegen 568 Millisekunden — dieselbe Binary, derselbe Prozess, Faktor 34. Beides sind korrekte Messungen von zwei völlig verschiedenen Dingen, und dazwischen liegt der Unterschied zwischen einer Versionsabfrage und einem Programmstart.

**Drittens:** Die eigentliche Nachricht steht nicht im Release-Post, sondern in seiner Bauform. Ein Runtime-Hersteller schreibt eine halbe Million Zeilen Systemcode in elf Tagen um, für 165.000 Dollar API-Kosten, mit adversarischem Review zwischen getrennten Kontextfenstern — und der Erfinder der abgelösten Sprache nennt das Ergebnis „unreviewed slop". Beide Sätze stimmen. Was daraus folgt, weiß, glaube ich, gerade niemand.

Was ich konkret mache: Bun kommt bei mir vorerst nicht in den Build dieser Seite — `node --test` ist mir dafür zu wichtig, und Eleventy sagt zu Bun schlicht nichts. Was ich mir dagegen vormerke, ist `bun pm diff`: ein Befehl, der dir vor einem Update zeigt, welche neuen Install-Skripte und welche neuen `child_process`-, `fs`- oder `net`-Importe dazukommen. Das ist genau die Frage, die ich mir bei jedem Dependency-Update stelle, und ich kenne kein npm-Äquivalent dafür.

Und die Runtime, die in meiner Claude-Code-Binary wohnt, bleibt sowieso da. Ich weiß jetzt nur, wo sie sitzt: ab Byte 87.101.440.

## Häufige Fragen

**Gehört Bun jetzt Anthropic?**
Ja. Angekündigt am 2. Dezember 2025. Übernommen wurde Oven, die Firma hinter Bun. Der Kaufpreis wurde nie genannt.

**Bleibt Bun Open Source?**
Ja. Beide Seiten haben die MIT-Lizenz zugesagt, und die `LICENSE.md` beginnt Stand 31. August 2026 unverändert mit „Bun itself is MIT-licensed". Dass GitHub „NOASSERTION" anzeigt, liegt am statisch gelinkten JavaScriptCore unter LGPL-2, nicht an einem Lizenzwechsel.

**Ist Claude Code wirklich ein Bun-Build?**
Die Binary trägt die vollständige Struktur einer Bun-Standalone-Executable: eine `.bun`-ELF-Sektion, den Trailer `---- Bun! ----` an ihrem Ende, ein passendes Offsets-Struct und 1.971 eingebettete Module. Sumner schreibt „Claude Code ships as a Bun executable", Anthropics Changelog spricht von der „bundled Bun runtime". Dass konkret `bun build --compile` benutzt wird, sagt keine Primärquelle — das ist meine Herleitung aus der Struktur.

**Brauche ich Node.js, um Claude Code zu benutzen?**
Nein. Das Binary startet ohne Node und ohne PATH. Die offizielle Doku sagt: „The installed `claude` binary does not itself invoke Node." Das npm-Paket liefert dasselbe native Binary wie der Standalone-Installer.

**Ist `bun install` sicherer als `npm install`?**
In der Voreinstellung ja, aber nicht vollständig. Bun führt Lifecycle-Skripte nur für Pakete auf einer eingebauten Allowlist mit 367 Namen aus. Das ist besser als npms Default, aber schlechter als `ignore-scripts=true` oder pnpms Verhalten — der `mbt`-Fall vom April 2026 zeigt genau die Lücke.

**Kann ich Bun nur als Paketmanager nutzen und weiter mit Node laufen?**
Ja. `bun install` erzeugt laut Doku ein Node-kompatibles `node_modules`-Verzeichnis „without using Bun's runtime", und `bun run` respektiert Shebangs. Die Bun-Runtime erzwingst du erst mit `--bun`.

**Läuft Eleventy unter Bun?**
Das kann ich dir nicht belegen. Eleventy nennt in seiner Runtime-Doku nur Node.js 18+ und Deno, Buns Ecosystem-Guides nennen Eleventy nicht, und ich habe es nicht getestet. Als reinen Paketmanager einzusetzen ist der Weg mit der geringsten Angriffsfläche.

**Ist Bun 1.4 wirklich fünfmal schneller beim Start?**
Gegenüber Node.js 26 unter Linux: ja, 5,1 gegen 27,2 Millisekunden. Gegenüber Bun 1.3.14: Faktor 2. Beide Zahlen stehen in derselben Tabelle des Herstellers, und es gibt zu Bun 1.4 keine unabhängige Nachmessung.

## Weiterlesen

- [Claude Code richtig konfigurieren](https://www.jpkc.com/db/blog/claude-code-konfiguration/) — was du mit dem Werkzeug machst, dessen Innenleben dieser Artikel aufschraubt.
- [Claude Code im Container](https://www.jpkc.com/db/blog/claude-code-container/) — Isolation von außen, für die Runtime, die sie von innen nicht mitbringt.
- [Sicheres Arbeiten mit Node.js und npm](https://www.jpkc.com/db/blog/nodejs-npm-absichern/) — das Setup, gegen das ich Buns Voreinstellungen hier gemessen habe.
- [Wer prüft den Prüfer? Adversarische Faktentreue für KI-Texte](https://www.jpkc.com/db/blog/faktentreue-review/) — warum die 0,01-Sekunden-Zahl es nicht in die Einleitung geschafft hat.
- [Warum 11ty: sechs Jahre statisch](https://www.jpkc.com/db/blog/warum-11ty/) — der Stack, in den Bun vorerst nicht einzieht.
- [„Bun is joining Anthropic"](https://bun.com/blog/bun-joins-anthropic) — Jarred Sumners Ankündigung vom 2. Dezember 2025, Quelle der meisten Zitate hier.
- [Anthropic: „Anthropic acquires Bun"](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) — die Gegenseite, mit dem Krieger-Zitat und der Run-Rate-Zahl.
- [„Rewriting Bun in Rust"](https://bun.com/blog/bun-in-rust) — die vollständigen Zahlen zum Elf-Tage-Rewrite, inklusive Kostenangabe und Disclosure.
- [Bun 1.4 Release-Notes](https://bun.com/blog/bun-v1.4) — mit Versionsbadges an jedem Abschnitt; lies sie mit.
- [RedMonk: „What Bun Can Tell Us About AI, Open Source and Anthropic"](https://redmonk.com/sogrady/2026/06/04/bun-two-lessons/) — die datengestützte Governance-Analyse von Stephen O'Grady.
- [heise online: Anthropic übernimmt Bun](https://www.heise.de/news/Open-Source-Toolkit-KI-Unternehmen-Anthropic-uebernimmt-Bun-11102360.html) — die deutschsprachige Meldung vom 4. Dezember 2025.
- [heise online: Claude schreibt Bun-Codebasis in Rust neu](https://www.heise.de/news/KI-Portierung-Claude-schreibt-Bun-Codebasis-in-Rust-neu-9787350.html) — Jan Mahn zum Merge vom 14. Mai 2026.