Die Rechnung, die im Konzept fehlt
Warum die Kosten einer Chat-Anwendung quadratisch mit der Gesprächslänge wachsen, was Prompt-Caching wirklich spart und weshalb die Modellwahl der letzte Hebel ist, nicht der erste.
Der Denkfehler in der ersten Kalkulation
Die naheliegende Rechnung geht so: Eine Anfrage hat 500 Token Eingabe und 600 Token Antwort, das kostet bei den aktuellen Preisen Bruchteile eines Cents, mal zehntausend Anfragen im Monat – ein überschaubarer Betrag. Diese Rechnung ist fast immer um eine Größenordnung zu niedrig.
Der Grund: Ein Sprachmodell hat kein Gedächtnis. Jede Anfrage in einem Gespräch enthält den vollständigen bisherigen Verlauf noch einmal – System-Prompt, Werkzeugbeschreibungen, alle vorherigen Fragen und Antworten. In der achten Runde eines Gesprächs wird der System-Prompt zum achten Mal bezahlt.
Der mittlere Term ist der entscheidende: Er wächst mit dem Quadrat der Rundenzahl. Anthropic beschreibt denselben Effekt für Agenten-Schleifen so: Eine Aufgabe mit 40 Schritten sendet ihre erste Runde vierzigmal, und die Kosten einer Aufgabe wachsen ungefähr mit dem Quadrat der Schrittzahl.
Ein Zahlenbeispiel: 4.000 Token System-Prompt und Werkzeuge, 8.000 Token Dokumentenkontext, acht Runden mit je 200 Token Frage und 600 Token Antwort. Naive Schätzung: acht mal 12.800 Token, also gut 100.000. Tatsächlich sind es rund 120.000 Input-Token – die Differenz ist der wachsende Verlauf.
Rechner: Token-Verbrauch und Monatskosten
Anfrage-Profil eintragen, Preise prüfen, Betriebsart wählen – der Rechner liefert Token je Sitzung, Kosten mit und ohne Caching, die Hochrechnung auf den Monat und die Aufteilung, wohin das Geld fließt.
Anfrage-Profil
Preise und Betriebsart – Werte prüfen, Preislisten ändern sich
Wohin das Geld fließt
Zu den Preisen: Die Vorlagen enthalten die Listenpreise der Anthropic-API mit Stand Juni 2026. Preise ändern sich, und für andere Anbieter sind die Felder frei ausfüllbar – tragen Sie die Werte aus der jeweils aktuellen Preisliste ein. Wir veröffentlichen hier bewusst keine Fremdanbieter-Tabelle, die in wenigen Wochen falsch wäre.
Prompt-Caching ist der größte Hebel
Da jede Anfrage denselben Anfang wiederholt, lässt sich dieser Anfang zwischenspeichern. Der Anbieter berechnet ihn dann nicht mehr voll, sondern zu einem Bruchteil:
| Vorgang | Faktor auf den Input-Preis |
|---|---|
| Normale Verarbeitung | 1,0 × |
| In den Cache schreiben, 5-Minuten-Speicherdauer | 1,25 × |
| In den Cache schreiben, 1-Stunden-Speicherdauer | 2,0 × |
| Aus dem Cache lesen | 0,1 × |
Daraus folgt der Break-even unmittelbar: Beim 5-Minuten-Cache rechnet sich das Schreiben ab der zweiten Anfrage – 1,25 plus 0,1 ist weniger als zweimal 1,0. Beim 1-Stunden-Cache braucht es drei Anfragen, weil das Schreiben doppelt kostet. Die längere Speicherdauer lohnt nur, wenn zwischen den Anfragen Pausen von mehr als fünf Minuten liegen – etwa weil ein Mensch antwortet.
Wie groß der Effekt in der Praxis ist, hat Anthropic gemessen: Bei Trefferquoten von 81 bis 90 Prozent sanken die Kosten einer Agenten-Schleife um den Faktor 2,5 bis 3,7. Für einen kleinen Triage-Agenten fiel die Rechnung allein durch Caching um 83 Prozent.
Wichtig ist dabei die Reihenfolge im Prompt. Der Cache arbeitet über einen Präfixvergleich: Ein einziges verändertes Byte macht alles ab dieser Stelle ungültig. Stabiles gehört nach vorn, Veränderliches nach hinten.
Die stillen Kostentreiber
Caching einzuschalten genügt nicht – es muss auch greifen. Die typischen Ursachen dafür, dass die Trefferquote bei null liegt, obwohl alles konfiguriert ist:
Ein Zeitstempel im System-Prompt. „Heute ist der 3. September 2026, 14:22 Uhr“ ändert sich bei jeder Anfrage und macht den gesamten nachfolgenden Prompt ungültig. Das Datum gehört ans Ende, nicht an den Anfang.
Eine Werkzeugliste in wechselnder Reihenfolge. Wird sie aus einem Dictionary oder einer Menge erzeugt, kann sich die Reihenfolge zwischen Prozessen unterscheiden – und Werkzeuge stehen im Prompt vor allem anderen.
Modellwechsel mitten im Gespräch. Caches sind an das Modell gebunden. Wer aus Kostengründen zwischen Modellen umschaltet, verliert bei jedem Wechsel den gesamten Cache – und zahlt den Präfix erneut zum vollen Preis.
Nachträgliches Umschreiben der Historie. Jede Verdichtung, jedes Löschen alter Werkzeugergebnisse schreibt den Verlauf neu und erzeugt einen Cache-Fehltreffer. Das kann sich lohnen, aber es ist kein kostenloser Vorgang – in einer von Anthropic dokumentierten Messung kostete zu häufiges Kontext-Aufräumen mehr, als es sparte.
Nachprüfbar ist all das nur an einer Stelle: den Nutzungsdaten der Antwort. Wenn der Zähler für gelesene Cache-Token über wiederholte Anfragen hinweg null bleibt, greift das Caching nicht – unabhängig davon, was im Code steht. Ein Fehler dieser Art meldet sich nie von selbst: Die Anwendung läuft, nur die Rechnung ist höher.
Batch-Verarbeitung: die Hälfte, wenn niemand wartet
Für alles, worauf kein Mensch in Echtzeit wartet – nächtliche Auswertungen, Klassifikation von Eingängen, Anreicherung eines Datenbestands – bieten die Anbieter einen asynchronen Tarif mit 50 Prozent Rabatt. Die Anfragen werden gesammelt und innerhalb eines Zeitfensters abgearbeitet.
Das ist der einfachste Hebel überhaupt, weil er keine Qualität kostet – nur Wartezeit. In der Praxis wird er übersehen, weil die Anwendung nun einmal synchron gebaut wurde. Bei der Architektur lohnt deshalb die Frage, welcher Anteil der Last wirklich interaktiv ist.
Die Modellwahl kommt zuletzt
Der erste Reflex bei einer zu hohen Rechnung ist der Wechsel auf ein kleineres Modell. Das ist der schlechteste Ausgangspunkt, aus drei Gründen.
Erstens sind die kostenlosen Hebel größer. Caching mit Faktor 2,5 bis 3,7 und Batch mit Faktor 2 schlagen den Preisunterschied zwischen zwei Modellgenerationen – und kosten keine Ausgabequalität.
Zweitens ist der Preis je Token nicht der Preis je erledigter Aufgabe. Ein günstigeres Modell, das mehr Runden braucht oder häufiger korrigiert werden muss, ist nicht günstiger. Die sinnvolle Kennzahl sind die Kosten pro abgeschlossener Aufgabe, nicht pro Anfrage.
Drittens gibt es innerhalb eines Modells eine feinere Stellschraube: den Aufwand, den es in die Bearbeitung stecken darf. Ein starkes Modell auf niedriger Stufe erreicht häufig mehr als ein schwaches auf hoher – und bleibt dabei in einem Cache-Namensraum. Eine Kaskade aus mehreren Modellen verliert die Cache-Wiederverwendung zwischen ihnen.
Wenn nach Caching, Batch und Aufwandssteuerung noch Bedarf besteht, ist die Modellwahl der richtige nächste Schritt – dann aber gemessen an einer Testmenge echter Anfragen, nicht nach Gefühl.
Checkliste vor dem Produktivstart
1. Mit echten Prompts rechnen, nicht mit geschätzten Token. Die Anbieter stellen einen Endpunkt zum Zählen bereit; ein Zeichen-durch-vier-Näherung liegt je nach Sprache deutlich daneben.
2. Nutzungsdaten je Anfrage protokollieren. Vier Werte – normale Eingabe, Cache-Schreiben, Cache-Lesen, Ausgabe. Ohne sie ist jede spätere Optimierung Raten.
3. Caching einbauen und nachweisen, dass es greift. Zwei identische Anfragen hintereinander, der zweite Cache-Lesezähler muss größer als null sein.
4. Gesprächslänge begrenzen. Der quadratische Anteil ist der einzige Posten, der ohne Gegenmaßnahme unbegrenzt wächst.
5. Ein Kostenlimit einziehen, bevor die Anwendung öffentlich ist. Eine Endlosschleife im Agenten oder ein Nutzer mit Skript kostet sonst an einem Wochenende mehr als der Rest des Monats.
KI-Architektur und Kostenoptimierung
Wir planen KI-Anwendungen so, dass sie im Betrieb bezahlbar bleiben: Prompt- und Kontextarchitektur mit funktionierendem Caching, Trennung von interaktiver und asynchroner Last, Messung der Nutzungsdaten und eine Testmenge, an der sich Modell- und Aufwandsentscheidungen belegen lassen.
Auch als Prüfung bestehender Anwendungen – wenn die Rechnung höher ist als geplant, liegt die Ursache fast immer in der Prompt-Struktur, nicht im Modellpreis. Das Erstgespräch ist unverbindlich.
Telefon: +49 (0) 176 820 42391
Weiterlesen
KI-Integration & Web-Infrastruktur – wie wir KI in bestehende Anwendungen einbinden.
Hardware-Entwicklung – unsere Apps VERHIKAL OBD und Mevaq-Gym nutzen Sprachmodelle mit Werkzeugzugriff auf dem Gerät.
Alle Engineering Guides
Preise, Cache-Faktoren und der Batch-Rabatt beziehen sich auf die Listenpreise der Anthropic-API mit Stand Juni 2026. Die Angaben zur gemessenen Caching-Ersparnis stammen aus Anthropics eigener Dokumentation. Für andere Anbieter gelten eigene Preise und teils andere Cache-Mechanismen – maßgeblich ist immer die aktuelle Preisliste des jeweiligen Anbieters.