Claude Sonnet 4.5 mit Tools: Berechne die Kosten einer Aufgabe, nicht nur eines Aufrufs

Die Kosten eines Aufrufs sind nicht die Kosten einer Aufgabe

Eine Integration kann dem Nutzer nur eine einzige Anfrage anzeigen und trotzdem mehrere Anfragen an Claude senden, bevor die Arbeit erledigt ist. Das Modell kann den Einsatz eines Tools vorschlagen; die Anwendung führt die Aktion aus und gibt das Ergebnis zurück. Anschließend verarbeitet das Modell den Kontext erneut und entscheidet, ob es antworten kann oder ein weiteres Tool benötigt. Um die Kosten der Aufgabe zu schätzen, musst du daher jede Anfrage an das Modell zählen – nicht nur die erste Anfrage oder die abschließende Antwort.

Diese Anleitung stellt eine Tabelle für Claude Sonnet 4.5 vor. Sie trennt Eingabetokens, Ausgabetokens und mögliche Gebühren für serverseitig gehostete Tools. Caching und die Batch API sind nicht enthalten. Außerdem wird nicht angenommen, dass alle Aufgaben gleich viele Runden benötigen: Eine einfache Suche, ein mehrstufiger Ablauf und ein fehlgeschlagener Versuch können unterschiedliche Kosten verursachen.

Die Berechnung bezieht sich auf die Claude API und einen begrenzten Workflow, in dem die Anwendung Tools ausführt. Sie lässt sich nicht ohne Weiteres auf Bedrock, Google Cloud oder eine andere Plattform übertragen: Dort können andere Modellkennungen, Tarife, Abrechnungseinheiten oder Zeitpläne gelten. Für einen Überblick über Preise kannst du den internen Pfad pricing.index heranziehen, für das Modell Claude Sonnet 4.5 und für den Anbieter Anthropic.

Lege Modell, Kanal und Modellkennung fest, bevor du schätzt

Der kommerzielle Modellname reicht nicht aus, um eine Berechnung reproduzierbar zu machen. Für die Claude API unterscheidet die Dokumentation der Modellkennungen zwischen dem Alias claude-sonnet-4-5 und der datierten Version claude-sonnet-4-5-20250929. Die angegebene Lifecycle-Seite führt diese Version als aktiv und nennt den 29. September 2026 als frühestmöglichen Zeitpunkt für ihre Einstellung. Das ist eine nützliche Referenz, aber keine Garantie für die künftige Verfügbarkeit: Prüfe den Status unmittelbar vor der Veröffentlichung oder Wiederverwendung der Tabelle.

Halte auch den Zugangskanal fest. Die Anthropic-Seiten beschreiben entsprechende Modellkennungen für andere Anbieter. Du solltest aber nicht davon ausgehen, dass derselbe Preis, Zeitplan oder dasselbe Nutzungsformat für alle Anbieter gilt. Der in der Tabelle verwendete Tarif muss zum tatsächlich genutzten Kanal und zum Datum der Ausführung passen. Die Preisdokumentation ist die maßgebliche Quelle, um aktuelle Tarife, mögliche regionale Unterschiede und Bedingungen verbundener Plattformen zu prüfen.

Das bereitgestellte Prüfmaterial enthält weder aktuelle Zahlen für Ein- und Ausgabetarife noch den Betrag möglicher regionaler Preisunterschiede. Deshalb werden diese hier nicht als bestätigte Werte angegeben. In der Vorlage bleiben die Tarife editierbare Felder. Ersetze sie durch die Werte aus der für deinen Fall geltenden Dokumentation und notiere das Abrufdatum, bevor du das Ergebnis als Budget verwendest.

Zähle eine vollständige Runde im Tool-Zyklus

Bei clientseitiger Tool-Nutzung kann eine Modellantwort eine Tool-Anforderung enthalten. Die Anwendung führt die Aktion aus und sendet das Tool-Ergebnis in einer späteren Nachricht zurück. Anschließend verarbeitet das Modell den weiteren Verlauf. Dieser Austausch kann sich wiederholen. Eine Nachricht, die ein Tool anfordert, bedeutet noch nicht, dass die Aufgabe abgeschlossen ist.

Zähle für jede Anfrage an das Modell die Eingabe, die bei genau dieser Anfrage tatsächlich übermittelt wurde. Dazu können die Systemnachricht, vorherige Nachrichten, Tool-Definitionen, die Nutzernachricht und frühere Ergebnisse gehören, sofern die Anwendung sie im Kontext beibehalten hat. Wenn eine neue Anfrage frühere Inhalte erneut enthält, gehören diese Inhalte wieder zur Eingabe dieser Anfrage. Zähle ein Tool-Ergebnis erst dann als Modelleingabe, wenn du es tatsächlich an das Modell sendest.

