Claude Code Kosten: Was Build Eval wirklich kostet

Nein. Der Build-Eval-Workflow der Claude API ist öffentlich zugänglich, doch die damit ausgeführte Evaluation ist nicht automatisch kostenlos. Bei den Claude Code Kosten muss zwischen kostenloser Anleitung und abrechenbarer Arbeit unterschieden werden: 24 Fälle × 3 Wiederholungen × 2 Modellvarianten ergeben 144 Anwendungsausführungen, noch bevor optionale Judge- oder Wiederholungsaufrufe hinzukommen. Für diese Prüfung stand kein finanziertes Anwendungspilotprojekt zur Verfügung; 144 ist daher eine Rechengröße und kein gemessener Dollarbetrag.

Ist Build Eval mit der Claude API kostenlos?

Die Workflow-Dateien lassen sich kostenlos lesen; eine ausgeführte Evaluation kann jedoch an drei Stellen bezahlte Modellnutzung verursachen. Claude Code kann ein Abo-Kontingent oder ein verbrauchsabhängig abgerechnetes Konto belasten. Die getestete Anwendung ruft ihren eigenen Modellanbieter auf, und ein optionaler Modell-Judge erzeugt eine weitere Serie von Aufrufen. Ein deterministischer lokaler Grader vermeidet die dritte Rechnung, nicht aber die Anwendungsaufrufe.

Diese Unterscheidung ist entscheidend: build-eval stellt kein Guthaben für kostenlose Evaluationen bereit. Es handelt sich um einen geführten Claude-Code-Workflow, der eine Evaluation rund um eine bereits vorhandene Anwendung aufbaut. Er hilft dabei, den Einstiegspunkt zu bestimmen, Testfälle zusammenzustellen, einen Grader auszuwählen, einen Runner zu schreiben oder anzupassen und nachvollziehbare Ergebnisse zu erzeugen. Die öffentliche Implementierung liegt im Skills-Repository von Anthropic. Für die Aufrufe des fertigen Runners gelten dennoch die Abrechnungsregeln des jeweils verwendeten Kontos und Anbieters.

Die belastbare Antwort ist deshalb an Bedingungen geknüpft: Der Entwurf der Evaluation kann kostenlos sein. Ihre Ausführung kostet nur dann nichts, wenn keine abrechenbaren Aufrufe stattfinden oder die gesamte Nutzung in einem bereits bezahlten Kontingent liegt. Selbst dann bezeichnet „kostenlos“ lediglich die zusätzlichen Rechnungskosten, nicht unbegrenzte Kapazität.

Was sich am 28. und 29. September geändert hat

Anthropic hat den Aufbau von Evaluationen und die iterative Optimierung in zwei klar benannte Claude-Code-Workflows überführt. Der Leitfaden vom 28. September 2026 stellte /claude-api build-eval für den Aufbau einer Evaluation und /claude-api hillclimb für die anschließende Verbesserung einer Anwendung vor. Die Implementierung wurde am 29. September um 02:20:03 UTC mit Commit 8a1541c4 öffentlich verfügbar.

build-eval setzt bei einem einzelnen Anwendungsablauf an. Der Workflow liest den vorhandenen Einstiegspunkt, klärt die Herkunft repräsentativer Fälle, schlägt den günstigsten Grader vor, der das Ergebnis korrekt misst, und verlangt eine ausdrückliche Freigabe sowohl der Eingaben als auch des Bewertungsverfahrens. Am Ende stehen Code und überprüfbare Nachweise im Repository, darunter ein Runner, results.jsonl, Traces und ein Bericht.

hillclimb folgt erst danach. Der Workflow teilt die Fälle in Trainings- und zurückgehaltene Testsätze auf, verändert jeweils nur eine zulässige Oberfläche, führt die Evaluation erneut aus und verwirft Änderungen, die das Ergebnis verschlechtern oder lediglich den Trainingssatz verbessern. So lassen sich Prompts, Modellauswahl, Effort, Tools oder Wrapper-Code der Anwendung optimieren. Jede getestete Variante bedeutet jedoch zusätzliche Ausführungen.

