Prompt Caching in der Praxis: Vorher 280 €, nachher 47 € pro Monat

Redaktion · · 3 Min. Lesezeit

Bei einem unserer Kunden — eine mittelständische Versicherungsplattform — lief seit Februar ein Claude-Sonnet-basierter Assistent für interne Sachbearbeiter. Der Bot beantwortet Produkt- und Tariffragen, basierend auf einem ~25.000-Token-Prompt: System-Anweisungen, Glossar, Tarifregeln, Beispielantworten. Pro Anfrage wird dieser Block komplett mitgesendet, dazu die jeweilige Frage des Sachbearbeiters und ggf. ein paar Kundenstammdaten. Insgesamt 1.200–1.800 Anfragen pro Tag.

Die Februar-Rechnung: 283,40 €. Im März, mit etwas mehr Nutzung: 312,10 €. Das ist nicht dramatisch, aber für ein internes Tool spürbar — und vor allem skaliert es linear mit der Nutzung.

Was wir geändert haben

Im April haben wir Prompt Caching eingeschaltet. Konkret: Den ~25.000-Token-Block am Anfang des Prompts haben wir als cache_control: ephemeral markiert. Der erste Aufruf eines Tages baut den Cache auf (kostet vollen Input-Preis plus 25 % Caching-Aufschlag), alle folgenden Aufrufe innerhalb der 5-Minuten-TTL nutzen den Cache und kosten nur 10 % des regulären Input-Preises für diesen Block.

Die einzige Code-Änderung war ein zusätzliches Feld im API-Aufruf — keine Architektur-Umbauten, kein neuer Service, kein zusätzlicher Cache-Layer auf unserer Seite.

Die Zahlen

| | Februar (ohne Cache) | April (mit Cache) | Differenz | |---|---|---|---| | Anfragen | ~42.000 | ~44.000 | +5 % | | Input-Tokens (regulär) | 1.050 Mio | 88 Mio | -92 % | | Input-Tokens (cache-write) | 0 | 12 Mio | — | | Input-Tokens (cache-read) | 0 | 950 Mio | — | | Output-Tokens | 21 Mio | 23 Mio | +10 % | | Gesamtrechnung | 283 € | 47 € | -83 % |

Output-Tokens sind leicht gestiegen (mehr Anfragen), aber der Hauptkostentreiber Input ist um 92 % eingebrochen. Die 88 Mio regulären Input-Tokens entsprechen den Anfragen, die außerhalb der 5-Minuten-TTL kamen — vor allem morgens und nach längeren Pausen.

Was wir gelernt haben

Cache-TTL ist die wichtigste Stellschraube. Anthropic bietet 5-Minuten-TTL standardmäßig und 1-Stunde-TTL gegen Aufpreis. Bei unserem Lastprofil (kontinuierliche Nutzung tagsüber) reichen die 5 Minuten — aber bei sporadischer Nutzung wäre die 1-Stunde-Variante trotz Aufpreis günstiger.

Cache-Position ist nicht trivial. Der gecachte Block muss am Anfang des Prompts liegen. Wir hatten zunächst Stammdaten vor den 25k-Block gepackt — das brach den Cache bei jeder neuen Anfrage. Stammdaten gehören ans Ende, vor die eigentliche Frage.

Monitoring vorher einrichten. Anthropic loggt Cache-Hit-Raten in der Console. Bei uns lag die nach Tag 2 bei 87 %. Wäre sie unter 50 % geblieben, hätte sich Caching nicht gelohnt — der Schreibaufschlag macht das schnell zum Verlustgeschäft.

Wann es sich nicht lohnt

Wir haben Caching auch bei einem zweiten Kunden getestet: eine Anwendung mit hochvariablen, nutzerspezifischen Prompts ohne stabilen Präfix. Cache-Hit-Rate dort: 12 %. Effekt aufs Bill: +7 % (durch den Schreibaufschlag).

Faustregel aus der Praxis: Lohnt sich, wenn der stabile Prompt-Teil mindestens 1.024 Tokens hat (Anthropic-Mindestgröße), die Cache-Hit-Rate über 60 % zu erwarten ist und derselbe Präfix von vielen aufeinanderfolgenden Anfragen geteilt wird.

Fazit

Prompt Caching ist der mit Abstand effektivste Pricing-Hebel, den wir kennen — wenn das Lastprofil passt. 83 % Ersparnis ohne Architektur-Eingriff sind selten. Wir empfehlen jedem Team, das einen stabilen System-Prompt von ≥ 5.000 Tokens hat, das einmal sauber zu prüfen.

Die anderen Hebel — Tier-Mix, Batch-API — bringen meist 30–60 % Ersparnis und brauchen mehr Aufwand. Caching ist die niedrig hängende Frucht. Mehr zu allen drei Hebeln im Lexikon-Artikel.

Entdecke mehr