Die versteckten KI-Kosten von JavaScript-Frameworks

Der Agent hat elf Minuten damit verbracht, einen Migrationsleitfaden zu lesen, bevor er auch nur eine Zeile Code geschrieben hat. Nicht dein Agent – sondern der, auf den ein Kollege letzte Woche ein SvelteKit-Projekt angesetzt hat, mit demselben Prompt, den du eine Stunde zuvor für deine React-App verwendet hattest. Deiner war nach etwa acht Minuten und vier Millionen Tokens fertig. Seiner brauchte siebzehn Minuten und fast zehn Millionen, und ein großer Teil dieser Differenz war das Modell, das sich geduldig selbst eine Framework-Version beibrachte, die es beim Training nie gesehen hatte. Für diese Lücke gibt es inzwischen einen Namen: die KI-Kosten von JavaScript-Frameworks. Und dank eines wirklich ungewöhnlichen Schritts in unserer Branche – jemand hat tatsächlich gemessen, statt nur zu behaupten – haben wir endlich echte Zahlen dafür.

Nolan Lawson, der seit Jahren Frontend-Folklore durch echte Benchmarks ersetzt, hat kürzlich das Naheliegende getan, was sonst niemand gemacht hatte. Er hat eine kleine, aber nicht triviale Pokémon-App spezifiziert – Suche, Filter, Detailseiten, Daten aus der PokéAPI – und einen Coding-Agenten bauen lassen, und zwar auf zwölf verschiedene Arten: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono mit htmx, Gracile mit Lit und reines Vite ganz ohne UI-Framework. Jedes Framework bekam fünf unabhängige Durchläufe mit demselben Prompt, jeder Build wurde gegen eine Konformitätssuite geprüft, damit der Agent nicht schummeln konnte, und die Ergebnisse wurden nach Kosten, Zeit, Tokens und Lighthouse-Metriken bewertet. Es ist kein perfektes Experiment, und Lawson sagt das selbst. Aber es ist der erste ehrliche Versuch, den ich gesehen habe, einer Entscheidung ein Preisschild zu geben, die die meisten Teams rein aus dem Bauch heraus treffen.

Was der Benchmark tatsächlich gemessen hat

Das Setup war bewusst neutral. Der Agent bekam die Spezifikation, sollte die neueste Version des jeweiligen Frameworks verwenden und durfte seine Architektur selbst wählen – SSR oder CSR, ganz wie er wollte. Wo ein Framework einen offiziellen MCP-Server, ein Agent-Skill oder ein Plugin anbietet, wurde es bereitgestellt, damit niemand sich beschweren konnte, in den Trainingsdaten unterrepräsentiert zu sein. Die Konformitätstests liefen gegen den Accessibility Tree statt gegen das rohe DOM, was wichtig war, weil ein Kandidat über Shadow DOM rendert. Jedes Framework bekam fünf Durchläufe, und die Ergebnisse werden als Mediane angegeben – außer bei Angular, das zweimal gar keine testbare App hervorbrachte, weshalb einige seiner Zahlen aus nur drei Durchläufen stammen.

• Die Build-Kosten lagen im Median zwischen etwa 2,67 und 4,97 US-Dollar pro App – ein etwa doppelt so großer Abstand zwischen dem günstigsten und dem teuersten Framework.
• Der Tokenverbrauch erzählte dieselbe Geschichte, nur lauter: rund 4 Millionen Tokens bei den günstigsten Stacks, fast 10 Millionen bei den teuersten.
• Die Laufzeit folgte den Kosten eng, von etwa 8 Minuten am schnellen Ende bis 17 Minuten am langsamen Ende.
• SvelteKit, Gracile+Lit und Angular waren durchgehend die teuersten Builds. Astro und die Kombination Hono+htmx waren durchgehend günstig.
• Überraschenderweise schnitt der Vite-Build ohne Framework schlechter ab als mehrere echte Frameworks – etwas Struktur schlägt keine Struktur, selbst für eine Maschine.