Die nachhaltige Neuerung lautet also nicht: „Evaluationen sind jetzt kostenlos.“ Neu ist, dass Claude Code einen disziplinierten und prüfbaren Evaluationsworkflow zusammenstellen kann, ohne ein separates Framework vorauszusetzen. Das darunterliegende Abrechnungsmodell bleibt bestehen.

Claude Code Kosten bei Build Eval: vier Kostenebenen

Ein brauchbares Budget trennt vier Kostenebenen, denn nur eine davon ist eindeutig kostenlos. Werden alle unter einem pauschalen „Claude kostet“ zusammengefasst, lässt sich später nicht mehr erklären, wo das Geld tatsächlich angefallen ist.

1. Der öffentliche Workflow. Leitfaden und Skill-Dateien sind öffentlich. Sie zu lesen, die lokal erzeugten Dateien zu prüfen und einen lokalen deterministischen Check auszuführen, verursacht für sich genommen keine Claude-API-Tokenkosten.
2. Die Orchestrierung durch Claude Code. Claude Code liest das Repository, klärt Anforderungen, schreibt den Runner und unterstützt bei der Ergebnisprüfung. Abonnenten verbrauchen ihr Plankontingent; per API authentifizierte Sitzungen werden nach Tokens abgerechnet. API-Nutzer sehen geschätzte Sitzungskosten, während Abonnenten stattdessen ihre Plannutzung angezeigt bekommen, wie die Dokumentation zu Claude-Code-Kosten von Anthropic erläutert. Die aktuellen Pläne und Authentifizierungsdetails stehen im Preisleitfaden für Claude Code dieser Website.
3. Die getestete Anwendung. Der Runner sollte den bestehenden Anwendungseinstiegspunkt aufrufen, statt eine vereinfachte Modellanfrage nachzubauen. Jedes Supportticket, jeder erneute Versuch, jede Tool-Schleife und jede Wiederholung belastet deshalb den Anbieter und das Konto, das die Anwendung ohnehin nutzt.
4. Der Grader. Ein festes Label, eine Schemaprüfung, ein Unit-Test oder eine Prüfung des Endzustands kann lokal laufen. Offene Antworten benötigen möglicherweise einen punktweisen oder paarweisen Modell-Judge. Dieser verursacht eigene Eingabe-, Ausgabe- und Cache-Nutzung und kann zusätzlich Tools verwenden.

Der erste Sparhebel ist nicht ein günstigerer Judge, sondern ein programmatischer Grader, sobald die korrekte Ausgabe eine klar begrenzte Form hat. Muss ein Support-Router genau eine Warteschlange aus einer festen Liste zurückgeben, kann Code das Ergebnis prüfen. Ein weiteres Modell zu fragen, ob billing gleich billing ist, gibt Geld für eine deterministische Antwort aus.

Ein Modell-Judge ist sinnvoll, wenn eine Eigenschaft tatsächlich Urteilsvermögen verlangt, etwa ob eine Eskalationszusammenfassung die Dringlichkeit des Kunden erhält, ohne Fakten zu erfinden. Auch dann gehören die Verbräuche von Anwendung und Judge in getrennte Felder. Ein günstiger Judge kann einen teuren Anwendungslauf verdecken – und umgekehrt.

Die Rechnung: Aus 24 Fällen werden 144 Anwendungsausführungen

Die Fallzahl ist nur der erste Multiplikator. Anthropics Einführungsleitfaden zeigt ein Beispiel zur Posteingangsweiterleitung mit 24 Eingaben. Werden 2 Modellvarianten verglichen und wird jeder Fall 3-mal wiederholt, ergibt sich folgende Zahl an Anwendungsausführungen:

24 Fälle × 3 Wiederholungen × 2 Varianten = 144 Anwendungsausführungen

