Claude Prompt Caching: Praxis-Guide 2026

Aktualisiert: 21. Juni 2026

Anthropic Prompt Caching senkt die Kosten der Claude API um bis zu 90 % und die Latenz um bis zu 85 %. Statische Prompt-Teile (Systemanweisungen, Tool-Definitionen, lange Kontextdokumente) werden serverseitig zwischengespeichert und bei Folgeanfragen nur noch zu einem Bruchteil des Preises gelesen. In diesem Praxis-Guide für 2026 zeige ich, wie ich Prompt Caching in Produktion einsetze: korrekte Cache-Breakpoints, TTL-Strategie, Modellunterschiede zwischen Opus 4.7, Sonnet 4.6 und Haiku 4.5 sowie konkrete Kostenrechnungen, mit denen sich der Break-even sofort bestimmen lässt.

Kurzer Kontext vorweg: Ich hab im letzten Projekt einen RAG-Bot ausgerollt, der pro Tag ca. 40.000 Anfragen mit identischem 25k-Token-Systemprompt bekommt. Ohne Caching hätte das Sonnet-Setup rund 3.000 $ pro Monat gekostet, mit Caching landen wir bei etwa 380 $. Genau diese Hebel zeige ich hier.

Cache-Reads kosten bei Claude nur 10 % des Basispreises pro Input-Token; Cache-Writes 125 % (5-Minuten-TTL) bzw. 200 % (1-Stunden-TTL).
Mindestgröße eines Cache-Blocks: 1.024 Tokens für Opus 4.7 und Sonnet 4.6, 2.048 Tokens für Haiku 4.5.
Bis zu vier cache_control-Breakpoints pro Request. Am besten platziert nach Tools, System-Prompt, langem Dokument und vorletzter User-Message.
Der Break-even liegt typischerweise bei zwei bis drei Folgeanfragen innerhalb der TTL; danach ist Caching reiner Gewinn.
Der 1-Stunden-Cache (Extended TTL) ist seit 2025 allgemein verfügbar und für agentische Workflows mit längeren Pausen ideal.
Cache-Hits werden im usage-Feld der Response über cache_creation_input_tokens und cache_read_input_tokens ausgewiesen.

Was ist Anthropic Prompt Caching?

Anthropic Prompt Caching ist eine API-Funktion, die wiederkehrende Prompt-Präfixe (also den Teil eines Requests, der sich zwischen Aufrufen nicht ändert) auf Anthropic-Servern zwischenspeichert. Beim nächsten Aufruf mit demselben Präfix wird dieser Teil nicht erneut tokenisiert und vom Modell verarbeitet, sondern aus dem Cache gelesen. Das spart Token-Kosten und Latenz, ohne die Antwortqualität zu verändern, weil der Modellzustand identisch rekonstruiert wird.

Technisch markieren Sie einen Cache-Punkt mit dem Feld cache_control: {"type": "ephemeral"} an einem beliebigen Block (System-Prompt, Tool-Definition, langes Dokument oder User-Message). Alles vor diesem Breakpoint wird gemeinsam als Cache-Eintrag gespeichert. Bei einem Treffer (Hit) zahlen Sie für diese Tokens 0,1× des normalen Input-Preises; bei einem Miss zahlen Sie einmalig 1,25× (für 5-Minuten-TTL), um den Cache zu schreiben.

Im Unterschied zu clientseitigem Embedding-Caching, wie es etwa in einer optimierten RAG-Pipeline zum Einsatz kommt, reduziert Prompt Caching nicht die Anzahl der Aufrufe, sondern die Kosten pro Aufruf bei gleichem Antwortverhalten. Beide Techniken kombinieren sich übrigens exzellent: RAG liefert kompakten Kontext, Caching macht den Systemanteil dieses Kontextes faktisch kostenlos.

Was kostet Prompt Caching bei Claude?

Die Preisstruktur ist für alle Claude-Modelle identisch in Form, unterscheidet sich aber im Basispreis. Cache-Writes sind teurer als ein normaler Input-Token, Cache-Reads dagegen drastisch günstiger. Die folgende Tabelle fasst die Multiplikatoren und die effektiven Preise pro Million Tokens für die wichtigsten Produktionsmodelle in 2026 zusammen.

