Prompt-Caching

Prompt-Caching optimiert Ihre API-Nutzung, indem es das Fortsetzen von bestimmten Präfixen in Ihren Prompts ermöglicht. Dies reduziert die Verarbeitungszeit und Kosten für repetitive Aufgaben oder Prompts mit konsistenten Elementen erheblich.

Es gibt zwei Möglichkeiten, Prompt-Caching zu aktivieren:

• Automatisches Caching: Fügen Sie ein einzelnes cache_control-Feld auf der obersten Ebene Ihrer Anfrage hinzu. Das System wendet den Cache-Breakpoint automatisch auf den letzten cachefähigen Block an und verschiebt ihn vorwärts, wenn Gespräche wachsen. Am besten für mehrstufige Gespräche geeignet, bei denen der wachsende Nachrichtenverlauf automatisch gecacht werden soll.
• Explizite Cache-Breakpoints: Platzieren Sie cache_control direkt auf einzelnen Inhaltsblöcken für eine feinkörnige Kontrolle darüber, was genau gecacht wird.

Der einfachste Einstieg ist das automatische Caching:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    "messages": [
      {
        "role": "user",
        "content": "Analyze the major themes in Pride and Prejudice."
      }
    ]
  }'

Beim automatischen Caching speichert das System alle Inhalte bis einschließlich des letzten cachefähigen Blocks. Bei nachfolgenden Anfragen mit demselben Präfix wird der gecachte Inhalt automatisch wiederverwendet.

Wie Prompt-Caching funktioniert

Wenn Sie eine Anfrage mit aktiviertem Prompt-Caching senden:

1. Das System prüft, ob ein Prompt-Präfix bis zu einem bestimmten Cache-Breakpoint bereits aus einer kürzlichen Abfrage gecacht ist.
2. Falls gefunden, wird die gecachte Version verwendet, was die Verarbeitungszeit und Kosten reduziert.
3. Andernfalls wird der vollständige Prompt verarbeitet und das Präfix gecacht, sobald die Antwort beginnt.

Dies ist besonders nützlich für:

• Prompts mit vielen Beispielen
• Große Mengen an Kontext oder Hintergrundinformationen
• Repetitive Aufgaben mit konsistenten Anweisungen
• Lange mehrstufige Gespräche

Standardmäßig hat der Cache eine Lebensdauer von 5 Minuten. Der Cache wird ohne zusätzliche Kosten jedes Mal aktualisiert, wenn der gecachte Inhalt verwendet wird.

Preisgestaltung

Prompt-Caching führt eine neue Preisstruktur ein. Die folgende Tabelle zeigt den Preis pro Million Tokens für jedes unterstützte Modell:

Unterstützte Modelle

Prompt-Caching (sowohl automatisch als auch explizit) wird derzeit unterstützt auf:

• Claude Opus 4.6
• Claude Opus 4.5
• Claude Opus 4.1
• Claude Opus 4
• Claude Sonnet 4.6
• Claude Sonnet 4.5
• Claude Sonnet 4
• Claude Sonnet 3.7 (veraltet)
• Claude Haiku 4.5
• Claude Haiku 3.5 (veraltet)
• Claude Haiku 3

Automatisches Caching

Automatisches Caching ist die einfachste Möglichkeit, Prompt-Caching zu aktivieren. Anstatt cache_control auf einzelne Inhaltsblöcke zu setzen, fügen Sie ein einzelnes cache_control-Feld auf der obersten Ebene Ihres Anfrage-Bodys hinzu. Das System wendet den Cache-Breakpoint automatisch auf den letzten cachefähigen Block an.

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant that remembers our conversation.",
    "messages": [
      {"role": "user", "content": "My name is Alex. I work on machine learning."},
      {"role": "assistant", "content": "Nice to meet you, Alex! How can I help with your ML work today?"},
      {"role": "user", "content": "What did I say I work on?"}
    ]
  }'

Wie automatisches Caching in mehrstufigen Gesprächen funktioniert

Beim automatischen Caching bewegt sich der Cache-Punkt automatisch vorwärts, wenn Gespräche wachsen. Jede neue Anfrage speichert alles bis zum letzten cachefähigen Block, und vorheriger Inhalt wird aus dem Cache gelesen.