Das ist die Untergrenze für dieses Design, bevor ein Modell irgendein Ergebnis bewertet und bevor ein fehlgeschlagener Aufruf erneut versucht wird. Wiederholungen sind nötig, weil ein Modell auf dieselbe Eingabe unterschiedlich antworten kann. Varianten sind nötig, weil ein Vergleich Ausgaben beider Konfigurationen voraussetzt.

Der Grader bestimmt den nächsten Multiplikator:

• Programmatischer Grader: 0 Modell-Judge-Aufrufe. Es bleibt bei 144 Anwendungsausführungen.
• Paarweiser Judge: 72 Judge-Aufrufe, wenn ein Aufruf je Fall und Wiederholung die beiden Varianten vergleicht, denn 24 × 3 = 72 Paare.
• Punktweiser Judge: 144 Judge-Aufrufe, wenn jede Anwendungsausgabe einzeln bewertet wird. Damit entstehen insgesamt 288 Modellaufrufe – 144 für die Anwendung und 144 für den Judge –, noch vor Wiederholungsversuchen oder der Orchestrierungsnutzung von Claude Code.

Hillclimbing fügt eine weitere Dimension hinzu, weil jede Runde einen neuen Kandidaten ausführt. Eine Schleife, die mehrere Patches ausprobiert, kann mehrere vollständige Evaluationsdurchläufe verbrauchen, obwohl jeder unterlegene Patch wieder zurückgenommen wird. Vor der Optimierung braucht es daher eine Obergrenze für Runden und Ausgaben. „Stoppen, wenn der Score steigt“ ist kein Budget: Schwankende Scores können die Suche immer weiterlaufen lassen.

Claude API Kosten beginnen bei der gemessenen Nutzung

Ein Fall hat keinen Festpreis. Eine seriöse Schätzung beginnt deshalb mit den tatsächlichen Nutzungsfeldern eines bezahlten Piloten. Ein Ticket kann nur einen kurzen Klassifizierungsaufruf auslösen. Ein anderes bringt möglicherweise einen langen Kontext, mehrere Tools, Wiederholungsversuche und einen Judge mit sich. Beides als „einen Evaluationsfall“ zu bepreisen, verschleiert genau den Unterschied, der die Rechnung bestimmt.

Die Preisliste der direkten Anthropic API wurde am 29. September 2026 geprüft. Die folgenden Preise gelten pro Million Tokens:

Quelle: aktuelle Preisseite der Claude API von Anthropic. Für Amazon Bedrock oder Google Cloud ist die Preisliste des jeweiligen Anbieters maßgeblich; die direkten API-Preise sollten nicht einfach übernommen werden.

Für jede Pilotzeile ist Folgendes zu berechnen:

frische Anwendungseingabe + Anwendungsausgabe + Cache-Schreibvorgänge der Anwendung + Cache-Lesevorgänge der Anwendung + frische Judge-Eingabe + Judge-Ausgabe + Cache-Schreibvorgänge des Judges + Cache-Lesevorgänge des Judges + kostenpflichtige serverseitige Tools

Jeder Token-Bucket wird mit dem Tarif des Modells multipliziert, das ihn erzeugt hat. Cache-Tokens dürfen nicht mit frischen Eingabe-Tokens zusammengelegt werden. Als allgemeine Faustregel kostet ein 5-Minuten-Cache-Schreibvorgang das 1.25-Fache des Eingabepreises, ein Lesevorgang das 0.1-Fache. Die aktuelle Preisliste enthält jedoch wichtige Ausnahmen für Lesevorgänge: Bei Fable 5.1 sind es das 0.025-Fache des Eingabepreises, bei Opus 5.5 das 0.05-Fache. Ein pauschal übernommener Faktor von 0.1 würde beide Werte zu hoch ansetzen.