Modell	Input (Basis)	Cache-Write (5 min, 1,25×)	Cache-Write (1 h, 2,0×)	Cache-Read (0,1×)
Claude Opus 4.7	15,00 $	18,75 $	30,00 $	1,50 $
Claude Sonnet 4.6	3,00 $	3,75 $	6,00 $	0,30 $
Claude Haiku 4.5	1,00 $	1,25 $	2,00 $	0,10 $

Praktisch heißt das: Wird ein 30.000-Token-Systemprompt mit Sonnet 4.6 zehnmal innerhalb von fünf Minuten aufgerufen, kostet er ohne Caching 10 × 30.000 × 3 $ / 1 Mio. = 0,90 $. Mit Caching kostet er einmal 30.000 × 3,75 $ / 1 Mio. = 0,1125 $ Write plus neunmal 30.000 × 0,30 $ / 1 Mio. = 0,081 $ Reads, in Summe 0,1935 $. Das ist eine Ersparnis von 78 %. Bei 100 Aufrufen wachsen die Ersparnisse auf über 87 %.

Der Break-even liegt für den 5-Minuten-Cache bei 1 ÷ (1 − 0,1) × 0,25 = 0,28 zusätzlichen Reads, also bereits beim zweiten Aufruf positiv. Für den 1-Stunden-Cache mit Multiplikator 2,0× benötigen Sie ungefähr 1,11 zusätzliche Reads, ebenfalls schon nach dem zweiten Hit.

Minimales Beispiel mit dem Python-SDK

Hier ein lauffähiges Beispiel mit dem offiziellen anthropic-Paket (Version 0.45+). Wir senden ein langes Referenzdokument einmal mit Cache-Marker und dann mehrere Folgefragen. Jede Folgeanfrage liest den Kontext aus dem Cache.

import anthropic

client = anthropic.Anthropic()

# Statisches Referenzdokument (z. B. API-Dokumentation, Vertrag, Codebase-Snapshot)
with open("policy.md", "r", encoding="utf-8") as f:
    long_context = f.read()  # >1024 Tokens, sonst greift Caching nicht

system_blocks = [
    {
        "type": "text",
        "text": "Du bist ein Compliance-Assistent. Antworte ausschließlich auf Basis des Dokuments.",
    },
    {
        "type": "text",
        "text": long_context,
        "cache_control": {"type": "ephemeral"},  # Breakpoint: alles oberhalb wird gecached
    },
]

def ask(question: str) -> dict:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=512,
        system=system_blocks,
        messages=[{"role": "user", "content": question}],
    )
    return {
        "answer": response.content[0].text,
        "cache_write": response.usage.cache_creation_input_tokens,
        "cache_read": response.usage.cache_read_input_tokens,
        "input": response.usage.input_tokens,
        "output": response.usage.output_tokens,
    }

print(ask("Welche Datenkategorien dürfen wir verarbeiten?"))
print(ask("Gilt das auch für Drittstaatentransfers?"))
print(ask("Wie lange ist die Aufbewahrungsfrist?"))

Beim ersten Aufruf sehen Sie cache_creation_input_tokens > 0 und cache_read_input_tokens = 0. Ab dem zweiten Aufruf kehrt sich das Verhältnis um. Wichtig: alles vor dem Breakpoint muss exakt byte-identisch bleiben. Schon ein zusätzliches Leerzeichen invalidiert den Cache. (Diesen Bug hatte ich beim ersten Rollout selbst, weil ein Logging-Decorator unbemerkt einen Timestamp in den System-Prompt gefriemelt hatte.)

Cache-Breakpoints richtig platzieren

Die API erlaubt bis zu vier cache_control-Marker pro Request. In der Praxis ist die stabilste Anordnung von oben nach unten: (1) hinter den Tool-Definitionen, (2) hinter dem statischen System-Prompt-Block, (3) hinter einem großen Kontextdokument und (4) hinter der vorletzten Assistant-Message in mehrstufigen Konversationen. Dadurch entstehen geschachtelte Cache-Einträge, von denen Anthropic immer den längsten passenden Präfix wählt.

Reihenfolge: Statisches zuerst, Dynamisches zuletzt

Anthropic cached immer den Präfix. Alles, was sich häufig ändert, gehört deshalb ans Ende des Requests, idealerweise in die letzte User-Message. Wenn Sie etwa pro Anfrage einen Zeitstempel mitschicken, gehört dieser nicht in den System-Prompt, sondern in die User-Message nach dem letzten Cache-Marker. Sonst wird der gesamte Cache bei jedem Aufruf invalidiert.