Der Cache-Breakpoint bewegt sich automatisch zum letzten cachefähigen Block in jeder Anfrage, sodass Sie keine cache_control-Markierungen aktualisieren müssen, wenn das Gespräch wächst.

TTL-Unterstützung

Standardmäßig verwendet automatisches Caching eine 5-Minuten-TTL. Sie können eine 1-Stunden-TTL zum 2-fachen des Basis-Eingabe-Token-Preises angeben:

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

Kombination mit Block-Level-Caching

Automatisches Caching ist kompatibel mit expliziten Cache-Breakpoints. Bei gemeinsamer Verwendung belegt der automatische Cache-Breakpoint einen der 4 verfügbaren Breakpoint-Slots.

Dies ermöglicht die Kombination beider Ansätze. Verwenden Sie beispielsweise explizite Breakpoints, um Ihren System-Prompt und Tools unabhängig zu cachen, während automatisches Caching das Gespräch verwaltet:

{
  "model": "claude-opus-4-6",
  "max_tokens": 1024,
  "cache_control": {"type": "ephemeral"},
  "system": [
    {
      "type": "text",
      "text": "You are a helpful assistant.",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [...]
}

Was gleich bleibt

Automatisches Caching verwendet dieselbe zugrunde liegende Caching-Infrastruktur. Preisgestaltung, Mindest-Token-Schwellenwerte, Anforderungen an die Kontextreihenfolge und das 20-Block-Lookback-Fenster gelten genauso wie bei expliziten Breakpoints.

Randfälle

• Wenn der letzte Block bereits ein explizites cache_control mit derselben TTL hat, ist automatisches Caching ein No-Op.
• Wenn der letzte Block ein explizites cache_control mit einer anderen TTL hat, gibt die API einen 400-Fehler zurück.
• Wenn bereits 4 explizite Block-Level-Breakpoints vorhanden sind, gibt die API einen 400-Fehler zurück (keine Slots mehr für automatisches Caching).
• Wenn der letzte Block nicht als automatisches Cache-Breakpoint-Ziel geeignet ist, geht das System stillschweigend rückwärts, um den nächsten geeigneten Block zu finden. Wenn keiner gefunden wird, wird das Caching übersprungen.

Explizite Cache-Breakpoints

Für mehr Kontrolle über das Caching können Sie cache_control direkt auf einzelne Inhaltsblöcke setzen. Dies ist nützlich, wenn Sie verschiedene Abschnitte cachen müssen, die sich mit unterschiedlichen Häufigkeiten ändern, oder wenn Sie eine feinkörnige Kontrolle darüber benötigen, was genau gecacht wird.

Strukturierung Ihres Prompts

Platzieren Sie statischen Inhalt (Tool-Definitionen, Systemanweisungen, Kontext, Beispiele) am Anfang Ihres Prompts. Markieren Sie das Ende des wiederverwendbaren Inhalts für das Caching mit dem Parameter cache_control.

Cache-Präfixe werden in folgender Reihenfolge erstellt: tools, system, dann messages. Diese Reihenfolge bildet eine Hierarchie, bei der jede Ebene auf den vorherigen aufbaut.

Wie die automatische Präfix-Prüfung funktioniert

Sie können nur einen Cache-Breakpoint am Ende Ihres statischen Inhalts verwenden, und das System findet automatisch die längste übereinstimmende Sequenz gecachter Blöcke. Das Verständnis dieser Funktionsweise hilft Ihnen, Ihre Caching-Strategie zu optimieren.

Drei Kernprinzipien:

1. Cache-Schlüssel sind kumulativ: Wenn Sie einen Block explizit mit cache_control cachen, wird der Cache-Hash-Schlüssel durch sequenzielles Hashing aller vorherigen Blöcke im Gespräch generiert. Das bedeutet, dass der Cache für jeden Block von allen vorherigen Inhalten abhängt.

2. Rückwärts-sequenzielle Prüfung: Das System prüft Cache-Treffer, indem es rückwärts von Ihrem expliziten Breakpoint arbeitet und jeden vorherigen Block in umgekehrter Reihenfolge prüft. Dies stellt sicher, dass Sie den längstmöglichen Cache-Treffer erhalten.

3. 20-Block-Lookback-Fenster: Das System prüft nur bis zu 20 Blöcke vor jedem expliziten cache_control-Breakpoint. Nach der Prüfung von 20 Blöcken ohne Übereinstimmung stoppt es die Prüfung und geht zum nächsten expliziten Breakpoint (falls vorhanden) über.

Beispiel: Das Lookback-Fenster verstehen

Betrachten Sie ein Gespräch mit 30 Inhaltsblöcken, bei dem Sie cache_control nur auf Block 30 setzen:

• Wenn Sie Block 31 ohne Änderungen an vorherigen Blöcken senden: Das System prüft Block 30 (Treffer!). Sie erhalten einen Cache-Treffer bei Block 30, und nur Block 31 muss verarbeitet werden.

• Wenn Sie Block 25 ändern und Block 31 senden: Das System prüft rückwärts von Block 30 → 29 → 28... → 25 (kein Treffer) → 24 (Treffer!). Da Block 24 sich nicht geändert hat, erhalten Sie einen Cache-Treffer bei Block 24, und nur die Blöcke 25-30 müssen neu verarbeitet werden.

• Wenn Sie Block 5 ändern und Block 31 senden: Das System prüft rückwärts von Block 30 → 29 → 28... → 11 (Prüfung Nr. 20). Nach 20 Prüfungen ohne Treffer stoppt es die Suche. Da Block 5 außerhalb des 20-Block-Fensters liegt, tritt kein Cache-Treffer auf und alle Blöcke müssen neu verarbeitet werden. Wenn Sie jedoch einen expliziten cache_control-Breakpoint auf Block 5 gesetzt hätten, würde das System von diesem Breakpoint aus weiterprüfen: Block 5 (kein Treffer) → Block 4 (Treffer!). Dies ermöglicht einen Cache-Treffer bei Block 4 und zeigt, warum Sie Breakpoints vor bearbeitbaren Inhalten setzen sollten.

Wichtige Erkenntnis: Setzen Sie immer einen expliziten Cache-Breakpoint am Ende Ihres Gesprächs, um Ihre Chancen auf Cache-Treffer zu maximieren. Setzen Sie außerdem Breakpoints direkt vor Inhaltsblöcken, die möglicherweise bearbeitbar sind, um sicherzustellen, dass diese Abschnitte unabhängig gecacht werden können.

Wann mehrere Breakpoints verwendet werden sollten

Sie können bis zu 4 Cache-Breakpoints definieren, wenn Sie:

• Verschiedene Abschnitte cachen möchten, die sich mit unterschiedlichen Häufigkeiten ändern (z. B. Tools ändern sich selten, aber der Kontext wird täglich aktualisiert)
• Mehr Kontrolle darüber haben möchten, was genau gecacht wird
• Caching für Inhalte mehr als 20 Blöcke vor Ihrem letzten Breakpoint sicherstellen möchten
• Breakpoints vor bearbeitbaren Inhalten platzieren möchten, um Cache-Treffer auch bei Änderungen außerhalb des 20-Block-Fensters zu garantieren

Kosten von Cache-Breakpoints verstehen

Cache-Breakpoints selbst verursachen keine zusätzlichen Kosten. Sie zahlen nur für:

• Cache-Schreibvorgänge: Wenn neuer Inhalt in den Cache geschrieben wird (25% mehr als Basis-Eingabe-Tokens für 5-Minuten-TTL)
• Cache-Lesevorgänge: Wenn gecachter Inhalt verwendet wird (10% des Basis-Eingabe-Token-Preises)
• Reguläre Eingabe-Tokens: Für nicht gecachten Inhalt

Das Hinzufügen weiterer cache_control-Breakpoints erhöht Ihre Kosten nicht – Sie zahlen weiterhin denselben Betrag basierend darauf, welcher Inhalt tatsächlich gecacht und gelesen wird. Die Breakpoints geben Ihnen lediglich die Kontrolle darüber, welche Abschnitte unabhängig gecacht werden können.

Caching-Strategien und Überlegungen

Cache-Einschränkungen

Die minimale cachefähige Prompt-Länge beträgt:

• 4096 Tokens für Claude Opus 4.6, Claude Opus 4.5
• 2048 Tokens für Claude Sonnet 4.6
• 1024 Tokens für Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4 und Claude Sonnet 3.7 (veraltet)
• 4096 Tokens für Claude Haiku 4.5
• 2048 Tokens für Claude Haiku 3.5 (veraltet) und Claude Haiku 3

Kürzere Prompts können nicht gecacht werden, auch wenn sie mit cache_control markiert sind. Alle Anfragen zum Cachen von weniger als dieser Anzahl von Tokens werden ohne Caching verarbeitet. Um zu sehen, ob ein Prompt gecacht wurde, lesen Sie die Antwort-Nutzungs-Felder.

Beachten Sie bei gleichzeitigen Anfragen, dass ein Cache-Eintrag erst nach Beginn der ersten Antwort verfügbar wird. Wenn Sie Cache-Treffer für parallele Anfragen benötigen, warten Sie auf die erste Antwort, bevor Sie nachfolgende Anfragen senden.

Derzeit ist "ephemeral" der einzige unterstützte Cache-Typ, der standardmäßig eine Lebensdauer von 5 Minuten hat.

Was gecacht werden kann

Die meisten Blöcke in der Anfrage können gecacht werden. Dazu gehören:

• Tools: Tool-Definitionen im tools-Array
• System-Nachrichten: Inhaltsblöcke im system-Array
• Text-Nachrichten: Inhaltsblöcke im messages.content-Array, sowohl für Benutzer- als auch für Assistenten-Turns
• Bilder & Dokumente: Inhaltsblöcke im messages.content-Array, in Benutzer-Turns
• Tool-Verwendung und Tool-Ergebnisse: Inhaltsblöcke im messages.content-Array, in beiden Benutzer- und Assistenten-Turns

Jedes dieser Elemente kann gecacht werden, entweder automatisch oder durch Markierung mit cache_control.

Was nicht gecacht werden kann

Während die meisten Anfrage-Blöcke gecacht werden können, gibt es einige Ausnahmen:

• Thinking-Blöcke können nicht direkt mit cache_control gecacht werden. Thinking-Blöcke KÖNNEN jedoch zusammen mit anderen Inhalten gecacht werden, wenn sie in vorherigen Assistenten-Turns erscheinen. Wenn sie auf diese Weise gecacht werden, zählen sie als Eingabe-Tokens, wenn sie aus dem Cache gelesen werden.

• Sub-Inhaltsblöcke (wie Zitate) können nicht direkt gecacht werden. Cachen Sie stattdessen den übergeordneten Block.

  Im Fall von Zitaten können die übergeordneten Dokument-Inhaltsblöcke, die als Quellmaterial für Zitate dienen, gecacht werden. Dies ermöglicht die effektive Verwendung von Prompt-Caching mit Zitaten durch das Cachen der Dokumente, auf die Zitate verweisen werden.

• Leere Text-Blöcke können nicht gecacht werden.

Was den Cache ungültig macht

Änderungen an gecachtem Inhalt können einen Teil oder den gesamten Cache ungültig machen.

Wie in Strukturierung Ihres Prompts beschrieben, folgt der Cache der Hierarchie: tools → system → messages. Änderungen auf jeder Ebene machen diese Ebene und alle nachfolgenden Ebenen ungültig.

Die folgende Tabelle zeigt, welche Teile des Caches durch verschiedene Arten von Änderungen ungültig gemacht werden. ✘ zeigt an, dass der Cache ungültig gemacht wird, während ✓ anzeigt, dass der Cache gültig bleibt.

Cache-Performance verfolgen

Überwachen Sie die Cache-Performance mit diesen API-Antwortfeldern innerhalb von usage in der Antwort (oder message_start-Ereignis beim Streaming):

• cache_creation_input_tokens: Anzahl der Tokens, die beim Erstellen eines neuen Eintrags in den Cache geschrieben wurden.
• cache_read_input_tokens: Anzahl der Tokens, die für diese Anfrage aus dem Cache abgerufen wurden.
• input_tokens: Anzahl der Eingabe-Tokens, die weder aus einem Cache gelesen noch zum Erstellen eines Caches verwendet wurden (d. h. Tokens nach dem letzten Cache-Breakpoint).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Caching mit Thinking-Blöcken

Bei der Verwendung von erweitertem Thinking mit Prompt-Caching haben Thinking-Blöcke ein besonderes Verhalten:

Automatisches Caching zusammen mit anderen Inhalten: Während Thinking-Blöcke nicht explizit mit cache_control markiert werden können, werden sie als Teil des Anfrageinhalts gecacht, wenn Sie nachfolgende API-Aufrufe mit Tool-Ergebnissen machen. Dies geschieht häufig bei der Tool-Verwendung, wenn Sie Thinking-Blöcke zurückgeben, um das Gespräch fortzusetzen.

Eingabe-Token-Zählung: Wenn Thinking-Blöcke aus dem Cache gelesen werden, zählen sie als Eingabe-Tokens in Ihren Nutzungsmetriken. Dies ist wichtig für die Kostenberechnung und das Token-Budgeting.

Cache-Ungültigkeitsmuster:

• Der Cache bleibt gültig, wenn nur Tool-Ergebnisse als Benutzernachrichten bereitgestellt werden
• Der Cache wird ungültig, wenn Nicht-Tool-Ergebnis-Benutzerinhalte hinzugefügt werden, was dazu führt, dass alle vorherigen Thinking-Blöcke entfernt werden
• Dieses Caching-Verhalten tritt auch ohne explizite cache_control-Markierungen auf

Weitere Details zur Cache-Ungültigmachung finden Sie unter Was den Cache ungültig macht.

Beispiel mit Tool-Verwendung:

Anfrage 1: Benutzer: "Wie ist das Wetter in Paris?"
Antwort: [thinking_block_1] + [tool_use block 1]

Anfrage 2:
Benutzer: ["Wie ist das Wetter in Paris?"],
Assistent: [thinking_block_1] + [tool_use block 1],
Benutzer: [tool_result_1, cache=True]
Antwort: [thinking_block_2] + [text block 2]
# Anfrage 2 cached ihren Anfrageinhalt (nicht die Antwort)
# Der Cache enthält: Benutzernachricht, thinking_block_1, tool_use block 1 und tool_result_1

Anfrage 3:
Benutzer: ["Wie ist das Wetter in Paris?"],
Assistent: [thinking_block_1] + [tool_use block 1],
Benutzer: [tool_result_1, cache=True],
Assistent: [thinking_block_2] + [text block 2],
Benutzer: [Text-Antwort, cache=True]
# Nicht-Tool-Ergebnis-Benutzerblock bewirkt, dass alle Thinking-Blöcke ignoriert werden
# Diese Anfrage wird verarbeitet, als ob Thinking-Blöcke nie vorhanden gewesen wären

Wenn ein Nicht-Tool-Ergebnis-Benutzerblock enthalten ist, wird eine neue Assistenten-Schleife eingeleitet und alle vorherigen Thinking-Blöcke werden aus dem Kontext entfernt.

Weitere detaillierte Informationen finden Sie in der Dokumentation zu erweitertem Thinking.

Cache-Speicherung und -Freigabe

• Organisations-Isolation: Caches sind zwischen Organisationen isoliert. Verschiedene Organisationen teilen niemals Caches, auch wenn sie identische Prompts verwenden.

• Exakte Übereinstimmung: Cache-Treffer erfordern 100% identische Prompt-Segmente, einschließlich aller Texte und Bilder bis einschließlich des mit Cache-Control markierten Blocks.

• Ausgabe-Token-Generierung: Prompt-Caching hat keinen Einfluss auf die Ausgabe-Token-Generierung. Die Antwort, die Sie erhalten, ist identisch mit dem, was Sie ohne Prompt-Caching erhalten würden.

Best Practices für effektives Caching

Um die Prompt-Caching-Performance zu optimieren:

• Beginnen Sie mit automatischem Caching für mehrstufige Gespräche. Es verwaltet Breakpoints automatisch.
• Verwenden Sie explizite Block-Level-Breakpoints, wenn Sie verschiedene Abschnitte mit unterschiedlichen Änderungshäufigkeiten cachen müssen.
• Cachen Sie stabilen, wiederverwendbaren Inhalt wie Systemanweisungen, Hintergrundinformationen, große Kontexte oder häufige Tool-Definitionen.
• Platzieren Sie gecachten Inhalt am Anfang des Prompts für beste Performance.
• Verwenden Sie Cache-Breakpoints strategisch, um verschiedene cachefähige Präfix-Abschnitte zu trennen.
• Setzen Sie Cache-Breakpoints am Ende von Gesprächen und direkt vor bearbeitbaren Inhalten, um Cache-Trefferquoten zu maximieren, insbesondere bei Prompts mit mehr als 20 Inhaltsblöcken.
• Analysieren Sie regelmäßig Cache-Trefferquoten und passen Sie Ihre Strategie nach Bedarf an.

Optimierung für verschiedene Anwendungsfälle

Passen Sie Ihre Prompt-Caching-Strategie an Ihr Szenario an:

• Konversationsagenten: Reduzieren Sie Kosten und Latenz für erweiterte Gespräche, insbesondere solche mit langen Anweisungen oder hochgeladenen Dokumenten.
• Coding-Assistenten: Verbessern Sie die Autovervollständigung und Codebase-Q&A, indem Sie relevante Abschnitte oder eine zusammengefasste Version der Codebase im Prompt behalten.
• Verarbeitung großer Dokumente: Integrieren Sie vollständiges Langform-Material einschließlich Bilder in Ihren Prompt, ohne die Antwortlatenz zu erhöhen.
• Detaillierte Anweisungssätze: Teilen Sie umfangreiche Listen von Anweisungen, Verfahren und Beispielen, um Claudes Antworten zu verfeinern. Entwickler fügen oft ein oder zwei Beispiele in den Prompt ein, aber mit Prompt-Caching können Sie noch bessere Ergebnisse erzielen, indem Sie 20+ diverse Beispiele hochwertiger Antworten einbeziehen.
• Agentische Tool-Verwendung: Verbessern Sie die Performance für Szenarien mit mehreren Tool-Aufrufen und iterativen Code-Änderungen, bei denen jeder Schritt typischerweise einen neuen API-Aufruf erfordert.
• Gespräche mit Büchern, Papieren, Dokumentationen, Podcast-Transkripten und anderen Langform-Inhalten: Erwecken Sie jede Wissensbasis zum Leben, indem Sie das gesamte Dokument/die gesamten Dokumente in den Prompt einbetten und Benutzern ermöglichen, Fragen zu stellen.

Häufige Probleme beheben

Bei unerwartetem Verhalten:

• Stellen Sie sicher, dass gecachte Abschnitte über Aufrufe hinweg identisch sind. Überprüfen Sie bei expliziten Breakpoints, dass cache_control-Markierungen an denselben Stellen sind
• Prüfen Sie, ob Aufrufe innerhalb der Cache-Lebensdauer (standardmäßig 5 Minuten) gemacht werden
• Stellen Sie sicher, dass tool_choice und Bildverwendung zwischen Aufrufen konsistent bleiben
• Überprüfen Sie, ob Sie mindestens die Mindestanzahl von Tokens cachen
• Das System prüft automatisch auf Cache-Treffer an vorherigen Inhaltsblock-Grenzen (bis zu ~20 Blöcke vor Ihrem Breakpoint). Bei Prompts mit mehr als 20 Inhaltsblöcken benötigen Sie möglicherweise zusätzliche cache_control-Parameter früher im Prompt, um sicherzustellen, dass alle Inhalte gecacht werden können
• Stellen Sie sicher, dass die Schlüssel in Ihren tool_use-Inhaltsblöcken eine stabile Reihenfolge haben, da einige Sprachen (z. B. Swift, Go) die Schlüsselreihenfolge bei der JSON-Konvertierung zufällig anordnen und damit Caches ungültig machen

1-Stunden-Cache-Dauer

Wenn Sie feststellen, dass 5 Minuten zu kurz sind, bietet Anthropic auch eine Cache-Dauer von 1 Stunde gegen Aufpreis an.

Um den erweiterten Cache zu verwenden, fügen Sie ttl in die cache_control-Definition wie folgt ein:

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

Die Antwort enthält detaillierte Cache-Informationen wie folgt:

{
  "usage": {
    "input_tokens": 2048,
    "cache_read_input_tokens": 1800,
    "cache_creation_input_tokens": 248,
    "output_tokens": 503,

    "cache_creation": {
      "ephemeral_5m_input_tokens": 456,
      "ephemeral_1h_input_tokens": 100
    }
  }
}

Beachten Sie, dass das aktuelle Feld cache_creation_input_tokens der Summe der Werte im cache_creation-Objekt entspricht.

Wann der 1-Stunden-Cache verwendet werden sollte

Wenn Sie Prompts haben, die in einem regelmäßigen Rhythmus verwendet werden (d. h. System-Prompts, die häufiger als alle 5 Minuten verwendet werden), verwenden Sie weiterhin den 5-Minuten-Cache, da dieser ohne zusätzliche Kosten weiterhin aktualisiert wird.

Der 1-Stunden-Cache wird am besten in folgenden Szenarien verwendet:

• Wenn Sie Prompts haben, die wahrscheinlich weniger häufig als alle 5 Minuten, aber häufiger als jede Stunde verwendet werden. Zum Beispiel, wenn ein agentischer Nebenagent länger als 5 Minuten braucht, oder wenn ein langes Chat-Gespräch mit einem Benutzer gespeichert wird und Sie generell erwarten, dass der Benutzer möglicherweise nicht innerhalb der nächsten 5 Minuten antwortet.
• Wenn Latenz wichtig ist und Ihre Folge-Prompts möglicherweise nach mehr als 5 Minuten gesendet werden.
• Wenn Sie Ihre Rate-Limit-Auslastung verbessern möchten, da Cache-Treffer nicht gegen Ihr Rate-Limit angerechnet werden.

Mischen verschiedener TTLs

Sie können sowohl 1-Stunden- als auch 5-Minuten-Cache-Controls in derselben Anfrage verwenden, aber mit einer wichtigen Einschränkung: Cache-Einträge mit längerer TTL müssen vor kürzeren TTLs erscheinen (d. h. ein 1-Stunden-Cache-Eintrag muss vor allen 5-Minuten-Cache-Einträgen erscheinen).

Beim Mischen von TTLs bestimmen wir drei Abrechnungspositionen in Ihrem Prompt:

1. Position A: Die Token-Anzahl beim höchsten Cache-Treffer (oder 0, wenn keine Treffer).
2. Position B: Die Token-Anzahl beim höchsten 1-Stunden-cache_control-Block nach A (oder gleich A, wenn keiner vorhanden).
3. Position C: Die Token-Anzahl beim letzten cache_control-Block.

Sie werden berechnet für:

1. Cache-Lese-Tokens für A.
2. 1-Stunden-Cache-Schreib-Tokens für (B - A).
3. 5-Minuten-Cache-Schreib-Tokens für (C - B).

Hier sind 3 Beispiele. Dies zeigt die Eingabe-Tokens von 3 Anfragen, von denen jede unterschiedliche Cache-Treffer und Cache-Fehlschläge hat. Jede hat eine unterschiedlich berechnete Preisgestaltung, die in den farbigen Feldern als Ergebnis dargestellt wird.

Beispiele für Prompt-Caching

Um Ihnen den Einstieg in das Prompt-Caching zu erleichtern, haben wir ein Prompt-Caching-Cookbook mit detaillierten Beispielen und Best Practices vorbereitet.

Im Folgenden haben wir mehrere Code-Snippets eingefügt, die verschiedene Prompt-Caching-Muster zeigen. Diese Beispiele demonstrieren, wie Caching in verschiedenen Szenarien implementiert werden kann, und helfen Ihnen, die praktischen Anwendungen dieser Funktion zu verstehen:

Datenspeicherung

Prompt-Caching speichert KV (Key-Value)-Cache-Darstellungen und kryptografische Hashes von gecachten Inhalten, speichert jedoch nicht den Rohtext von Prompts oder Antworten. Gecachte Einträge haben eine Mindestlebensdauer von 5 Minuten (Standard) oder 60 Minuten (erweitert). Cache-Einträge sind zwischen Organisationen isoliert. Da Anthropic keinen Rohtext von Prompts oder Antworten speichert, kann diese Funktion für Kunden geeignet sein, die ZDR-ähnliche Datenspeicherungsverpflichtungen benötigen.

Informationen zur ZDR-Berechtigung für alle Funktionen finden Sie unter API und Datenspeicherung.

FAQ