Dieselbe Sorgfalt gilt für den Judge. Nutzt die Anwendung Sonnet 5.5 und der Judge Haiku 4.5, wird jeder Verbrauch anhand seines eigenen Modells und Tarifs berechnet. Läuft die Anwendung zu einem vertraglich vereinbarten Cloud-Tarif, gilt dieser Vertrag. Wird ein serverseitiges Tool pro Vorgang abgerechnet, kommt es separat hinzu. Clientseitige Tools vergrößern weiterhin den Modellkontext und damit die Tokenrechnung.

Hier steht kein gemessener Dollarbetrag, weil für diese Veröffentlichung weder ein Anwendungseinstiegspunkt noch ein Anbieterkonto oder ein genehmigter, finanzierter Pilot verfügbar war. Eine erfundene Tokenzahl ergäbe zwar einen ordentlichen Betrag, aber kein brauchbares Budget. Die Preistabelle ist geprüft; die Gesamtkosten des Laufs müssen auf gemessene Nutzung warten.

Claude Code Build Eval: zuerst einen Fünf-Ticket-Piloten bepreisen

Der kleinste sinnvolle Schritt ist ein Pilot mit fünf Tickets über den vorhandenen Einstiegspunkt des Support-Routers, gefolgt von einer Prüfung der Nutzung auf Zeilenebene. Fünf Tickets reichen nicht aus, um Produktionsqualität nachzuweisen. Sie genügen aber, um die korrekte Verdrahtung von Runner, Grader, Trace und Kostenrechnung zu prüfen, bevor sich ein Fehler über eine vollständige Suite vervielfacht.

Verwendet werden fünf synthetische Tickets, die unterschiedliche Weiterleitungsfälle abdecken, ohne Kundendaten zu kopieren:

• Ein Kunde kann das Abrechnungsportal nicht öffnen.
• Eine Karte scheint doppelt belastet worden zu sein.
• Ein Kunde fragt, ob ein Jahresabo erstattungsfähig ist.
• Ein Produktionsausfall erfordert eine dringende Eskalation.
• Ein Unternehmenskunde bittet um eine Vertragsänderung.

Diese Fälle sind ein vorgeschlagener Pilotsatz, kein Bericht über einen durchgeführten Test. Sie sollten dieselbe Funktion, denselben Endpunkt oder dasselbe Skript durchlaufen wie der produktive Router; externe Seiteneffekte werden dabei isoliert. Kann der Live-Ablauf E-Mails versenden, eine Datenbank verändern oder einen Bereitschaftsdienst alarmieren, wird nur dieser Seiteneffekt durch eine Test-Fixture ersetzt. Prompt-Aufbau, Modellaufruf, Tools, Wiederholungsversuche und Antwort-Parsing müssen produktionsgleich bleiben, sonst bepreist der Pilot das falsche System.

1. 1

   Einstiegspunkt und Abrechnungsidentität bestätigen

   Zu dokumentieren sind Funktion oder Endpunkt der Anwendung, Modell, Anbieter, Konto, Prompt, Tools und Ausgabeform. Ebenfalls festzuhalten ist, wie Claude Code selbst authentifiziert ist. So werden Plankontingent und API-Nutzung der Anwendung voneinander getrennt, bevor eines von beiden startet.

2. 2

   Die fünf Eingaben und den Grader freigeben

   Jedes synthetische Ticket und die erwartete Route müssen geprüft und freigegeben werden. Für ein festes Warteschlangenlabel eignet sich ein programmatischer Grader. Ein Modell-Judge kommt nur für Eigenschaften hinzu, die sich nicht per Code prüfen lassen; das getestete Modell darf nie sein eigener Judge sein.

3. 3

   Einen finanzierten Piloten ausführen

   Der Lauf umfasst 5 Fälle × 1 Wiederholung × 1 Anwendungsvariante, also 5 Anwendungsausführungen. Der veröffentlichte Workflow verlangt vor dem ersten kostenpflichtigen Durchlauf eine eindeutige Zustimmung. Fehlt das genehmigte Budget, endet der Prozess hier mit einem ausführbaren Trockenaufbau, statt einen Preis vorzutäuschen.