Tool-Definitionen separat cachen

Tool-Schemas sind oft 5.000–20.000 Tokens lang und ändern sich selten. Setzen Sie deshalb den ersten Breakpoint nach dem tools-Array. Das funktioniert besonders gut in Kombination mit einem eigenen MCP-Server, dessen Tool-Liste in jeder Session konstant bleibt. Die Definitionen werden faktisch zum Nulltarif mitgeladen.

5-Minuten- vs. 1-Stunden-Cache

Standardmäßig hält Anthropic Cache-Einträge fünf Minuten ab dem letzten Treffer. Seit 2025 ist zusätzlich ein 1-Stunden-Cache (Extended TTL) allgemein verfügbar. Sie aktivieren ihn pro Breakpoint:

{
  "type": "text",
  "text": long_context,
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

Der 1-Stunden-Cache kostet beim Schreiben das Doppelte des Basispreises (statt 1,25×), Reads bleiben bei 0,1×. Er lohnt sich, wenn zwischen Aufrufen Pausen von mehr als fünf Minuten liegen, typisch für Batch-Workflows, nächtliche Analysen oder agentische Pipelines mit menschlicher Freigabe zwischen Schritten. Für hochfrequente Chat-Workloads ist der 5-Minuten-Cache fast immer günstiger.

Wann lohnt sich welche TTL?

Faustregel: Liegt der erwartete Abstand zwischen zwei Treffern unter vier Minuten, ist der 5-Minuten-Cache optimal. Liegt er zwischen fünf und sechzig Minuten, gewinnt der 1-Stunden-Cache. Bei längeren Pausen lohnt sich kein Caching mehr; dann sollten Sie auf clientseitige Caches (z. B. Redis mit eigener Antwort-Hash-Strategie) wechseln.

Welche Modelle unterstützen Prompt Caching?

Prompt Caching ist in 2026 für alle aktuellen Produktionsmodelle verfügbar: Claude Opus 4.7, Sonnet 4.6 und Haiku 4.5. Frühere Modelle der 3.x-Reihe werden weiterhin unterstützt, gelten aber als Legacy. Die wichtigsten Unterschiede:

Opus 4.7 / Sonnet 4.6: Mindestens 1.024 Tokens pro Cache-Block. Unterhalb dieser Schwelle wird der Block nicht gecached und Sie zahlen nur den Basispreis. Kein Risiko, aber auch kein Nutzen.
Haiku 4.5: Mindestens 2.048 Tokens pro Cache-Block. Bei sehr kurzen System-Prompts lohnt sich Caching mit Haiku deshalb seltener.
Fable 5: Unterstützt Caching ebenfalls; Schwellen folgen der Sonnet-Klasse.

Die offiziellen Schwellen und unterstützten Felder dokumentiert Anthropic in den Prompt-Caching-Docs. Cachen lassen sich Text-, Tool-, Image- und Document-Blöcke; PDF-Inhalte werden seit Mitte 2025 ebenfalls als Cache-fähig behandelt.

Caching in Agenten- und Tool-Use-Workflows

In agentischen Workflows wächst die Konversation mit jeder Tool-Ausführung. Ideal für Caching, wenn man die Breakpoints diszipliniert wandern lässt. Mein bewährtes Schema: Tools mit statischem Breakpoint, System-Prompt mit statischem Breakpoint, und ein dynamischer Breakpoint auf der zweitletzten Message. Bei jedem neuen Turn rückt der dynamische Breakpoint nach unten.

def build_messages(history, new_user_msg):
    msgs = []
    for i, m in enumerate(history):
        # vorletzte Nachricht erhält den wandernden Cache-Punkt
        if i == len(history) - 1 and m["role"] == "assistant":
            msgs.append({
                "role": m["role"],
                "content": [{
                    "type": "text",
                    "text": m["content"],
                    "cache_control": {"type": "ephemeral"},
                }],
            })
        else:
            msgs.append(m)
    msgs.append({"role": "user", "content": new_user_msg})
    return msgs

Wer Agenten orchestriert, sollte zusätzlich die Framework-Wahl im Blick behalten: LangGraph und CrewAI exponieren die Anthropic-Cache-Parameter direkt; AutoGen benötigt aktuell einen Custom-Client, um Cache-Marker durchzureichen.

Cache-Hits messen und überwachen

Jede API-Antwort enthält im usage-Block die Felder cache_creation_input_tokens und cache_read_input_tokens. Diese Werte sollten Sie pro Request loggen und in einer Zeitreihe aggregieren. Eine sinnvolle Ziel-KPI ist die Cache-Hit-Quote = Cache-Reads ÷ (Cache-Reads + Cache-Writes + Non-Cached-Input). Unter 60 % gibt es fast immer Optimierungspotenzial.

Für Tracing in Produktion empfiehlt sich ein Setup mit Langfuse als LLM-Observability: die SDKs erfassen die usage-Felder automatisch und stellen Dashboards für Cache-Effizienz, Kosten pro Request und Latenzverteilung bereit. Alternativ können Sie OpenTelemetry-Spans manuell mit Attributen wie anthropic.cache.read_tokens annotieren und an ein beliebiges Backend senden.

Beispielmetrik: Effektiver Input-Preis

Ich berechne pro Request einen effektiven Input-Preis: (input × 1 + cache_write × 1.25 + cache_read × 0.1) ÷ (input + cache_write + cache_read) × base_price. Liegt dieser Wert unter 0,2 × Basispreis, läuft das Caching effizient; über 0,5 × deutet auf zu viele Misses hin, meist verursacht durch instabile Präfixe.

Typische Fehler und wie ich sie vermeide

Die häufigsten Fehler, die ich bei Code-Reviews sehe, lassen sich auf drei Muster reduzieren. Erstens: dynamische Inhalte (Zeitstempel, User-IDs, Locale-Strings) wandern in den System-Prompt und brechen den Cache. Lösung: alles Variable in die letzte User-Message verschieben. Zweitens: Entwickler setzen den Cache-Marker auf einen Block unter der 1.024-Token-Schwelle und wundern sich, warum keine Reads erscheinen. Lösung: Cache-Block bewusst groß halten oder mehrere kleine Texte konkatenieren.

Drittens: bei sehr großen Tool-Listen werden alle vier Breakpoints für Tool-Schemas verbraten, sodass für den eigentlichen Kontext keiner mehr übrig bleibt. Lösung: Tools serverseitig in eine kompakte, gemeinsam gecachte Definition zusammenführen, etwa per MCP-Server, wie im offiziellen Anthropic Python-SDK demonstriert.

Häufig gestellte Fragen

Wann lohnt sich Anthropic Prompt Caching wirklich?

Bereits ab dem zweiten Cache-Treffer innerhalb der TTL ist Caching günstiger als ein nicht gecachter Request. In der Praxis lohnt es sich für alle Workloads mit statischem Kontext >1.024 Tokens und mindestens zwei Anfragen alle fünf Minuten, also Chatbots, RAG-Antwortsysteme, Agenten und Batch-Verarbeitung.

Wie lange bleibt ein Cache-Eintrag aktiv?

Standardmäßig fünf Minuten ab dem letzten Treffer; jeder Hit verlängert die TTL. Mit "ttl": "1h" erhalten Sie einen 1-Stunden-Cache, der bei höherem Schreibpreis (2,0×) längere Pausen zwischen Treffern überbrückt.

Welche Claude-Modelle unterstützen Prompt Caching?

Alle aktuellen Produktionsmodelle: Opus 4.7, Sonnet 4.6, Haiku 4.5 sowie Fable 5. Opus und Sonnet erfordern mindestens 1.024 Tokens pro Cache-Block, Haiku mindestens 2.048 Tokens. Legacy-Modelle der 3.x-Reihe werden ebenfalls noch unterstützt.

Was passiert, wenn sich der gecachte Text minimal ändert?

Der Cache wird invalidiert und es entsteht ein neuer Eintrag mit Cache-Write-Kosten. Schon ein einzelnes Leerzeichen vor dem Breakpoint reicht aus. Halten Sie deshalb alles vor dem Marker byte-identisch und verschieben Sie variable Inhalte hinter den letzten Breakpoint.

Lassen sich Prompt Caching und Batch-API kombinieren?

Ja. Die Message Batches API ist mit Prompt Caching kompatibel, der zusätzliche Batch-Rabatt (50 %) wird unabhängig auf Input und Cache-Operationen angewendet. Für nächtliche Analysejobs ist die Kombination aus 1-Stunden-Cache und Batch-API die kostengünstigste Variante in 2026.