Prinzip
Wenn Sie einen Request mit aktiviertem Prompt Caching senden, prüft das System, ob das Prompt-Präfix aus kürzlich erfolgten Abfragen bereits gecached wurde. Wird es gefunden, wird der Cache verwendet, wodurch Verarbeitungszeit und Kosten sinken. Andernfalls wird der vollständige Prompt verarbeitet und das Präfix nach Beginn der Antwort gecached. Dies ist besonders nützlich in folgenden Szenarien:- Prompts mit zahlreichen Beispielen
- Umfangreicher Kontext oder Hintergrundinformationen
- Wiederkehrende Aufgaben mit gleichbleibenden Anweisungen
- Lange Multi-Turn-Konversationen
Kernmechanismus
Verschiedene Modellanbieter bieten unterschiedliche Caching-Unterstützung:Automatisches Caching
Automatisches Caching erfordert keine zusätzliche Konfiguration; das System erkennt und cached wiederverwendbare Inhalte automatisch. Anwendbar auf Modelle wie OpenAI, DeepSeek usw.OpenAI
- Mindest-Prompt-Länge: 1024 Token; automatischer Hit bei Zeichen für Zeichen identischem Präfix
- Modelle vor GPT-5.6: Cache-Writes werden nicht separat abgerechnet; Cache-Reads kosten den Cache-Lesepreis des jeweiligen Modells
- GPT-5.6 und neuer (offizielle Angabe “GPT-5.6 models and later model families”, derzeit gpt-5.6-sol / terra / luna): Cache-Writes werden mit dem 1,25-Fachen des Inputpreises abgerechnet, Reads mit dem 0,1-Fachen; neu sind die Parameter
prompt_cache_keyund explizite Cache-Breakpoints - Nutzung, Abrechnung und Fehlersuche bei Cache-Misses siehe GPT Prompt Caching
Gemini
- Implizites Kontext-Caching ist standardmäßig aktiviert und ohne manuelle Konfiguration automatisch wirksam.
- Caching greift nur, wenn Inhalt, Modell und Parameter identisch sind; jede Abweichung wird als neuer Request behandelt und trifft den Cache nicht.
- Die Cache-Gültigkeit wird vom Entwickler festgelegt; sie kann auch leer bleiben. Ohne Angabe gilt standardmäßig 1 Stunde. Es gibt keine minimale oder maximale Dauerbegrenzung; die Kosten hängen von der Anzahl der gecachten Token und der Cache-Dauer ab.
DeepSeek / Grok / Moonshot / Groq
- Kosten: Das Schreiben in den Cache ist kostenlos oder zum gleichen Preis; das Lesen aus dem Cache liegt unter dem Originalpreis
Explizites Caching bei Claude-Modellen
- Aktivierung über
cache_control: Feld auf oberster Ebene des Request-Bodys für automatische Breakpoints (verschieben sich mit der Konversation nach vorn) oder auf Inhaltsblock-Ebene für präzise Kontrolle der Cache-Position - Alle aktiven Claude-Modelle werden unterstützt; Cache-Writes kosten das 1,25-Fache (5-Minuten-Cache) bzw. das 2-Fache (1-Stunden-Cache), Reads das 0,1-Fache – die Faktoren gelten einheitlich für die gesamte Reihe
- Anwendbar auf Anthropic-Claude-Modelle
Claude legt die Mindestschwelle an cachebaren Token je Modell fest (512 / 1.024 / 2.048 / 4.096, nicht proportional zur Versionsnummer): Claude Opus 4.8 = 1.024, Claude Opus 4.7 = 2.048, Claude Opus 4.6 / 4.5 und Claude Haiku 4.5 = 4.096, Claude Fable 5 = 512. Ein Präfix unterhalb der Schwelle wird auch mit gesetztem
cache_control nicht in den Cache geschrieben und löst keinen Fehler aus – erkennbar daran, dass in der Antwort cache_creation_input_tokens und cache_read_input_tokens gleichzeitig 0 sind. Die vollständige Staffelung und Fehlersuche finden Sie unter Claude Prompt Caching.OpenAI-kompatible Schnittstelle
Sie können insystem, user (einschließlich Bildern) und tools mit dem Feld cache_control Caching-Breakpoints setzen. Die folgenden Beispiele zeigen nur die wesentliche Struktur:
System-Message-Caching (Standard 5 Minuten TTL):
cache_control auf der obersten Ebene des Tool-Objekts (auf gleicher Ebene wie type und function):
Anthropic-kompatible Schnittstelle
Cache-Dauer
- Standard: 5 Minuten
- Optional: 1 Stunde (“ttl”: “1h”)
Weitere Informationen finden Sie unter: Claude Prompt Caching
Nutzungsempfehlungen
- Stabile Präfixe beibehalten
- Große Texte cachen
- RAG-Daten
- Lange Texte
- CSV-/JSON-Daten
- Rolleneinstellungen
- TTL steuern
- Kurze Sessions → 5 Minuten
- Lange Sessions → 1 Stunde (kosteneffizienter)
- Cache-Writes reduzieren