4. 4

   Die Zeile prüfen, nicht die Überschrift der Konsole

   Zu öffnen sind results.jsonl und ein Trace. Bei erfolgreichen Zeilen müssen model und usage befüllt sein, der Einstiegspunkt muss stop_reason ausgeben, und die Nutzung von Anwendung und Judge muss unterscheidbar sein. Felder für Cache-Schreib- und Cache-Lesevorgänge bleiben erhalten, statt in der Eingabe aufzugehen. Eine Null, die keine Null sein dürfte, ist ein Runner-Fehler – kein kostenloser Aufruf.

5. 5

   Gesamtumfang bepreisen und freigeben

   Die fünf Zeilen werden zu den tatsächlich geltenden Anbietertarifen berechnet. Anschließend werden Minimum, Median und Maximum pro Fall ausgewiesen und mit der freigegebenen Zahl an Fällen und Wiederholungen multipliziert. Hinzu kommen die gewählte Grader-Form, Wiederholungsversuche und die Hillclimb-Obergrenze. Diese Formel gehört in die Vorlage, bevor die Freigabe für den vollständigen Lauf angefragt wird.

Diese Reihenfolge folgt der veröffentlichten Implementierung: Erst einen finanzierten Piloten messen und dessen Nutzung prüfen, dann die Suite schätzen. Historische Durchschnittswerte sind kein Ersatz. Cache-Zustand, Tool-Schleifen, Effort, Wiederholungsversuche und Ausgabelänge gehören zu dieser Anwendung, nicht zu einem Durchschnitt.

Was Entwickler, Betreiber und Einkäufer daraus ableiten sollten

Entwickler sollten Kosten an der Anwendungsgrenze sichtbar machen. Verbirgt der Einstiegspunkt model, usage oder stop_reason, gehören diese Felder in das letzte Event, bevor der vollständige Runner geschrieben wird. Native Cache-Felder des Anbieters müssen erhalten bleiben, die Judge-Nutzung wird separat angehängt. Das typische Hindernis ist ein makelloser Bericht auf Basis unvollständiger Zeilen: Ist der Gesamtlauf beendet, lassen sich fehlende Token-Buckets oft nicht mehr rekonstruieren.

Betreiber sollten die Multiplikation und die Freigabeschranke verantworten. Fälle, Wiederholungen, Varianten, Grader-Aufrufe, Wiederholungsrichtlinie und maximale Hillclimb-Runden gehören auf eine Seite. Ein Budget, in dem nur „24 Fälle“ steht, ist unvollständig. Ein Budget mit 144 Anwendungsausführungen, der Grader-Form, gemessener Nutzung pro Fall und einer festen Abbruchgrenze ist prüfbar.

Einkäufer sollten klären, welche Ebene ein Preisangebot abdeckt. Sind die Orchestrierung durch Claude Code, das Anwendungsmodell, der Judge, Aufschläge des Cloud-Anbieters, Tool-Gebühren, Wiederholungsversuche und Optimierungsrunden enthalten? Ein Anbieter kann wahrheitsgemäß einen günstigen Judge anbieten und zugleich die Anwendungsläufe ausklammern, die den Großteil der Ausgaben verursachen. Verlangt werden sollten die Pilotzeilen und die Formel, nicht nur eine Gesamtsumme.

Wer jetzt handeln, abwarten oder beim Plugin-Ansatz bleiben sollte

Jetzt handeln lohnt sich, wenn die Anwendung einen stabilen Einstiegspunkt, eine anstehende Entscheidung und fünf repräsentative Fälle hat, die sich sicher prüfen lassen. Eine Prompt-Migration, ein Modellwechsel, eine Änderung der Routing-Richtlinie oder ein Tool-Wechsel eignet sich gut, weil die Evaluation ein konkretes Vorher und Nachher vergleichen kann.

