KI-Kosten von JavaScript-Frameworks: Vergleich und eigener Test

Bei einer inhaltslastigen Anwendung solltest du zuerst Hono+htmx und Astro prüfen, wenn die KI-Kosten wichtig sind. Im Benchmark von Nolan Lawson hatte Hono+htmx den niedrigsten Median der geschätzten API-Kosten: $2.67 gegenüber $4.97 bei Angular. Teste bei einem bestehenden Projekt zuerst eine typische Änderung, bevor du das Framework wechselst.

Welches Framework hatte die niedrigsten KI-Kosten?

Nutze diese Ergebnisse, um Kandidaten für einen eigenen Test mit einer inhaltslastigen Anwendung auszuwählen. Lawson veröffentlichte das Experiment am 28. Oktober 2026. Die veröffentlichten Durchläufe und Messungen verwendeten Claude Code 2.1.310 mit claude-opus-5-5 und der Effort-Stufe high.

Jeder Agent entwickelte dieselbe PokéAPI-Anwendung mit Suche, Filtern und Detailseiten. Die Tabelle fasst die veröffentlichten Ergebnisse mit Stand 2026-11-06 zusammen. Die Versionen bezeichnen die getesteten Framework-Pakete und sind keine aktuellen Installationsempfehlungen.

Framework und getestete Version	Geschätzte API-Kosten, Median in USD (Min.–Max.)	Minuten	Tokens, Millionen	Quellcodezeilen
Hono 4.13.14 + htmx 2.0.11	$2.67 ($2.23–$3.19)	8.6	4.26	1,370
Astro 7.4.2	$2.76 ($2.16–$3.63)	8.2	4.13	1,461
Nuxt 4.6.2	$2.82 ($2.39–$4.25)	9.0	3.85	1,415
Vanilla mit Vite 8.3.5	$2.98 ($2.24–$3.37)	10.1	5.00	1,492
Next.js 16.4.3	$3.14 ($2.58–$4.13)	10.9	4.99	1,539
Qwik 1.20.2 / 1.20.3	$3.27 ($2.35–$3.80)	10.7	5.64	1,744
TanStack Start 1.169.4	$3.54 ($3.11–$3.96)	10.3	7.07	1,697
SolidStart 2.1.0	$3.79 ($2.84–$4.81)	11.2	7.13	1,630
React Router 8.5.0	$3.81 ($2.82–$3.97)	12.5	7.58	1,564
SvelteKit 3.1.0	$4.28 ($3.59–$4.65)	10.8	8.53	1,611
Gracile 0.11.0 + Lit 3.3.3	$4.65 ($3.92–$5.07)	12.1	9.04	1,717
Angular 22.2.3	$4.97 ($3.19–$6.82)	17.2	9.76	2,009

Jede Kennzahl ist ein separat berechneter Median. Kosten, Zeit und Tokens berücksichtigen fünf Versuche pro Framework. Der Codeumfang von Angular basiert auf drei Anwendungen, weil sich zwei hinter dem Reverse Proxy nicht messen ließen.

Die Tokenzahlen umfassen nicht zwischengespeicherte Eingaben, Cache-Schreibvorgänge, Cache-Lesevorgänge und Ausgaben während der gesamten Sitzung. Bei den Quellcodezeilen zählen Kommentare mit. Leerzeilen, JSON, Lockdateien, Tests, generierte Dateien und kopierte Designdateien sind ausgeschlossen.

Die Dollarbeträge sind die von Claude Code ausgewiesenen API-Kostenschätzungen. Lawson nutzte ein Abonnement; die Tabelle zeigt daher nicht seine tatsächlichen Zahlungen pro erstellter Anwendung. Hosting und menschliche Prüfzeit sind ebenfalls nicht enthalten.

Mit den gerundeten Medianen beträgt der Abstand für Angular $4.97 − $2.67 = $2.30. Das entspricht 4.97 / 2.67 ≈ 1.86 mal den Kosten von Hono+htmx, also etwa 86% mehr für diese Aufgabe.

Zwischen Next.js und Astro liegen $0.38 pro erstellter Anwendung, wobei sich die beobachteten Bereiche überschneiden. Hono+htmx und Astro unterscheiden sich nur um $0.09. Diese Abstände sprechen für einen kleinen eigenen Test. Für eine verlässliche allgemeine Rangfolge reichen sie nicht aus.

