Claude Haiku 4.5: So berechnen Sie die Kosten pro nutzbarer Antwort

Welche Kosten werden berechnet?

Der Preis eines API-Aufrufs, die Ausgaben für eine Aufgabe und die Kosten einer akzeptierten Antwort sind unterschiedliche Kennzahlen. Wenn Sie eine reale Anwendung mit Claude Haiku 4.5 budgetieren, sollten Sie zunächst den Nenner festlegen: Möchten Sie wissen, was jeder an das Modell gesendete Versuch kostet, jede empfangene Antwort, jedes Ergebnis, das Ihre Akzeptanzregeln erfüllt, oder jede Aufgabe, die nach einer menschlichen Prüfung abgeschlossen ist?

Der Unterschied ist relevant, wenn eine Antwort verworfen, korrigiert oder erneut angefordert werden kann. Ein Aufruf, der Text zurückgibt, verursacht Verbrauch – auch dann, wenn dieser Text nicht verwendet wird. Teilen Sie die Gesamtausgaben nur durch die Zahl erfolgreicher Aufrufe, können verworfene Versuche verborgen bleiben. Teilen Sie sie dagegen durch alle Aufrufe, sagt das nicht aus, was es kostet, ein Ergebnis zu erzeugen, das für den Prozess tatsächlich brauchbar ist.

In diesem Leitfaden bezeichnet „akzeptierte Antwort“ eine Ausgabe, die die vom Team festgelegten Kriterien für die jeweilige Aufgabe erfüllt. Das kann etwa ein gültiges Label, ein einem Schema entsprechendes Objekt oder eine geprüfte Zusammenfassung sein. Der Begriff bedeutet weder, dass das Modell Korrektheit garantiert, noch dass die Ausgabe für jeden Einsatz sicher ist oder keiner weiteren Freigabe bedarf. Es handelt sich um eine betriebliche Berechnungseinheit, nicht um ein Qualitätsversprechen.

Der veröffentlichte Tarif ist nur eine Komponente der Budgetplanung. Sie können Inferenzkosten, Wiederholungsversuche, externe Validierung, menschliche Prüfung und weitere Systemressourcen getrennt erfassen. Werden diese Posten auseinandergehalten, lassen sich Ausführungen vergleichen und die Herkunft einer Zahl erklären, ohne eine Schätzung als garantierte Rechnung darzustellen.

Der Tarif für Claude Haiku 4.5 und sein Geltungsbereich

Anthropic nennt für Claude Haiku 4.5 auf der Claude Platform einen Standardtarif von 1 USD pro Million Eingabetokens und 5 USD pro Million Ausgabetokens. Diese Preise sind eine nützliche Grundlage für eine nachvollziehbare Schätzung. Halten Sie dazu aber auch den verwendeten Zugangskanal, die genaue Modellkennung und das Datum der Preisprüfung fest. Setzen Sie nicht voraus, dass ein Drittanbieterkanal oder eine andere Servicevariante denselben Preis hat.

Die Anbieterdokumentation führt auch andere Preismodelle auf, darunter solche für die Batchverarbeitung und für Cache-Tokens. Die Beispielrechnungen in diesem Leitfaden beziehen diese Varianten nicht ein. Ziel ist es, die Berechnung anhand der genannten Standardtarife zu erläutern – nicht, zu bestimmen, welches Preismodell für eine konkrete Anwendung gilt. Prüfen Sie vor der Budgetierung die aktuelle Preisliste und die Bedingungen des Kanals, den Sie einsetzen möchten.

Die Modellkennung ist wichtig, damit sich ein Test wiederholen lässt und Sie überprüfen können, ob die Ausführungen derselben Version entsprechen. Die konsultierte Dokumentation zum Modelllebenszyklus führt die Kennung claude-haiku-4-5-20251001 auf und zeigt das Modell zum Zeitpunkt der Abfrage als aktiv, ohne angekündigtes Abschaltdatum. Dieser Status kann sich ändern und ist keine Garantie für die künftige Verfügbarkeit.

Notieren Sie zur Prüfung der Beträge den angewandten Tarif und das Abrufdatum. Soll das Budget mehrere Monate gelten, planen Sie eine erneute Prüfung von Preisen und Bedingungen ein, bevor aus der Projektion eine verbindliche Zusage wird. Eine Änderung des Einheitspreises wirkt sich auf das Ergebnis aus, selbst wenn Aufgabenvolumen und gemessene Tokenzahlen gleich bleiben.

