Am 7. Oktober 2026 veröffentlichte Theo Browne das Repository ts-rust zusammen mit dem zugehörigen npm-Paket tsc-rs als Open Source. Es handelt sich um ein gewaltiges Migrationsprojekt: den nativen TypeScript-7-Compiler von Microsoft samt Typprüfer und LSP (Language Server Protocol), der zuvor in Go neu implementiert worden war, vollständig nach Rust zu portieren. Das Vorhaben übernimmt die Algorithmen, Verhaltensweisen, Befehlszeilenparameter sowie APIs des Upstream-Projekts exakt und friert den Codestand verbindlich auf die Version TypeScript 7.1.0-dev vom 29. September 2026 (Revision 673a5f17d713) ein. Bei identischer Aufgabenstellung lieferten zwei führende Modellfamilien Ergebnisse ab, die sich bei Zeitaufwand und Kosten um eine ganze Größenordnung unterschieden.
400.000 Dollar API-Listenpreis gegen 24.000 Dollar tatsächliche Abonnementkosten
Der erste Versuch des Autors stützte sich auf die Modelle GPT-5.6 Sol und GPT 6 Astra. Über mehrere Monate hinweg verbrauchten diese Modelle in autonomen /goal-Schleifen Tokens im rechnerischen Gegenwert von über 400.000 Dollar nach regulären API-Preisen. Dabei generierten sie 1,3 Millionen Zeilen Rust-Code, blieben jedoch bei einer Kompatibilitätsquote von rund 84 % dauerhaft stecken. Nach dem Wechsel zu Claude Opus 5.5 war die gesamte Portierung innerhalb von zwei Wochen abgeschlossen. Auf X zog der Autor folgendes Fazit: „Codex-Tokens im Wert von rund 400.000 Dollar verbrannt und nichts erreicht; Opus-Tokens für rund 20.000 Dollar verbrannt und die Sache in zwei Wochen erledigt.“
Die genannten 400.000 Dollar spiegeln lediglich den Nennwert zu Listenpreisen der API wider. Die tatsächlichen Ausgaben für Opus beliefen sich dank hochgestufter Abonnementkontingente auf rund 24.047 Dollar. Dieser Betrag entspricht etwa 925 % bis 983 % des wöchentlichen Kontingents eines 200-Dollar-Plans. Bei extrem langen Softwarevorhaben liegt der entscheidende Engpass darin, ob ein Modell den Kontext kohärent halten kann und ob es den Mut aufbringt, unbrauchbare Vorarbeiten komplett zu verwerfen. Bei einer Abrechnung nach regulären API-Sätzen wäre die finanzielle Reichweite eines kleinen Entwicklerteams vorzeitig erschöpft gewesen – weshalb dieses Projekt nur im Rahmen pauschaler Abonnements wirtschaftlich funktionierte.
Abb.: Vergleich von Token-Kosten und Zeitaufwand beider Portierungsversuche. Quelle: @theo / X
1,3 Millionen Zeilen Code verworfen: Der radikale Neuanfang als Architekturentscheidung
Nach dem Wechsel zu Opus 5.5 versuchte das Modell keineswegs, die von Astra hinterlassenen 1,3 Millionen Zeilen Code mühsam zusammenzuflicken. Es stufte die bestehende Codebasis als unbrauchbar ein, legte ein neues Crate an und begann von Grund auf neu zu schreiben. Bereits nach zehn Stunden legte es eine lauffähige v0-Version vor, die den mühsamen, wochenlangen Stillstand des Vorgängermodells mit einem Schlag hinter sich ließ.
Unter der Last von Hunderttausenden Tokens Kontext entscheidet die Entschlossenheit eines Modells, minderwertigen Code radikal zu entsorgen und neu anzusetzen, über Leben und Tod eines Langzeitprojekts. Bei langwierigen Codegenerierungsaufgaben führt das endlose Anhäufen von Patches unweigerlich zu unberechenbaren Kaskadenfehlern. Tabula rasa zu machen erweist sich als wesentlich effizienter, als fehlerhaften Code weiterzuschleppen – und setzt sich über die menschliche Neigung hinweg, an versunkenen Kosten festzuhalten.
181.711 Upstream-Tests als uneinnehmbare Verteidigungslinie
In den Warnhinweisen des MIT-lizenzierten Repositorys – das rasch 572 Sterne und 5.963 Commits verzeichnete – hinterließ der Entwickler einen bemerkenswerten Satz: „Ich habe keine einzige Zeile dieses Codes gelesen.“ Der eigentliche Inhalt der README unterhalb der Trennlinie wurde sogar vollständig von Claude Code verfasst. Dass ein Entwickler ein derart massives Softwareprojekt ungeprüft veröffentlicht, verdankt sich ausschließlich der automatisierten Verifikation: Sämtliche 181.711 aus der Go-Version übernommenen Tests laufen fehlerfrei durch.
In den Testläufen stimmten die Diagnosemeldungen für TanStack Query core und Hono Punkt für Punkt mit denen des Go-Compilers überein. Auch die Antworten des Language Servers und der API deckten sich auf den Orakel-Testsuiten vollständig mit dem Upstream. Bei Tests an 120 Open-Source-Repositorys wich die CLI-Ausgabe nur bei wenigen bekannten Grenzfällen ab. Die Vertrauenswürdigkeit gigantischer LLM-Codebasen wird allein durch die Abwehrlinie robuster Upstream-Testsuiten gesichert; das klassische manuelle Code-Review durch den Menschen wurde aus der Vertrauenskette gestrichen.
Abb.: Social-Preview-Card des ts-rust-Repositorys. Quelle: GitHub
Bun bleibt ungeschlagen, doch integrierte Effect-Diagnostik verschafft Vorsprung
Mithilfe des Benchmarking-Tools hyperfine ermittelte der Autor auf einem Apple M4 Pro (Median aus fünf Durchläufen) ein klares Leistungsprofil. Bei der Typprüfung von sechs Open-Source-Projekten lag die Geschwindigkeit von tsc-rs im geometrischen Mittel um das 1,61-Fache über der von tsc 7. Beim 3,75 Millionen Zeilen umfassenden VS-Code-Projekt benötigte tsc 6 noch 54,56 Sekunden und tsc 7 6,84 Sekunden, während tsc-rs die Ausführungszeit auf 4,20 Sekunden drückte. Da die aktuellen Vorschaupakete noch ohne PGO- und BOLT-Optimierungen ausgeliefert werden, dürften finale Versionen noch schneller arbeiten. Allerdings absolvierte bun check von Bun den VS-Code-Test in gerade einmal 1,62 Sekunden und behauptet damit weiterhin die Spitzenposition.
Geht es jedoch um fachspezifische Diagnosen, spielt die Architekturzusammenführung ihre Trümpfe aus. Bei den kombinierten Tests der fünf Teilprojekte von T3 Code benötigte tsc-rs ohne Effect-Prüfungen 7,25 Sekunden (gegenüber 16,10 Sekunden bei tsc 7). Bei aktivierter Effect-Diagnostik (Fehlercodes 377xxx) lag die Laufzeit von tsc-rs bei 11,13 Sekunden – verglichen mit 21,07 Sekunden für tsc 7 in Kombination mit @effect/tsgo. Da die Effect-Prüfung fest in den primären Compiler-Durchlauf integriert wurde, entfällt der Overhead eines zweiten Analyse-Scans vollständig. Entwickler erhalten die integrierte Diagnosekette direkt über den Aufruf npm install -D tsc-rs.
Plattformgrenzen und Rechenzeitbilanz entfachen Grundsatzdebatte
Als frühes Experiment unterliegt tsc-rs derzeit noch engen Einsatzgrenzen. Unterstützt werden bislang ausschließlich statisch gelinkte Linux-x64- und macOS-arm64-Umgebungen; Windows und Linux-arm64 folgen erst später. Zu den bekannten Einschränkungen zählen TS6059-Fehler in bestimmten Monorepo-Setups (Meldung, dass Quelldateien außerhalb des rootDir liegen) sowie gelegentlich veraltete Zwischenstände bei tsc -b. Bemerkenswerterweise bildeten vier der ersten fünf gemeldeten GitHub-Issues lediglich das bestehende Verhalten des offiziellen TypeScript-Compilers nach. Wenn ein Migrationswerkzeug das Upstream-System bis ins kleinste Detail imitiert, werden auch dessen Unzulänglichkeiten unweigerlich als Produkteigenschaften verewigt.
In den Diskussionen auf Hacker News rückten die technischen Umsetzungsdetails schnell zugunsten grundsätzlicher Fragen in den Hintergrund. Manche Kommentatoren rechneten vor, dass man für 400.000 Dollar problemlos einen hochkarätigen Compiler-Entwickler für ein ganzes Jahr hätte einstellen können, anstatt das Kapital in Rechencluster zu pumpen. Andere hielten dagegen, dass 400.000 Dollar lediglich ein fiktiver Listenpreis seien und die reellen Kosten bei 24.000 Dollar lagen. Zudem gab es Zweifel daran, ob es vertretbar sei, ein millionenschweres KI-Projekt ungeprüft ins Netz zu stellen, während mancher die README schlicht als kalkulierte Werbekampagne für Claude Code einstufte. Wenn die finanzielle Hürde für Softwareentwicklung auf die Höhe monatlicher Abopreise sinkt, verlagert sich der Diskurs in der Softwaretechnik: Weg von der Frage, wie Code konstruiert wird, hin zur ökonomischen Abwägung zwischen Maschinenrechenzeit und menschlicher Arbeitsvergütung.
Weiterführende Links:
- Erklärung von Theo Browne auf X
- README des Repositorys pingdotgg/ts-rust
- Community-Diskussion über die KI-Portierung von TypeScript