Auch die Ausgabe wird pro Anfrage gezählt. In einer Zwischenrunde kann sie aus einer Tool-Anweisung samt Argumenten bestehen; in der letzten Runde kann sie eine Antwort an den Nutzer sein. Gehe nicht davon aus, dass eine Zwischenausgabe kostenlos ist. Bei Claude Sonnet 4.5 kann die Tool-Nutzung zusätzliche Systemtokens enthalten, die dem ausgewählten Tool zugeordnet sind. Die Anzahl hängt von der Konfiguration ab; die Preisdokumentation ist maßgeblich, um sie zu prüfen. Addiere keinen pauschalen Wert, ohne das verwendete Tool und den Modus zu überprüfen.

Bei serverseitig gehosteten Tools ist eine zusätzliche Trennung nötig. Für ihre Vorgänge können eigene Gebühren anfallen, und manche Abläufe werden intern im Dienst ausgeführt. In diesem Fall entspricht nicht jeder interne Vorgang zwangsläufig einem clientseitig sichtbaren Modellaufruf. Führe daher getrennte Zähler für Modellanfragen und Tool-Vorgänge und rechne jeden Posten nach der jeweils dokumentierten Einheit ab.

Vorlage für die Berechnung pro Runde und pro Aufgabe

Lege in der Tabelle eine Zeile pro Anfrage an das Modell an. Erstelle für Tool-Gebühren eine separate Tabelle oder einen getrennten Abschnitt. Notiere für jede Modellzeile die abrechenbaren Eingabetokens, die abrechenbaren Ausgabetokens sowie den Ein- und Ausgabetarif, jeweils passend zum erfassten Kanal und Datum. Wenn ein gehostetes Tool verwendet wird, erfasse zusätzlich jeden abrechenbaren Vorgang dieses Tools. So kannst du die Kosten einer Aufgabe addieren, ohne verschiedene Einheiten zu vermischen.

Die geschätzten Tokenkosten eines Aufrufs berechnen sich so: (Eingabetokens ÷ Tarifeinheit) × Eingabepreis + (Ausgabetokens ÷ Tarifeinheit) × Ausgabepreis. Die Tarifeinheit muss der vom Anbieter veröffentlichten Einheit entsprechen. Wird der Preis pro Million Tokens angegeben, ist die Einheit eine Million. Für eine Aufgabe addierst du die Ergebnisse aller Modellaufrufe und rechnest gegebenenfalls die Gebühren für Tools separat hinzu.

Ziehe Eingaben nicht theoretisch zusammen, um wiederholten Kontext nur einmal zu zählen. Wenn eine Systemnachricht, ein Tool-Schema oder ein früheres Ergebnis in drei abrechenbaren Anfragen enthalten ist, zählst du den in jeder Anfrage erfassten Verbrauch – selbst wenn der Text identisch ist. Umgekehrt addierst du keine Tokens für Inhalte, die nie übermittelt wurden. Wenn verlässliche Messwerte fehlen, kennzeichne den Wert als Schätzung und gleiche ihn mit dem Tokenzähl-Tool oder den von der API zurückgegebenen Nutzungsdaten ab.

Drei anschauliche Szenarien

Die folgenden Szenarien erklären, wie du die Zählung strukturierst; sie sagen keine allgemeine Nutzung voraus. Die Tokenmengen sind Beispielwerte zum Ausprobieren der Tabelle, keine Messwerte für Claude und keine veröffentlichten Preise. Für reale Geldbeträge ersetzt du die Beispielwerte durch Protokolle deiner Anwendung und Preise, die für deinen Kanal geprüft wurden.

Szenario A: Eine Anfrage wird ohne Tools beantwortet. Zähle die einzelne Anfrage an das Modell einschließlich der gesendeten Nachrichten und des Kontexts sowie die erzeugte Ausgabe. Wenn die Anwendung eine Tool-Definition mitsendet, obwohl das Tool nicht verwendet wird, prüfe den tatsächlichen Inhalt der Anfrage. Gehe nicht davon aus, dass diese Definition kostenlos oder gar nicht vorhanden war. In diesem Fall gibt es eine Modellrunde; daraus folgt aber nicht, dass alle Anfragen im Produkt gleich viel kosten.

Szenario B: Eine Frage erfordert eine Suche. Zähle den ersten Modellaufruf, die Antwort, die das Tool anfordert, den Suchvorgang und den anschließenden Aufruf, der das Ergebnis enthält. Wird ein serverseitig gehostetes Tool verwendet, erfasse seine Gebühr in der von der Dokumentation angegebenen Einheit; rechne sie nicht in Tokens um. Verwendet die Anwendung eine clientseitig eingebundene externe Suche, erfasse die entsprechenden externen Kosten außerhalb der Claude-Tokenrechnung.