Zwei Dollar pro Build klingen nach nichts. Für einen einzelnen Build ist es auch nichts. Aber agentische Entwicklung ist von Natur aus iterativ – niemand akzeptiert die erste Ausgabe. Multipliziere den Abstand mit Dutzenden Agenten-Sitzungen pro Entwickler und Woche, über ein Team und über ein Jahr, und aus einem Token-Multiplikator von 2 für deinen Stack wird ein echter Kostenposten. Noch wichtiger: Tokens sind ein Stellvertreter für etwas, das mich mehr interessiert als Geld, nämlich wie viel Trial-and-Error das Modell braucht, um korrekten Code in deinem Framework zu produzieren. Hohe Token-Zahlen bedeuten meist, dass der Agent verwirrt ist, Dokumentation erneut liest und Versuche wiederholt. Das ist ein Qualitätssignal im Kostenkleid.

Warum manche Frameworks Agenten teuer machen

Nach Jahren des Trainierens und Evaluierens von Modellen finde ich die Ergebnisse weniger rätselhaft, als sie auf den ersten Blick wirken. Drei Mechanismen erklären nahezu die gesamte Streuung, und keiner hat etwas damit zu tun, welches Framework im traditionellen Sinne „besser“ ist.

Dichte der Trainingsdaten ist Schicksal

Reacts größter Vorteil in der agentischen Ära ist nicht sein Programmiermodell – es ist, dass ein Jahrzehnt an Tutorials, GitHub-Repos und Stack-Overflow-Antworten seine Idiome in die Gewichte jedes Frontier-Modells verdichtet hat. Ein Agent, der React schreibt, erinnert sich größtenteils. Ein Agent, der Gracile schreibt, entdeckt größtenteils: In den Benchmark-Läufen griffen Agenten, die das Framework nicht kannten, darauf zurück, das Repository des Frameworks zu klonen oder dessen kompilierten Quellcode aus node_modules zu lesen. Das sind Tokens, die für Nachhilfe verbrannt werden, bevor überhaupt Nutzercode existiert. Dieselbe Dynamik verändert generell, wie Entwickler Wissen finden – ich habe darüber geschrieben, was mit dem Korpus des Entwicklerwissens passiert, während Stack Overflow verblasst, und der Framework-Aspekt ist ein scharfer Spezialfall: Unpopuläre Werkzeuge fehlen nicht nur in der Community, sie fehlen auch im Modell selbst.

API-Änderungen sind eine wiederkehrende Token-Steuer

Die schwache Leistung von SvelteKit hat eine konkrete, fast schon komische Ursache: Der Agent hat bei jedem einzelnen Durchlauf den Migrationsleitfaden zu SvelteKit v3 gelesen, weil diese Version zu neu war, um in den Trainingsdaten des Modells vorzukommen. Jede Breaking Change, die ein Framework ausliefert, entwertet Muster, die das Modell auswendig gelernt hat, und zwingt es, die korrekte API zur Inferenzzeit aus der Dokumentation neu herzuleiten – bezahlt in Tokens, bei jeder Sitzung, von jedem Nutzer. Frameworks behandeln große Versionswechsel als Marketingereignis. Für Agenten-Nutzer ist es ein wiederkehrender Aufschlag. Ein langweiliges Framework, dessen API seit drei Jahren nicht gebrochen wurde, ist nach dieser Metrik ein Premium-Feature.

Ausführlichkeit verstärkt sich durch die Schleife