Die Formel: Inferenzkosten pro akzeptierter Antwort

Mit den genannten Standardpreisen lassen sich die Inferenzkosten eines Textversuchs so schätzen: (Eingabetokens × 1 USD / 1.000.000) + (Ausgabetokens × 5 USD / 1.000.000). Die Formel behandelt beide Seiten der Interaktion getrennt, weil pro Million unterschiedliche Preise gelten. Bei mehreren Aufrufen addieren Sie die geschätzten Kosten sämtlicher Versuche – nicht nur die Kosten der Antworten, die schließlich akzeptiert wurden.

Teilen Sie anschließend die gesamten Inferenzkosten durch die Zahl akzeptierter Antworten. Bei einer Mischung unterschiedlicher Aufgaben berechnen Sie zunächst Kosten und Akzeptanz je Aufgabentyp und führen die Ergebnisse dann anhand des jeweiligen Volumens gewichtet zusammen. Ein einfacher Durchschnitt von Akzeptanzraten kann die Kosten verzerren, wenn Aufgaben sich stark hinsichtlich Tokenverbrauch oder Häufigkeit unterscheiden.

Wenn aggregierte Daten vorliegen, kann es hilfreich sein, die durchschnittlichen Kosten pro Versuch mit der durchschnittlichen Zahl der Versuche bis zu einer akzeptierten Antwort zu multiplizieren. Diese Näherung ist nur dann geeignet, wenn klar ist, wie der Durchschnitt ermittelt wurde und ob er die untersuchte Anwendung repräsentiert. Unterscheiden sich die Längen des ersten Versuchs und der Wiederholungen, berechnen Sie die Ausgaben für diese Gruppen getrennt, statt anzunehmen, jeder Versuch koste gleich viel.

Die gemessenen Tokenzahlen sollten aus repräsentativen Ausführungen stammen und nicht aus einer idealisierten Länge, die eine günstigere Projektion ergibt. Die Messages-API-Referenz dokumentiert Nutzungsfelder für Eingabe und Ausgabe. Damit lässt sich der erfasste Verbrauch mit den Berechnungsannahmen abgleichen. Halten Sie auch Maßeinheit und Messzeitraum fest, damit Tokens nicht mit Zeichen, Wörtern oder Anfragen verwechselt werden.

Drei beispielhafte Szenarien

Die folgenden Beispiele zeigen, wie sich Größenordnungen mit der Tokenmenge und dem Anteil akzeptierter Versuche verändern. Es sind hypothetische Berechnungen, keine veröffentlichten Messungen von Claude Haiku 4.5 und keine Leistungsprognosen. Angenommen wird, dass Versuche im Durchschnitt gleich lang sind, jeder Versuch eine konstante Akzeptanzwahrscheinlichkeit hat und bis zur Akzeptanz wiederholt wird. Unter diesen Annahmen entsprechen die erwarteten Kosten pro akzeptierter Ausgabe den durchschnittlichen Kosten pro Versuch geteilt durch die Akzeptanzrate.

Bei einer kurzen Klassifikationsaufgabe nehmen wir 600 Eingabetokens und 80 Ausgabetokens pro Versuch sowie eine Akzeptanzrate von 95 % an. Bei den genannten Preisen kostet ein Versuch 0,001 USD: 0,0006 USD für die Eingabe und 0,0004 USD für die Ausgabe. Unter den beschriebenen Annahmen betragen die erwarteten Inferenzkosten etwa 0,00105 USD pro akzeptierter Antwort.

Bei einer strukturierten Extraktion nehmen wir 1.800 Eingabetokens und 450 Ausgabetokens sowie eine Akzeptanzrate von 85 % an. Ein Versuch kostet 0,00405 USD: 0,0018 USD für die Eingabe und 0,00225 USD für die Ausgabe. Die erwarteten Kosten pro akzeptierter Antwort liegen bei etwa 0,00476 USD. In diesem Beispiel wird für die Schemaprüfung kein separater Betrag angesetzt. Entstehen dabei tatsächlich abrechenbare externe Kosten, sind sie als eigener Posten zu erfassen.

