Claude Prompt-Caching spart 70% Ihrer Automatisierungskosten ein

Die erste Rechnung von Anthropic für einen meiner Kunden löste eine echte Panik aus. Die Automatisierung funktionierte perfekt: Claude sortierte Support-Tickets rund um die Uhr gegen eine 30-seitige Wissensdatenbank – doch die monatliche Rechnung hatte plötzlich eine zusätzliche Null. Der Grund? Ich hatte Prompt-Caching noch nicht aktiviert.

Ich betreibe mehrere n8n-Workflows in der Produktion, die für Kunden auf Anthropic Claude setzen. Diese Workflows reichen von Lead-Anreicherung über Dokumentenextraktion bis hin zur automatisierten Ticketbearbeitung. Nach der korrekten Implementierung von Prompt-Caching sanken die Input-Token-Kosten in diesem Setup um etwa 70%. Gleichzeitig reduzierte sich die Latenz bei wiederkehrenden Ausführungen spürbar. Dieser Artikel fasst zusammen, was ich mir vor dem ersten Deployment gewünscht hätte.

Warum Prompt-Caching die Kosten drastisch senkt

Prompt-Caching ist eine Funktion von Anthropic, die statische Teile eines Prompts in einem Cache speichert. Bei wiederholten Anfragen mit identischen Prefixen wird der bereits gecachte Inhalt nicht erneut verarbeitet. Stattdessen wird nur der variable Teil des Prompts neu berechnet – was die Kosten und die Antwortzeit deutlich reduziert.

Die Cache-Logik folgt einer festen Reihenfolge: Zuerst werden die Tools verarbeitet, gefolgt vom System-Prompt und schließlich den Nachrichten. Ein cache_control-Marker kann an beliebiger Stelle platziert werden, um den gecachten Bereich zu definieren. Wichtig ist, dass der Cache auf bytegenauer Übereinstimmung basiert. Selbst minimale Änderungen wie ein dynamisches Datum oder eine unsortierte JSON-Struktur invalidieren den Cache sofort.

Die tatsächliche Kostenersparnis im Detail

Die Preismodelle von Anthropic für Prompt-Caching sind nicht intuitiv – und genau hier liegt die größte Überraschung. Der Cache selbst ist nicht kostenlos; das Schreiben in den Cache ist teurer als ein normaler Aufruf. Die Ersparnis entsteht erst durch wiederholte Lesezugriffe auf denselben gecachten Inhalt.

• Normale Input-Tokens: Basispreis (1.0×)
• Cache-Lesezugriff: 0,1× des Basispreises (≈90% Ersparnis)
• Cache-Schreibzugriff (5-Minuten-TTL): 1,25× des Basispreises
• Cache-Schreibzugriff (1-Stunden-TTL): 2,0× des Basispreises

Die Wirtschaftlichkeit hängt davon ab, wie oft der gecachte Bereich wiederverwendet wird:

• 5-Minuten-TTL: Bereits nach einem Lesezugriff lohnt sich der Cache. Ein Schreibzugriff (1,25×) plus ein Lesezugriff (0,1×) kostet insgesamt 1,35× – günstiger als zwei normale Aufrufe (2,0×).
• 1-Stunden-TTL: Mindestens drei Lesezugriffe innerhalb einer Stunde sind nötig, um Kosten zu sparen. Ein Schreibzugriff (2,0×) plus zwei Lesezugriffe (0,2×) summieren sich auf 2,2× – günstiger als drei normale Aufrufe (3,0×).

Die 1-Stunden-TTL eignet sich besonders für Batch-Jobs, die seltener als alle fünf Minuten ausgeführt werden. So vermeidet man, dass der Cache zwischen den Ausführungen verfällt.

Was Sie gecacht halten sollten – und was nicht

Die Entscheidung, welcher Teil eines Prompts gecacht werden soll, ist der wichtigste Faktor für den Erfolg von Prompt-Caching. Der Grundsatz lautet: Stabile Präfixe cachen, variable Teile nachreichen.

Diese Elemente gehören in den gecachten Bereich:

• System-Prompt (Anweisungen, Tonfall, Rolle des Modells)
• Tool-Definitionen (sortiert und deterministisch)
• Wissensdatenbank oder RAG-Kontext (z. B. Produktdokumentation)
• Few-Shot-Beispiele (festgelegte Beispiele für das Modellverhalten)
• Formatvorgaben oder Styleguides