Warum waren SvelteKit und Angular teurer?

Zusätzliche Dokumentationsabrufe und größere erzeugte Anwendungen könnten zu den höheren Kosten beitragen. Das Experiment trennt ihre Auswirkungen jedoch nicht voneinander.

Lawson beobachtete, dass der SvelteKit-Agent in jedem Durchlauf den Migrationsleitfaden für v3 las. Er vermutete, dass v3 neuer sein könnte als die Trainingsdaten des Modells. Der offizielle Migrationsleitfaden beschreibt tatsächliche Änderungen, darunter die Verlagerung der Konfiguration nach Vite. Er belegt nicht, was das Modell während des Trainings gelernt hat.

Für Gracile berichtet Lawson, dass Agenten das Repository klonten oder kompilierte Dateien in node_modules untersuchten. Das bedeutet zusätzliche Recherchearbeit. Der Benchmark misst nicht, welcher Anteil des Kostenunterschieds auf diese Zugriffe zurückgeht.

Angular erzeugte im Median 2,009 Quellcodezeilen, Hono+htmx dagegen 1,370. Letzteres entspricht etwa 68% des Angular-Werts und passt zu Lawsons grobem Vergleich von 70%. Größere Dateien können später mehr Lese- und Bearbeitungsaufwand verursachen. Wartungskosten wurden in diesem Experiment jedoch nicht gemessen.

Auch die Gesamtzahl der Tokens muss sorgfältig interpretiert werden. Nuxt hatte mit 3.85 Millionen den niedrigsten Token-Median, aber nicht den niedrigsten Kostenmedian. Die Cache-Nutzung verändert das Verhältnis zwischen Tokenzahl und Preis. Betrachte die Tokenkategorien deshalb getrennt.

Helfen MCP-Server und Skills der Frameworks?

Dieser Benchmark belegt nicht, ob MCP-Server oder Skills die Kosten senken. Er zeigt eine uneinheitliche Nutzung verfügbarer Werkzeuge. Ein direkter Vergleich mit und ohne diese Werkzeuge für jedes Framework fehlt.

Lawson installierte offizielle Werkzeuge, soweit sie verfügbar waren. Für mehrere Frameworks gab es keine. Er beobachtete unter anderem:

Framework	Beobachtete Nutzung in fünf Durchläufen
Hono+htmx	Skill-Werkzeug für Hono in 5/5 genutzt
SvelteKit	MCP in 5/5 genutzt
Nuxt	MCP in 0/5 genutzt
Next.js	Skill-Dateien in 1/5 gelesen; AGENTS.md in 2/5 gelesen
TanStack Start	Mitgelieferte Skill-Dateien in 2/5 entdeckt

Dass der Nuxt-MCP ungenutzt blieb, belegt nicht seine Wirkungslosigkeit. Ebenso beweisen die höheren SvelteKit-Kosten nicht, dass dessen MCP die Ursache war. Installation, tatsächlicher Aufruf und geringere Kosten für eine abgeschlossene Aufgabe sind getrennte Fragen.

Die aktuelle Next.js-Anleitung unterscheidet zwischen Dokumentation für die installierte Version und Skills, die Arbeitsabläufe koordinieren. Erfasse, welche Ressource der Agent tatsächlich genutzt hat. Nicht jeder Dokumentationsabruf ist ein MCP-Aufruf.

Prüfe im eigenen Test mit claude mcp list oder /mcp, ob die Server verfügbar sind. Untersuche anschließend die tatsächlichen Werkzeugaufrufe. Vergleiche dasselbe Framework ohne Werkzeuge, mit verfügbaren Werkzeugen und mit der ausdrücklichen Anweisung, diese zu verwenden. Die Anleitung zum Messen des MCP-Kontextverbrauchs hilft bei diesem gezielten Folgetest.

Was lässt das Experiment offen?

Nutze die Ergebnisse zur Vorauswahl für kleine, inhaltslastige Anwendungen. Berücksichtige dabei vier Grenzen:

• Aufgabe: Ein Katalog mit wenigen Interaktionen steht nicht für einen komplexen Editor, ein Dashboard oder ein Spiel. Auch die Rendering-Architektur überließ Lawson den Agenten.
• Stichprobe: Fünf Versuche liefern hilfreiche Beispiele und Wertebereiche. Bei eng beieinanderliegenden Ergebnissen bleibt die Rangfolge unsicher. Die Bereiche zeigen beobachtete Minimal- und Maximalwerte, keine Konfidenzintervalle.
• Umgebung: Getestet wurden ein Modell, ein Agent und eine Effort-Stufe. Nach dem ersten Qwik-Durchlauf wechselte die Version von 1.20.2 auf 1.20.3. Die angeforderte Kombination Gracile+Lit führte außerdem zu zwei Implementierungen ohne Lit.
• Ergebnis: Lighthouse-Messungen beim mobilen Seitenaufruf erfassen nicht jede Interaktion oder Produktionsanforderung. Quellcodezeilen messen den Umfang, liefern aber keine belegte Prognose der Wartungskosten.

Auch die Angular-Ausnahme ist relevant. Das Archiv verzeichnet bestandene Akzeptanztests für alle fünf Versuche. Zwei Messungen der Produktionsversion schlugen jedoch fehl. Erfasse in deinem Experiment bestandene Tests und eine erfolgreiche Bereitstellung getrennt.

So misst du die Kosten von Claude Code im eigenen Projekt

Beginne mit zwei Kandidaten und jeweils drei unabhängigen Versuchen. Erhöhe auf fünf, wenn die Ergebnisse nahe beieinanderliegen. Das ist ein Vorschlag für einen ersten Test und kein zusätzliches Benchmark-Ergebnis.

1. Lege Aufgabe und Ausgangszustand fest

Vergleiche eine klar begrenzte Funktion anhand identischer Akzeptanztests. Bei einem bestehenden Produkt sollte dein aktuelles Framework einer der Kandidaten sein. Bereite beide Ausgangsprojekte vor, bevor du die Zeit für eine Änderung misst. Soll die Entwicklung von Grund auf verglichen werden, rechne die Einrichtung bei beiden ein.

Beschreibe eine konkrete Aufgabe in SPEC.md. Bereite beispielsweise gleichwertige Katalogseiten mit denselben Produkt-Testdaten vor. Gib dem Agenten dann diese Aufgabe:

Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.

Fixiere die Versionen der Abhängigkeiten und behalte die Lockdateien. Installiere die Abhängigkeiten vor einem Änderungstest. Beide Projekte müssen npm run build und npm test bereitstellen. Bewahre eine unveränderte Kopie der Akzeptanztests auf.

Verwende bei jeder Wiederholung denselben Ausgangscode, Prompt, dasselbe Modell und dieselbe Effort-Stufe. Halte auch Berechtigungen, vorgesehene Framework-Werkzeuge sowie Zugang und Abrechnung konstant. Starte für jeden Versuch eine neue Unterhaltung in einer frischen Projektkopie. Wechsle die Reihenfolge der Frameworks ab und erfasse die Cache-Nutzung.

Dokumentiere auch Benutzeranweisungen, Hooks und Plugins, die das Verhalten beeinflussen könnten. Wenn du die ursprüngliche Anwendung mit ihren vorhandenen Prüfungen bevorzugst, beginne mit Lawsons Benchmark-Werkzeugen.

2. Erfasse einen Durchlauf und sein Endergebnis

Nutze Bash mit authentifiziertem Claude Code und installiertem jq. Prüfe die Anmeldung mit claude auth status --text. Führe bei Bedarf vor dem Test claude auth login aus.

Führe den Versuch in einem Entwicklungscontainer aus, den du anschließend verwirfst. Die folgende Freigabeliste erlaubt automatisch Dateiänderungen und Shell-Befehle. Genehmige vorgesehene MCP-Aufrufe vorab über Berechtigungsregeln, die in jeder Testumgebung tatsächlich geladen werden. Den Server nur zu verbinden, reicht nicht aus.

Setze für jede Testbedingung ein eigenes trial_label. Das Beispiel nutzt die dokumentierte nicht interaktive CLI und erstellt ein eindeutiges Ausgabeverzeichnis.

trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1

claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"

trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
  --model claude-opus-5-5 \
  --max-budget-usd 10 \
  --allowedTools "Read,Edit,Write,Bash" \
  --output-format stream-json --verbose \
  "Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
  > "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
  || trial_status=$?

printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"

jq -s '
  [.[] | select(.type == "result")] | last
  | if . == null then error("No final result; record an incomplete run")
    else {
      session_id,
      subtype,
      is_error,
      estimated_usd: .total_cost_usd,
      reported_wall_minutes: (.duration_ms / 60000),
      modelUsage,
      permission_denials
    } end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"

cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"

Die Schwelle von $10 ist ein beispielhaft gewähltes Budget. --max-budget-usd verwendet geschätzte API-Ausgaben; diese können die Schwelle überschreiten. Wende für jede Testbedingung dieselbe Schwelle an und protokolliere Stopps wegen des Budgets.

Mit Stand 2026-11-06 hat CLAUDE_CODE_EFFORT_LEVEL Vorrang vor --effort. Effort-Grenzen der Organisation können die gewählte Stufe weiterhin begrenzen. Falls das Modell nicht geladen werden kann, korrigiere zuerst die Konfiguration für Opus 5.5, bevor du den Vergleich fortsetzt.

Die Zusammenfassung sollte estimated_usd, reported_wall_minutes, modelUsage und gegebenenfalls permission_denials enthalten. Das JSONL-Protokoll bewahrt Werkzeugereignisse für die Prüfung auf. Kontrolliere, ob das vorgesehene Modell erscheint, und erfasse alle zusätzlich verwendeten Modelle.

3. Vergleiche akzeptierte Ergebnisse und erfasse Fehlschläge

Nutze modelUsage, um die Tokens des Agenten und seiner Unteragenten zu erfassen. Halte inputTokens, outputTokens, cacheReadInputTokens und cacheCreationInputTokens getrennt. Das Feld usage im Ergebnisobjekt enthält keine Aktivitäten der Unteragenten.

Lies das abschließende Ergebnis einmal aus. Addiere keine bereits kumulierten Ergebnissummen. Behandle eine fortgesetzte Sitzung auch nicht als neuen unabhängigen Versuch.

Führe die unveränderten Tests und den Produktions-Build selbst aus. Prüfe, ob Abhängigkeits- und Testdateien unverändert geblieben sind. Ein Erfolgsergebnis des Agenten beweist nicht, dass die Anwendung die Anforderungen erfüllt.

Fehlt das abschließende Ergebnis oder ist es fehlerhaft formatiert, untersuche stderr.log. Erfasse den Durchlauf als unvollständig mit unbekannten Kosten. Trage nicht null ein. Behebe verweigerte Berechtigungen, bevor du einen ungenutzten MCP als Entscheidung des Agenten interpretierst.

Berichte für jedes Framework die Zahl der akzeptierten Ergebnisse im Verhältnis zu allen Versuchen. Gib außerdem Mediane und Wertebereiche erfolgreicher Versuche sowie die gesamten geschätzten Kosten aller Versuche an. Für die Kosten pro akzeptiertem Ergebnis teilst du die Gesamtkosten der Versuchsreihe durch die Anzahl akzeptierter Ergebnisse:

Total quoted cost of all attempts / Number of accepted results

Fehlen für einen Versuch Kostendaten, kennzeichne die Gesamtkosten als unvollständig. Gibt es kein akzeptiertes Ergebnis, berichte einen Fehlschlag statt eines endlichen Stückpreises. Erfasse menschliche Prüfzeit separat.

Bei manuellen Sitzungen zeigt die aktuelle Kostenanzeige von Claude Code eine entsprechende Schätzung unter /usage. Die Befehlsreferenz führt /cost mit Stand 2026-11-06 als Alias von /usage auf. Abonnementkontingente und tatsächliche Anbietergebühren sind von dieser Schätzung zu trennen.

Behalte deinen bestehenden Stack, wenn Prüfaufwand oder Migration eine kleine Tokenersparnis überwiegen. Ziehe einen Wechsel in Betracht, wenn der Kandidat dieselben Prüfungen wiederholt besteht und die gesamten Betriebskosten für dich vertretbar sind.

Teste nach der Framework-Auswahl ein anderes Modell oder einen anderen Zugangsweg in einem separaten Experiment. Der Vergleich von Coding-Modellen hilft bei der Auswahl weiterer Kandidaten, ohne mehrere Variablen im Framework-Test gleichzeitig zu ändern.