Bei einer begrenzten Zusammenfassung nehmen wir 3.000 Eingabetokens und 1.200 Ausgabetokens sowie eine Akzeptanzrate von 80 % an. Ein Versuch würde 0,009 USD kosten, die erwarteten Kosten pro akzeptierter Antwort etwa 0,01125 USD. Bei dem angenommenen Tarif entfällt damit zwei Drittel der Versuchskosten auf die Ausgabe. Das Beispiel verdeutlicht, warum die Zahl der Anfragen allein nicht zur Budgetplanung ausreicht: Auch die Länge der Antwort beeinflusst die Kosten.

Welche Variablen das Ergebnis bestimmen

In diesen Beispielen ist der Einheitspreis eines Ausgabetokens fünfmal so hoch wie der eines Eingabetokens. Das bedeutet nicht, dass die Ausgabe immer den größten Anteil der Rechnung ausmacht: Entscheidend ist das Verhältnis der Tokenmengen. Bei einer Anfrage mit umfangreicher Eingabe und sehr kurzer Antwort kann die Eingabe weiterhin einen erheblichen Kostenanteil haben. Bei Aufgaben mit langen Ausgaben kann dagegen die Ausgabe dominieren.

Die Akzeptanzrate beeinflusst die Kosten pro Ergebnis, nicht aber den Preis jedes einzelnen Versuchs. Im vereinfachten Modell bedeutet eine niedrigere Rate, dass im Durchschnitt mehr Versuche pro Akzeptanz erforderlich sind. Dieser Zusammenhang bildet nicht jedes System ab: Es kann Höchstgrenzen für Wiederholungen, alternative Abläufe, manuelle Prüfung oder unterschiedliche Ablehnungsgründe geben. Für die Planung einer realen Anwendung sollten Sie deshalb bevorzugt die aufgezeichneten Versuche und akzeptierten Ergebnisse derselben Stichprobe auswerten.

Auch die Ausgabelänge kann je nach Anfrage und Verhalten der Anwendung variieren. Eine maximale Ausgabelänge ist keine Prognose des durchschnittlichen Verbrauchs. Messen Sie für die Budgetplanung die tatsächlich beobachteten Tokens und behalten Sie das für Sie relevante Perzentil im Blick. Ein Mittelwert kann unzureichend sein, wenn lange Ausgaben häufig auftreten oder nachgelagerte Prozesse verteuern.

Ordnen Sie nicht jeden Fehler pauschal dem Modell zu. Eine Ablehnung kann durch ein strenges Schema, eine unvollständige Eingabe, eine Unterbrechung des Dienstes oder eine Geschäftsregel verursacht werden. Diese Gründe getrennt zu erfassen hilft bei der Wahl einer geeigneten Korrektur. Außerdem verhindert es, dass Probleme der Validierung oder Integration fälschlich als Modell-Wiederholungen verbucht werden.

Wiederholungen, Validierung und menschliche Prüfung

Zu den Inferenzkosten einer akzeptierten Antwort gehören alle Versuche, die bis zum Ergebnis Verbrauch verursacht haben. Wird ein erster Versuch verworfen und anschließend eine neue Antwort angefordert, zählen beide zu den Ausgaben. Wenn Ihre Richtlinie eine Höchstzahl an Wiederholungen festlegt, messen Sie die endgültige Akzeptanzrate und die insgesamt verbrauchten Tokens unter genau dieser Richtlinie. Eine Formel, die unbegrenzte Wiederholungen annimmt, beschreibt diesen Ablauf nicht.

Auch externe Validierung kann Kosten verursachen, ohne das Modell erneut aufzurufen. Eine lokale Formatprüfung benötigt unter Umständen Rechenressourcen; eine Validierung über ein anderes Tool kann Gebühren auslösen; eine manuelle Prüfung beansprucht Arbeitszeit. Vermischen Sie diese Posten nicht mit den Tokens von Claude Haiku 4.5. Erfassen Sie sie separat und legen Sie offen, wie Arbeitszeit in Geld umgerechnet wurde, wenn Sie dafür einen internen Stundensatz verwenden.

Eine menschliche Prüfung kann auf alle Antworten, nur auf eine Stichprobe oder ausschließlich auf unsichere Fälle angewandt werden. Halten Sie jeweils fest, welcher Anteil geprüft wurde, wie viel Zeit die Prüfung beanspruchte und welche Ergebnisse akzeptiert, korrigiert oder verworfen wurden. Ohne solche Angaben lassen sich die Prüfungskosten nicht aus dem API-Tarif ableiten.