Angulars Kosten schienen mit dem schieren Codevolumen zu korrelieren – mehr generierte Zeilen bedeuten mehr ausgegebene Tokens, mehr Tokens, die bei jeder weiteren Änderung erneut gelesen werden, und mehr Angriffsfläche, an der sich der Agent verheddert. Das lässt sich verallgemeinern: Jeder Stack mit ausführlicher Tool-Ausgabe, verrauschten Build-Logs oder langsamen Testbefehlen zwingt den Agenten, sich pro Iteration durch mehr Text zu kämpfen, und jeder fehlgeschlagene Lint- oder Typcheck löst eine weitere teure Runde aus. Praktiker berichten überall dasselbe Muster: Nicht die Kosten der Generierung, sondern die Kosten der Iteration dominieren die Agenten-Ausgaben. Ein Framework mit schneller, ruhiger und strikter Toolchain ist günstiger zu betreiben als ein nachsichtiges, denn Strenge fängt Agenten-Fehler in einem Zyklus ab statt in fünf.

Jede Breaking Change, die dein Framework ausliefert, ist jetzt eine Steuer, die jemand in Tokens bezahlt – und anders als ein Mensch, der ein Changelog liest, zahlt das Modell sie bei jeder einzelnen Sitzung.

Das Würfelproblem bei Agenten-Benchmarks

Hier kommen meine alten ML-Evaluierungsgewohnheiten zum Tragen, denn das wichtigste Detail der ganzen Studie sind die Fehlerbalken. LLM-Ausgaben sind eine Verteilung, kein Punktwert. Der mediane Build-Preis von React Router lag etwa einen Dollar über dem von Hono+htmx – doch der günstigste Einzellauf von React Router kam unter dem teuersten Lauf von Hono heraus. Die Spannen überlappen sich erheblich. Die Läufe von SvelteKit schwankten zwischen etwa 3,20 und 6,80 Dollar. Manchmal würfelt der Agent einfach niedrig, verliert sich in einem Nebengleis und verbrennt ein paar Millionen Tokens aus Gründen, die nichts mit dem Framework zu tun haben.

Die Daten zur Nutzung der Tools zeigen dasselbe. Frameworks lieferten MCP-Server und Skill-Dateien aus, und die Agenten nutzten sie … manchmal. Der MCP-Server von Nuxt wurde in fünf Durchläufen nie angefasst. Die Skill-Dateien von TanStack Start wurden in zwei von fünf Durchläufen entdeckt. Der Skill von React Router wurde jedes Mal verwendet. Gleicher Prompt, gleiches Harness, völlig unterschiedliches Verhalten – das ist die stochastische Natur des Werkzeugs. Das bedeutet, dass jeder Twitter-Thread, der behauptet „Framework X ist für Agenten so viel besser, ich habe meine ganze App neu geschrieben“, auf Grundlage eines Nachmittags Vibe-Coding nur Rauschen misst. Ein Lauf ist eine Anekdote. Wenn du KI-Kosten eine Architekturentscheidung beeinflussen lässt – und ich finde, du solltest das –, verlange Mediane über wiederholte Läufe, bevor du irgendetwas glaubst, auch diesem Benchmark.

Bei der Ausgabequalität konvergiert alles zu „gut genug“

Das überraschendste Ergebnis ist, was sich nicht unterschied. Die Lighthouse-Werte für Performance, Accessibility und Cumulative Layout Shift waren über alle zwölf Stacks fast gesättigt – fast überall 99 und 100. Bei klarer Spezifikation und Konformitätssuite erzeugen moderne Agenten kompetente, barrierefreie kleine Apps in praktisch jedem Framework. Die Qualitätsuntergrenze ist so hoch gestiegen, dass das Framework bei einer inhaltsorientierten Seite kaum noch einen Unterschied in der Ausgabe macht.

Die einzige Qualitätsmetrik mit echter Streuung war das ausgelieferte JavaScript: null KiB bei den Islands-artigen Builds von Astro und Hono+htmx, bis zu rund 142 KiB bei der schwersten SPA-Ausgabe. Die Total Blocking Time blieb durchweg unauffällig, und der LCP war zu verrauscht, um viel daraus zu lesen. Zwei ehrliche Einschränkungen gelten hier. Die Test-App ähnelt eher Wikipedia als Figma, begünstigt also Multi-Page-Architekturen, und Lighthouse selbst ist strukturell gegen SPAs voreingenommen. Dennoch verdient das Ergebnis für Vanilla-JavaScript eine Pause: Der Agent, der reines Vite ohne Framework nutzen sollte, erzielte schlechtere Werte als mehrere echte Frameworks, inklusive dem höchsten Layout Shift aller Builds. Frameworks kodieren Konventionen, und Agenten stützen sich stark darauf. Gibst du dem Modell eine ausgetretene Spur, bleibt es darin; gibst du ihm ein leeres Feld, improvisiert es – nicht immer gut.