Abwarten ist richtig, solange der Runner die Produktionslogik nicht sicher aufrufen kann. Zuerst müssen Datenbankschreibvorgänge, ausgehende Nachrichten, destruktive Tools und veränderlicher externer Zustand isoliert werden. Abwarten gilt auch, wenn niemand Eingaben oder Grader freigeben kann. Zusätzliche Ausführungen retten keine Evaluation, die die falsche Aufgabe misst.

Beim nativen Plugin-Ansatz bleiben sollte, wer den Mehrwert eines Claude-Code-Plugins prüfen möchte. Dieser Workflow vergleicht gezielt Sitzungen mit „WITH-plugin“ und „W/OUT-plugin“. Der Leitfaden dieser Website zum Testen von Claude-Code-Plugins mit Evaluationen beschreibt diesen separaten Kontrollansatz. build-eval für Anwendungen richtet sich an den Einstiegspunkt der App; es ersetzt die Plugin-Kontrolle nicht durch einen allgemeinen Benchmark.

Wer bereits einen vertrauenswürdigen Runner und Grader hat, ist nicht betroffen. Beide können weiterverwendet werden. Die öffentliche Implementierung bevorzugt ausdrücklich die Anpassung bestehender Bausteine gegenüber dem Austausch durch ein neues Framework. Der eigentliche Mehrwert kann in der Freigabedisziplin, der Nutzungserfassung oder der Hillclimb-Schleife liegen, nicht in einem neuen Test-Stack.

Was an Build Eval übertrieben dargestellt wird

Der Workflow senkt den Einrichtungsaufwand; er macht Evaluationen weder automatisch noch objektiv oder kostenlos. Claude kann Fälle vorschlagen, doch ein Mensch muss weiterhin entscheiden, ob sie die Produktion abbilden. Claude kann einen Grader vorschlagen, doch ein Mensch muss prüfen, ob eine Musterantwort besteht, eine Nullantwort durchfällt und ein Modell-Judge nicht Stil statt Korrektheit belohnt.

Auch Hillclimbing ist kein kostenloser Optimierer. Es führt gezielt weitere Varianten aus, liest Fehler, schlägt Patches vor und evaluiert erneut. Der zurückgehaltene Testsatz schützt vor einer Form der Überanpassung, ersetzt aber weder genügend Fälle und Wiederholungen noch eine Ausgabenobergrenze.

Der Bericht ist nur dann ein Beleg, wenn seine Zeilen vollständig sind. Eine ansprechende report.html neben leeren usage-Feldern kann die Kostenfrage nicht beantworten. Ein aus angenommenen Tokenzahlen berechneter Dollarbetrag ist nicht besser. Vor einem finanzierten Piloten besteht das belastbare Ergebnis aus Ausführungsplan und aktueller Preisliste; der gemessene Gesamtbetrag bleibt offen.

Der nächste Schritt am Montag

Ein Verantwortlicher erhält einen klar begrenzten Piloten – keinen offenen Auftrag, „Evaluationen zu bauen“. Am Montag wird der bestehende Einstiegspunkt des Support-Routers ausgewählt, die fünf oben genannten synthetischen Tickets werden erstellt und ein programmatischer Grader für feste Labels wird eingesetzt. Eingaben und erwartete Routen werden gemeinsam mit der für die Support-Richtlinie verantwortlichen Person geprüft.

Danach wird die Freigabe für genau 5 Anwendungsausführungen eingeholt. Zu prüfen sind results.jsonl, ein Trace, jeder Nutzungs-Bucket und stop_reason. Diese Zeilen werden mit dem tatsächlich geltenden Anbietertarif bepreist. Erst anschließend sollte der Umfang von 24 Fällen, 3 Wiederholungen und 2 Varianten samt Obergrenzen für Judge, Wiederholungsversuche und Hillclimb vorgeschlagen werden.

Die Entscheidungsregel ist unmissverständlich: Ohne vollständige Pilotnutzung gibt es keine Budgetfreigabe für den Gesamtlauf.