Für Teams sind meist zwei Perspektiven besonders nützlich: die Inferenzkosten pro akzeptierter Antwort und die Gesamtkosten pro abgeschlossener Aufgabe. Die erste macht den Modellverbrauch verständlich. Die zweite bezieht die Bestandteile ein, die erforderlich sind, um das Ergebnis im tatsächlichen organisatorischen Kontext bereitzustellen. Beide Kennzahlen sollten denselben Zeitraum, dasselbe Volumen und dieselbe Erfolgsdefinition verwenden.

Vorlage für eine monatliche Projektion

Trennen Sie die Aufgaben nach Typ und schätzen Sie das Monatsvolumen anhand von Nutzungsdaten oder ausdrücklich genannten Annahmen. Erfassen Sie je Aufgabentyp die durchschnittlich beobachteten Eingabe- und Ausgabetokens, die Akzeptanzrate, die Zahl der Versuche pro Ergebnis und den Anteil der Fälle, die geprüft werden müssen. Ändert sich die Aufgabenmischung im Monatsverlauf, verwenden Sie eine Verteilung nach Aufgabentyp statt eines einzigen, ungewichteten Gesamtmittelwerts.

Multiplizieren Sie die erwarteten monatlichen Versuche je Aufgabentyp mit den durchschnittlichen Inferenzkosten pro Versuch und addieren Sie die Ergebnisse. Teilen Sie anschließend die Gesamtausgaben durch die erwartete Zahl akzeptierter Antworten, um die durchschnittlichen Kosten pro nutzbarer Ausgabe zu ermitteln. Für die monatlichen Gesamtkosten des Prozesses addieren Sie separat messbare Ausgaben für Validierung, Prüfung, Tools und Infrastruktur.

Gleichen Sie die Projektion als Kontrolle mit einer Stichprobe realer Datensätze ab. Prüfen Sie, ob der Zeitraum der Tokenmessung mit dem Zeitraum der akzeptierten Antworten übereinstimmt und unvollständige Aufgaben nicht als Erfolg gezählt wurden. Weichen erwartete und beobachtete Kosten voneinander ab, untersuchen Sie zunächst Änderungen bei Aufgabenmix, Ausgabelänge, Wiederholungsrate und angewandtem Tarif, bevor Sie Ihre Annahmen anpassen.

Grenzen der Schätzung und Prüfungen vor der Budgetierung

Die Szenarien in diesem Leitfaden sagen den Verbrauch einer konkreten Anwendung nicht voraus. Die Längen und Akzeptanzraten sind frei gewählte Rechenannahmen. Sie sind weder offizielle Durchschnittswerte noch vergleichende Qualitätsmessungen. Um sie zu ersetzen, benötigen Sie eine eigene Stichprobe, die reale Eingaben, Anweisungen, Einschränkungen, Validierungsregeln und Wiederholungsrichtlinien abbildet.

Auch die Inferenzkosten dürfen nicht als vollständige Kosten einer Aufgabe verstanden werden. Die Beispiele enthalten weder menschliche Prüfung noch kostenpflichtige externe Validierung, Tools, Infrastruktur oder Preismodelle, die vom genannten Standardtarif abweichen. Diese Bestandteile hängen vom Design und vom Zugangskanal der jeweiligen Implementierung ab.

Prüfen Sie vor der Budgetfreigabe erneut die Modellkennung und den Modellstatus, den aktuellen Tarif und den Geltungsbereich des Kanals. Preise können sich ändern. Cache- oder Batch-Preismodelle dürfen nicht ohne Prüfung ihrer Bedingungen mit dem Standardtarif gleichgesetzt werden. Bewahren Sie die verwendete Referenz und das Prüfdatum auf, damit andere Personen die Schätzung nachvollziehen können.

Kurz gesagt: Ein Preis pro Million Tokens erlaubt es, den Verbrauch zu bewerten, bestimmt aber nicht allein die Kosten einer Ausgabe, die Ihr Team verwenden kann. Eingabe- und Ausgabelänge, verworfene Versuche und Akzeptanzrate bestimmen die Inferenzkosten pro Ergebnis. Prüfung und weitere Prozessbestandteile vervollständigen die Betriebskosten. Aussagekräftig ist eine Zahl, die ihren Nenner, ihre Datenbasis und ihre Ausschlüsse offenlegt.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.