Was dieser Benchmark nicht verraten kann

Bevor jemand seine Produktionsapp auf Grundlage einer Pokémon-Demo umbaut, sollten wir ehrlich über den Geltungsbereich sein. Das ist eine kleine, überwiegend inhaltsgetriebene Anwendung mit wenig querschnittlichem Zustand, ohne Lokalisierung, ohne komplexe Formulare und ohne ein Team von Menschen, das sie fünf Jahre lang pflegt. Das ist eine echte Einschränkung, und es ist dieselbe Falle, um die ich in diesem Blog immer wieder kreise: KI-Benchmarks verfehlen systematisch den Großteil dessen, wie echte Arbeit aussieht. Die Eigenschaften, die ein Framework auf einem Greenfield-Spielzeug für Agenten gut machen – Vertrautheit, Einfachheit, statische Struktur –, sind nicht dieselben, die im achtzehnten Monat eines chaotischen Produkts zählen.

Außerdem gibt es einen tieferen Punkt, den die Framework-Skeptiker in der Diskussion richtig erkannt haben. Ein großer Teil des historischen Werts eines Frameworks lag nie darin, was es dir erlaubt, sondern darin, was es verbietet. Java hat die Unternehmensentwicklung teilweise erobert, weil es zehntausende Programmierer zwang, ähnlich aussehenden Code zu schreiben. Frameworks sind Constraint-Systeme für Teams aus Menschen, die kommen, gehen und einander missverstehen. Ein Agent braucht keine Leitplanken gegen Langeweile oder lebenslaufgetriebene Entwicklung; er braucht eine klare Spezifikation und eine Testsuite. Ein Praktiker berichtete genau diese Umkehrung bei htmx: Der Agent kam mit einfachen Seiten locker zurecht, scheiterte aber an einem komplexen zustandsbehafteten Formular, verlor Zustände und brach Toggles – Probleme, die React auf Anhieb gelöst hätte –, bis genug Tests existierten, um ihn ehrlich zu halten. Die Einschränkung, die für Agenten zählt, ist nicht das Framework. Es ist die Konformitätssuite.

Und ja, der günstigste Build ist nicht die günstigste Codebasis. Zwei zusätzliche Dollar pro Agenten-Sitzung für einen Stack, den dein Team tief versteht und jahrelang pflegen kann, sind offensichtlich richtig. Aber beachte, was dieses Argument voraussetzt: Zahlen. Der ganze Sinn, KI-Kosten zu messen, besteht nicht darin, einen Gewinner zu küren – sondern „dieses Framework ist besser für Agenten“ durch eine Größe zu ersetzen, die du gegen Bewerbermarkt, Reifegrad des Ökosystems und Bundle-Größe abwägen kannst. Vibes haben die DX-Debatte verloren; sie sollten die agentische nicht standardmäßig gewinnen.

So misst du die KI-Kosten deines eigenen Stacks

Extrapoliere nicht aus dem Benchmark anderer – auch nicht aus diesem hier – auf deine Codebasis. Dein Repo, deine Spezifikation und dein Modell deiner Wahl erzeugen ihre eigene Verteilung. Die gute Nachricht ist, dass sich KI-Kosten wirklich leicht messen lassen, weil Coding-Agenten bereits alles melden, was du brauchst. Wenn du verstehen willst, wie Schleife, Kontext und Berechtigungen zusammenspielen, bevor du sie instrumentierst, ist unser Beitrag wie ein agentisches Coding-CLI tatsächlich funktioniert eine gute Grundlage. Dann mach Folgendes:

1. Wähle einen vertikalen Schnitt, der deine reale Arbeit repräsentiert – ein Feature, das deine Datenschicht, dein State-Management und deine UI berührt, nicht eine Landingpage.
2. Schreibe zuerst die Konformitätstests. Tests sind sowohl dein Qualitätstor als auch dein Mittel gegen Schummeln; ein Agent ohne Tests erklärt vorzeitig den Sieg.
3. Führe denselben Prompt pro Kandidaten-Stack oder jede Konfiguration mindestens fünfmal aus. Berichte Mediane und Spannen, niemals Einzelläufe.
4. Protokolliere die Tokens insgesamt (aufgeteilt nach Cache-Reads, Input und Output), die Laufzeit, die Kosten sowie die Anzahl der Tool-Aufrufe und Retry-Schleifen.
5. Erfasse, wie viele Tokens in Dokumentationslesungen fließen – Migrationsleitfäden, Changelogs, node_modules-Spelunking. Das ist deine Steuer für das Trainingsdaten-Defizit, direkt gemessen.
6. Führe den Benchmark nach größeren Framework-Upgrades erneut aus. Die KI-Kosten driften, wenn sich APIs ändern und Trainingsstichtage verschieben.

Das Harness selbst kann ein Nachmittag Scripting sein. Hier ist das Gerüst, das ich verwendet habe – die Details der CLI-Flags hängen von deinem Agenten ab, aber die Form ist universell:

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

Achte genauso genau auf die Anzahl der Wiederholungen wie auf die Token-Summe. Nach meiner Erfahrung ist Tokens pro akzeptiertem Test die ehrlichste Metrik überhaupt: Sie fasst Kosten, Verwirrung und Korrektheit in einer Zahl zusammen und bestraft den Fehlermodus, der tatsächlich wehtut – den Agenten, der sich durch fünf Compile-Fehler-Schleifen kämpft, bevor er etwas landet, das durchläuft. Ein Framework, in dem der Agent beim ersten oder zweiten Versuch sauber durchläuft, schlägt jedes Mal ein nominell „günstigeres“, das ständig korrigiert werden muss.

Das pragmatische Fazit

Solltest du deine Angular-App also in Astro umschreiben, weil Agenten es günstiger finden? Nein. Die Dollar-Unterschiede sind klein, die Streuung ist groß, die Test-App ist ein Spielzeug, und deine Migration würde mehr Agenten-Tokens kosten, als du in einem Jahrzehnt einsparen würdest. Wer dir eine Framework-Migration „für die Agenten“ verkauft, betreibt dieselbe Vibes-basierte Argumentation, die die Branche schon immer betrieben hat – nur mit einer neuen Begründung obendrauf.

Aber KI-Kosten haben sich einen Platz am Entscheidungstisch verdient, neben Bewerbermarkt, Tiefe des Ökosystems und Bundle-Größe. Für neue Projekte weist die Evidenz in eine konsistente Richtung: Wähle Stacks mit tiefer Repräsentation in den Trainingsdaten, langsamer API-Entwicklung, strikten und ruhigen Toolchains und Konventionen, die das Modell zehntausendmal gesehen hat. Langweilige Technologie war schon immer die pragmatische Wahl; Agenten haben sie nur messbar gemacht. Pinne deine Framework-Versionen, denn jedes Upgrade ist jetzt auch eine Inferenzzeit-Steuer, bis die Modelle aufholen. Und investiere unabhängig vom Framework in Konformitätstests – sie sind das eine Asset, das jeden Agenten günstiger macht, ihn ehrlich hält, wenn er strauchelt, und sich noch auszahlt, lange nachdem das heute verwendete Modell veraltet ist. Die Frameworks werden weiter umkrempeln. Die Tests und die Gewohnheit des Messens sind das, was überlebt.