Diese Elemente sollten außerhalb des gecachten Bereichs bleiben:

• Dynamische Nutzerdaten (z. B. Nutzer-ID, Sitzungs-ID)
• Aktuelle Zeitstempel oder Datumsangaben
• Per-Kunde-variable Daten (z. B. Name, Kontostand, Tarif)
• Unsortierte oder nicht-deterministische JSON-Strukturen

Ein häufiger Fehler ist das Einfügen von Variablen wie current_date direkt in den System-Prompt. Dadurch ändert sich der gecachte Bereich täglich, und der Cache invalidiert sich automatisch. Die Lösung: Halten Sie den System-Prompt statisch und übergeben Sie dynamische Daten als separate Nachrichten nach dem gecachten Bereich.

Die Mindestgröße für Prompt-Caching

Prompt-Caching funktioniert nur, wenn die gecachte Präfix eine bestimmte Mindestgröße überschreitet. Unterhalb dieser Grenze akzeptiert das API zwar den cache_control-Marker, gibt aber in der Antwort cache_creation_input_tokens mit dem Wert 0 zurück – der Cache wird also nicht genutzt, ohne dass ein Fehler auftritt.

Mindestgrößen für verschiedene Modelle:

• Claude Opus 4.6 & 4.7: 4.096 Tokens
• Claude Sonnet 4.6: 1.024 Tokens
• Claude Haiku 4.5: 4.096 Tokens

In der Praxis bedeutet das: Wenn Ihr gecachter Bereich zu kurz ist, müssen Sie ihn entweder mit zusätzlichem stabilen Inhalt auffüllen oder auf Prompt-Caching verzichten. Ein Upgrade von Sonnet 4.5 auf Opus 4.7 kann dazu führen, dass ein zuvor funktionierender Cache plötzlich leer bleibt – nur weil die Mindestgröße für das neue Modell höher ist.

Praktisches Beispiel: Automatisierte Ticketbearbeitung mit n8n

Ein typischer Anwendungsfall ist die automatisierte Bearbeitung von Support-Tickets. Jedes neue Ticket wird über einen n8n-Webhook an einen Workflow übergeben. Der Workflow lädt eine 30-seitige Produktdokumentation (≈8.000 Tokens), fügt fünf Few-Shot-Beispiele (≈1.500 Tokens) und einen System-Prompt (≈500 Tokens) hinzu. Anschließend wird die Antwort von Claude Sonnet 4.6 generiert und das Ticket automatisch beantwortet.

Optimierungsschritte:

1. Der System-Prompt und die Tool-Definitionen werden als statisches Präfix gecacht. Nur der eigentliche Ticketinhalt und die Nutzeranfrage werden dynamisch hinzugefügt.
2. Der cache_control-Marker wird nach dem letzten stabilen Block (z. B. nach dem System-Prompt) platziert.
3. Der Workflow stellt sicher, dass die Nachrichtenstruktur byteidentisch bleibt – selbst kleine Änderungen wie ein zusätzlicher Leerraum invalidieren den Cache.

Durch diese Maßnahmen sank die monatliche Rechnung für diesen Workflow von etwa 200 US-Dollar auf rund 30 US-Dollar – eine Ersparnis von 70%. Gleichzeitig reduzierte sich die Antwortzeit, da das Modell weniger Tokens neu verarbeiten musste.

Fazit: Prompt-Caching richtig einsetzen lohnt sich

Prompt-Caching ist eine einfache, aber extrem mächtige Funktion, um die Kosten von KI-gestützten Automatisierungen zu senken. Der Schlüssel zum Erfolg liegt in der korrekten Strukturierung des Prompts und der sorgfältigen Auswahl der gecachten Bereiche. Wer die technischen Details – wie Mindestgrößen, TTL-Wahl und bytegenaue Übereinstimmung – beachtet, kann seine Ausgaben deutlich reduzieren, ohne auf Leistung zu verzichten.

Für Teams, die häufig wiederkehrende Prompts nutzen, lohnt sich ein Test mit Prompt-Caching definitiv. Die ersten Ergebnisse zeigen: Wer die Technik richtig anwendet, spart nicht nur Geld, sondern verbessert auch die Effizienz seiner KI-Workflows.