Szenario C: Eine Aktion mit mehreren aufeinanderfolgenden Aufrufen oder einem fehlgeschlagenen Versuch. Wenn das erste Tool einen Fehler zurückgibt und die Anwendung das Modell um eine Korrektur bittet, zähle diesen Aufruf und alle folgenden mit. Wird der Ablauf als neuer Versuch neu gestartet, behalte die Kennung des Versuchs bei und addiere dessen Verbrauch zu den Kosten der abgeschlossenen Aufgabe. Nur den erfolgreichen Versuch zu melden, würde die Ausgaben verschleiern, die für das Ergebnis nötig waren.

Welche Variablen das Ergebnis verändern können

Die Zahl der Runden ist häufig eine entscheidende Variable. Eine Aufgabe, die nach der ersten Antwort abgeschlossen ist, kann weniger Aufrufe benötigen als eine, für die drei Modellentscheidungen erforderlich sind. Schreibe den gesamten Unterschied aber nicht dem Modell zu: Er kann von der Anwendungslogik, dem Zustand des Tools, der Datenqualität, der Grenze für Wiederholungsversuche oder dem Erfolgskriterium abhängen.

Auch die Menge des vom Client beibehaltenen Kontexts spielt eine Rolle. Umfangreiche Tool-Definitionen, frühere Nachrichten und große Ergebnisse können die Eingabe späterer Runden erhöhen. Den Verlauf zu kürzen kann den Verbrauch verändern, ist aber nur dann sinnvoll, wenn die für die Aufgabe nötigen Informationen erhalten bleiben. Miss die Wirkung in einem kontrollierten Durchlauf, statt anzunehmen, der Kontext werde automatisch zusammengefasst oder nur einmal berechnet.

Tool-Schemas und zugehörige Systemtokens bilden eine weitere Variable. Die konkrete Anzahl hängt von Tool und Konfiguration ab und sollte deshalb in der Preisdokumentation sowie anhand der gezählten Anfrage überprüft werden. Auch ein umfangreiches Tool-Ergebnis kann die Eingabe des nächsten Aufrufs erhöhen, sofern es an das Modell gesendet wird.

Trenne außerdem fehlgeschlagene Aufgaben, automatische Wiederholungen und vom Nutzer angeforderte Korrekturen. Ein Budget, das auf dem Durchschnitt abgeschlossener Aufgaben beruht, kann die Ausgaben unterschätzen, wenn fehlgeschlagene Versuche fehlen. Es ist sinnvoll, sowohl die Kosten pro Versuch als auch die aggregierten Kosten pro abgeschlossener Aufgabe zu veröffentlichen – zusammen mit Zeitraum und gemessener Ausführungsmenge.

Gleiche die Tabelle mit dem Produktivbetrieb ab und nenne Ausschlüsse

Bewahre für eine Prüfung eine Aufgaben- und Versuchskennung, die Modellkennung, den Kanal, die Nummer jeder Anfrage, die verfügbaren Tools, die an das Modell gesendeten Ergebnisse und die Nutzungsdaten jeder Antwort auf. Protokolliere auch fehlgeschlagene Aufrufe und Vorgänge, die keine brauchbare Antwort ergeben haben. Speichere keine personenbezogenen Daten oder Geheimnisse, die für die Analyse nicht erforderlich sind; Kostenmetriken lassen sich mit pseudonymen internen Kennungen verknüpfen.

Die API-Dokumentation stellt einen Endpunkt zur Tokenzählung bereit, der Nachrichten, Systemanweisungen und Tools berücksichtigt. Er kann helfen, eine Anfrage vor dem Senden zu schätzen. Er ersetzt jedoch nicht den Abgleich mit den zur Laufzeit zurückgegebenen Nutzungsdaten oder der abschließenden Rechnung – insbesondere nicht bei mehreren Runden, Fehlern oder Tool-Gebühren. Verwende die Vorabschätzung zur Planung und die tatsächlichen Protokolle zur Prüfung.

Vergleiche die berechneten Kosten mit der Rechnung für einen gleichartigen Zeitraum und Kanal. Suche bei Abweichungen nach fehlenden Aufrufen, falsch interpretierten Tarifeinheiten, regionalen Unterschieden oder separaten Tool-Gebühren. Halte ausgeschlossene Posten ausdrücklich fest. In dieser Berechnung sind Caching und die Batch API nicht enthalten. Für sie können eigene Berechnungsweisen gelten; füge sie nicht so zur Formel hinzu, als wären sie Teil des Basis-Workflows.

Eine nützliche Zahl ist nicht zwangsläufig eine exakte Vorhersage. Lege die Methode, das Preisdatum, die Aufgabenauswahl, die Zahl der Versuche und die Ausschlüsse offen. Wenn die Stichprobe nur wenig Variation enthält, beschreibe das Ergebnis als Resultat dieser Stichprobe – nicht als typische Kosten beliebiger Aufgaben mit Sonnet 4.5.

Weiter entdecken

Korrekturen und Transparenz

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