Prompt-Caching

„Prompt caching" (Prompt-Caching) optimiert deine API-Nutzung, indem es ermöglicht, ab bestimmten Präfixen in deinen Prompts fortzufahren. Dies reduziert die Verarbeitungszeit und die Kosten für sich wiederholende Aufgaben oder Prompts mit gleichbleibenden Elementen erheblich.

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

• Automatisches Caching: Füge ein einzelnes cache_control-Feld auf der obersten Ebene deiner Anfrage hinzu. Das System setzt den „cache breakpoint" (Cache-Haltepunkt) automatisch auf den letzten cachebaren Block und verschiebt ihn nach vorne, während Gespräche wachsen. Am besten geeignet für Gespräche mit mehreren Runden, bei denen der wachsende Nachrichtenverlauf automatisch gecacht werden soll.
• Explizite Cache-Breakpoints: Platziere cache_control direkt auf einzelnen Inhaltsblöcken, um genau zu steuern, was gecacht wird.

Am einfachsten beginnst du mit automatischem Caching:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    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'.",
        }
    ],
)
print(response.usage.model_dump_json())

Beim automatischen Caching speichert das System alle Inhalte bis einschließlich des letzten cachebaren Blocks im Cache. Bei nachfolgenden Anfragen mit demselben Präfix werden gecachte Inhalte automatisch wiederverwendet.

Wie Prompt-Caching funktioniert

Wenn du eine Anfrage mit aktiviertem Prompt-Caching sendest:

1. Das System prüft, ob ein Prompt-Präfix bis zu einem angegebenen Cache-Breakpoint bereits aus einer kürzlichen Anfrage im Cache gespeichert ist.
2. Falls ja, verwendet es die gecachte Version, was Verarbeitungszeit und Kosten reduziert.
3. Andernfalls verarbeitet es den vollständigen Prompt und speichert das Präfix im Cache, sobald die Antwort beginnt.

Dies ist besonders nützlich für:

• Prompts mit vielen Beispielen
• Große Mengen an Kontext oder Hintergrundinformationen
• Sich wiederholende Aufgaben mit gleichbleibenden Anweisungen
• Lange Gespräche mit mehreren Runden

Standardmäßig hat der Cache eine Lebensdauer von 5 Minuten. Der Cache wird jedes Mal ohne zusätzliche Kosten aufgefrischt, wenn die gecachten Inhalte verwendet werden.

Die Lebensdauer wird ab dem Beginn der Anfrage gemessen, die den Cache-Eintrag schreibt oder liest, nicht ab dem Ende ihrer Antwort. Die Zeit, die für das Generieren einer Antwort benötigt wird, zählt zur Lebensdauer: Wenn das Streaming einer Antwort 4 Minuten dauert, muss eine Folgeanfrage, die dasselbe gecachte Präfix wiederverwendet, innerhalb von etwa 1 Minute nach Abschluss dieser Antwort beginnen.

Preise

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

Model	Base tokens		Prompt caching
Name	Input	Output	5m writes	1h writes	Hits and refreshes
Claude Fable 5.1For demanding reasoning and long-horizon agentic work	$10 / MTok	$50 / MTok	$12.50 / MTok	$20 / MTok	$0.25 / MTok1
Claude Opus 5.5For long-running agentic coding and knowledge work	$4 / MTok	$20 / MTok	$5 / MTok	$8 / MTok	$0.20 / MTok2
Claude Sonnet 5.5The best combination of speed and intelligence	$2 / MTok	$10 / MTok	$2.50 / MTok	$4 / MTok	$0.20 / MTok
Claude Haiku 4.5The fastest model with near-frontier intelligence	$1 / MTok	$5 / MTok	$1.25 / MTok	$2 / MTok	$0.10 / MTok
Additional models
Claude Mythos 5.1	$10 / MTok	$50 / MTok	$12.50 / MTok	$20 / MTok	$0.25 / MTok1
Claude Fable 5	$10 / MTok	$50 / MTok	$12.50 / MTok	$20 / MTok	$1 / MTok
Claude Mythos 5	$10 / MTok	$50 / MTok	$12.50 / MTok	$20 / MTok	$1 / MTok
Claude Opus 5	$5 / MTok	$25 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok
Claude Opus 4.8	$5 / MTok	$25 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok
Claude Opus 4.7	$5 / MTok	$25 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok
Claude Opus 4.6	$5 / MTok	$25 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok
Claude Opus 4.5	$5 / MTok	$25 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok
Claude Opus 4.1	$15 / MTok	$75 / MTok	$18.75 / MTok	$30 / MTok	$1.50 / MTok
Claude Opus 4	$15 / MTok	$75 / MTok	$18.75 / MTok	$30 / MTok	$1.50 / MTok
Claude Sonnet 5	$2 / MTok	$10 / MTok	$2.50 / MTok	$4 / MTok	$0.20 / MTok
Claude Sonnet 4.6	$3 / MTok	$15 / MTok	$3.75 / MTok	$6 / MTok	$0.30 / MTok
Claude Sonnet 4.5	$3 / MTok	$15 / MTok	$3.75 / MTok	$6 / MTok	$0.30 / MTok
Claude Sonnet 4	$3 / MTok	$15 / MTok	$3.75 / MTok	$6 / MTok	$0.30 / MTok
Claude Haiku 3.5	$0.80 / MTok	$4 / MTok	$1 / MTok	$1.60 / MTok	$0.08 / MTok

^{1 Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price.}

^{2 Cache hits and refreshes on Claude Opus 5.5 are priced at 0.05x the base input price.}

^{All other models use the standard 0.1x multiplier.}

Unterstützte Modelle

Prompt-Caching (sowohl automatisch als auch explizit) wird auf allen aktiven Claude-Modellen unterstützt.

Automatisches Caching

Automatisches Caching ist die einfachste Möglichkeit, Prompt-Caching zu aktivieren. Anstatt cache_control auf einzelnen Inhaltsblöcken zu platzieren, fügst du ein einzelnes cache_control-Feld auf der obersten Ebene deines Anfrage-Bodys hinzu. Das System setzt den Cache-Breakpoint automatisch auf den letzten cachebaren Block.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    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?"},
    ],
)
print(response.usage.model_dump_json())

Wie automatisches Caching in Gesprächen mit mehreren Runden funktioniert

Beim automatischen Caching wandert der Cache-Punkt automatisch nach vorne, während Gespräche wachsen. Jede neue Anfrage speichert alles bis zum letzten cachebaren Block im Cache, und vorherige Inhalte werden aus dem Cache gelesen.

Der Cache-Breakpoint wandert in jeder Anfrage automatisch zum letzten cachebaren Block, sodass du keine cache_control-Markierungen aktualisieren musst, während das Gespräch wächst.

TTL-Unterstützung

Standardmäßig verwendet automatisches Caching eine „time to live" (Lebensdauer), oder TTL, von 5 Minuten. Du kannst eine TTL von 1 Stunde zum 2-Fachen des Basispreises für Input-Token angeben:

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

Kombination mit Caching auf Blockebene

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

So kannst du beide Ansätze kombinieren. Verwende zum Beispiel einen expliziten Breakpoint, um deinen System-Prompt zu cachen, während automatisches Caching das Gespräch übernimmt:

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "system": [
    {
      "type": "text",
      "text": "You are a helpful assistant.",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "What are the key terms?" }]
}

Was gleich bleibt

Automatisches Caching nutzt dieselbe zugrunde liegende Caching-Infrastruktur. Preise, Mindest-Token-Schwellenwerte, Anforderungen an die Kontextreihenfolge und das „lookback window" (Rückblickfenster) von 20 Blöcken gelten genauso wie bei expliziten Breakpoints.

Sonderfälle

• Wenn der letzte Block bereits ein explizites cache_control mit derselben TTL hat, ist automatisches Caching wirkungslos.
• 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 Breakpoints auf Blockebene vorhanden sind, gibt die API einen 400-Fehler zurück (keine Plätze mehr für automatisches Caching frei).
• Wenn der letzte Block nicht als Ziel für einen automatischen Cache-Breakpoint infrage kommt, geht das System stillschweigend rückwärts, um den nächstgelegenen geeigneten Block zu finden. Wird keiner gefunden, wird das Caching übersprungen.

Explizite Cache-Breakpoints

Für mehr Kontrolle über das Caching kannst du cache_control direkt auf einzelnen Inhaltsblöcken platzieren. Das ist nützlich, wenn du verschiedene Abschnitte cachen musst, die sich unterschiedlich häufig ändern, oder wenn du genau steuern möchtest, was gecacht wird.

Deinen Prompt strukturieren

Platziere statische Inhalte (Tool-Definitionen, Systemanweisungen, Kontext, Beispiele) am Anfang deines Prompts. Markiere das Ende der wiederverwendbaren Inhalte für das Caching mit dem Parameter cache_control.

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

Wie die automatische Präfixprüfung funktioniert

Du kannst nur einen einzigen Cache-Breakpoint am Ende deiner statischen Inhalte verwenden, und das System findet automatisch das längste Präfix, das eine vorherige Anfrage bereits in den Cache geschrieben hat. Wenn du verstehst, wie das funktioniert, kannst du deine Caching-Strategie optimieren.

Drei Grundprinzipien:

1. Cache-Schreibvorgänge finden nur an deinem Breakpoint statt. Das Markieren eines Blocks mit cache_control schreibt genau einen Cache-Eintrag: einen Hash des Präfixes, das an diesem Block endet. Das System schreibt keine Einträge für frühere Positionen. Da der Hash kumulativ ist und alles bis einschließlich des Breakpoints abdeckt, erzeugt jede Änderung an einem Block am oder vor dem Breakpoint bei der nächsten Anfrage einen anderen Hash.

2. Cache-Lesevorgänge suchen rückwärts nach Einträgen, die vorherige Anfragen geschrieben haben. Bei jeder Anfrage berechnet das System den Präfix-Hash an deinem Breakpoint und sucht nach einem passenden Cache-Eintrag. Existiert keiner, geht es Block für Block rückwärts und prüft, ob der Präfix-Hash an jeder früheren Position mit etwas übereinstimmt, das bereits im Cache liegt. Es sucht nach früheren Schreibvorgängen, nicht nach stabilen Inhalten.

3. Das Lookback-Fenster umfasst 20 Blöcke. Das System prüft höchstens 20 Positionen pro Breakpoint, wobei der Breakpoint selbst als erste zählt. Findet das System in diesem Fenster keinen passenden Eintrag, wird die Prüfung beendet (oder am nächsten expliziten Breakpoint fortgesetzt, falls vorhanden). In der Claude API zählt eine Folge aufeinanderfolgender tool_use-Blöcke als eine Position, ebenso eine Folge aufeinanderfolgender tool_result-Blöcke, sodass eine Runde mit vielen parallelen Tool-Aufrufen den Eintrag der vorherigen Anfrage nicht allein aus dem Fenster verdrängt.

Beispiel: Lookback in einem wachsenden Gespräch

Du hängst in jeder Runde neue Blöcke an und setzt cache_control auf den letzten Block jeder Anfrage:

• Runde 1: 10 Blöcke, Breakpoint auf Block 10. Es existieren keine vorherigen Cache-Einträge. Das System schreibt einen Eintrag bei Block 10.
• Runde 2: 15 Blöcke, Breakpoint auf Block 15. Block 15 hat keinen Eintrag, also geht das System zurück zu Block 10 und findet den Eintrag aus Runde 1. Cache-Treffer bei Block 10; das System verarbeitet nur die Blöcke 11 bis 15 neu und schreibt einen neuen Eintrag bei Block 15.
• Runde 3: 35 Blöcke, Breakpoint auf Block 35. Das System prüft 20 Positionen (Blöcke 35 bis 16) und findet nichts. Der Eintrag aus Runde 2 bei Block 15 liegt eine Position außerhalb des Fensters, daher gibt es keinen Cache-Treffer. Ein zweiter Breakpoint bei Block 15 startet dort ein zweites Lookback-Fenster, das den Eintrag aus Runde 2 findet.

Häufiger Fehler: Breakpoint auf Inhalten, die sich bei jeder Anfrage ändern

Dein Prompt hat einen großen statischen Systemkontext (Blöcke 1 bis 5), gefolgt von einem anfragespezifischen Block mit einem Zeitstempel und der Benutzernachricht (Block 6). Du setzt cache_control auf Block 6:

• Anfrage 1: Cache-Schreibvorgang bei Block 6. Der Hash enthält den Zeitstempel.
• Anfrage 2: Der Zeitstempel ist anders, daher unterscheidet sich der Präfix-Hash bei Block 6. Der Lookback durchläuft die Blöcke 5, 4, 3, 2 und 1, aber das System hat an keiner dieser Positionen jemals einen Eintrag geschrieben. Kein Cache-Treffer. Du zahlst bei jeder Anfrage für einen neuen Cache-Schreibvorgang und erhältst nie einen Lesevorgang.

Der Lookback findet keine stabilen Inhalte hinter deinem Breakpoint, um sie zu cachen. Er findet Einträge, die vorherige Anfragen bereits geschrieben haben, und Schreibvorgänge finden nur an Breakpoints statt. Verschiebe cache_control auf Block 5, den letzten Block, der über Anfragen hinweg gleich bleibt, und jede nachfolgende Anfrage liest das gecachte Präfix. Automatisches Caching tappt in dieselbe Falle: Es setzt den Breakpoint auf den letzten cachebaren Block, der in dieser Struktur derjenige ist, der sich bei jeder Anfrage ändert. Verwende daher stattdessen einen expliziten Breakpoint auf Block 5.

Wichtigste Erkenntnis: Platziere cache_control auf dem letzten Block, dessen Präfix über die Anfragen hinweg identisch ist, die sich einen Cache teilen sollen. In einem wachsenden Gespräch funktioniert der letzte Block, solange jede Runde weniger als 20 Blöcke hinzufügt: Frühere Inhalte ändern sich nie, sodass der Lookback der nächsten Anfrage den vorherigen Schreibvorgang findet. Bei einem Prompt mit variablem Suffix (Zeitstempel, anfragespezifischer Kontext, die eingehende Nachricht) platzierst du den Breakpoint am Ende des statischen Präfixes, nicht auf dem variablen Block.

Wann mehrere Breakpoints sinnvoll sind

Du kannst bis zu 4 Cache-Breakpoints definieren, wenn du:

• Verschiedene Abschnitte cachen möchtest, die sich unterschiedlich häufig ändern (zum Beispiel ändern sich Tools selten, der Kontext aber täglich)
• Mehr Kontrolle darüber haben möchtest, was genau gecacht wird
• Einen Cache-Treffer sicherstellen möchtest, wenn ein wachsendes Gespräch deinen Breakpoint 20 oder mehr Blöcke über den letzten Cache-Schreibvorgang hinaus verschiebt

Kosten von Cache-Breakpoints verstehen

Cache-Breakpoints selbst verursachen keine Kosten. Berechnet werden dir nur:

• Cache-Schreibvorgänge: Wenn neue Inhalte in den Cache geschrieben werden (25 % mehr als Basis-Input-Token bei einer TTL von 5 Minuten)
• Cache-Lesevorgänge: Wenn gecachte Inhalte verwendet werden (10 % des Basispreises für Input-Token, bzw. 2,5 % bei Claude Fable 5.1 und Claude Mythos 5.1 und 5 % bei Claude Opus 5.5)
• Reguläre Input-Token: Für alle nicht gecachten Inhalte

Das Hinzufügen weiterer cache_control-Breakpoints erhöht deine Kosten nicht; du zahlst weiterhin denselben Betrag, basierend darauf, welche Inhalte tatsächlich gecacht und gelesen werden. Die Breakpoints geben dir die Kontrolle darüber, welche Abschnitte unabhängig voneinander gecacht werden können.

Caching-Strategien und Überlegungen

Cache-Einschränkungen

In der Claude API, auf Claude Platform on AWS, Google Cloud und Microsoft Foundry beträgt die minimale cachebare Prompt-Länge:

• 512 Token für Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5.5, Claude Opus 5, Claude Sonnet 5.5, Claude Fable 5 und Claude Mythos 5
• 2.048 Token für Claude Mythos Preview und Claude Opus 4.7
• 4.096 Token für Claude Opus 4.6 und Claude Opus 4.5
• 1.024 Token für Claude Opus 4.8, Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1 (eingestellt, außer auf Bedrock und Google Cloud), Claude Opus 4 (eingestellt, außer auf Google Cloud) und Claude Sonnet 4 (eingestellt, außer auf Bedrock und Google Cloud)
• 4.096 Token für Claude Haiku 4.5
• 2.048 Token für Claude Haiku 3.5 (eingestellt, außer auf Bedrock und Google Cloud)

Diese Mindestwerte gelten auf jeder Plattform, auf der das jeweilige Modell verfügbar ist.

Kürzere Prompts können nicht gecacht werden, selbst wenn sie mit cache_control markiert sind. Alle Anfragen, weniger als diese Anzahl an Token zu cachen, werden ohne Caching verarbeitet, und es wird kein Fehler zurückgegeben. Um zu überprüfen, ob ein Prompt gecacht wurde, prüfe die Usage-Felder der Antwort: Wenn sowohl cache_creation_input_tokens als auch cache_read_input_tokens 0 sind, wurde der Prompt nicht gecacht (wahrscheinlich, weil er die Mindestlänge nicht erreicht hat).

Wenn dein Prompt knapp unter dem Mindestwert für dein Modell und deine Plattform liegt, lohnt es sich oft, die gecachten Inhalte zu erweitern, um den Schwellenwert zu erreichen. Cache-Lesevorgänge kosten deutlich weniger als nicht gecachte Input-Token, sodass das Erreichen des Mindestwerts die Kosten für häufig wiederverwendete Prompts senken kann.

Beachte bei gleichzeitigen Anfragen, dass ein Cache-Eintrag erst verfügbar wird, nachdem die erste Antwort begonnen hat. Wenn du Cache-Treffer für parallele Anfragen benötigst, warte auf die erste Antwort, bevor du nachfolgende Anfragen sendest.

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
• Systemnachrichten: Inhaltsblöcke im system-Array
• Textnachrichten: Inhaltsblöcke im messages.content-Array, sowohl für Benutzer- als auch für Assistenten-Runden
• Bilder & Dokumente: Inhaltsblöcke im messages.content-Array, in Benutzer-Runden
• Tool-Nutzung und Tool-Ergebnisse: Inhaltsblöcke im messages.content-Array, sowohl in Benutzer- als auch in Assistenten-Runden

Jedes dieser Elemente kann gecacht werden, entweder automatisch oder indem du es mit cache_control markierst.

Was nicht gecacht werden kann

Obwohl die meisten Anfrageblö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-Runden vorkommen. Wenn sie auf diese Weise gecacht werden, ZÄHLEN sie beim Lesen aus dem Cache als Input-Token.

• Untergeordnete Inhaltsblöcke (wie Zitate) selbst können nicht direkt gecacht werden. Cache stattdessen den Block der obersten Ebene.

  Im Fall von Zitaten können die Dokument-Inhaltsblöcke der obersten Ebene, die als Quellmaterial für Zitate dienen, gecacht werden. So kannst du Prompt-Caching effektiv mit Zitaten nutzen, indem du die Dokumente cachst, auf die sich die Zitate beziehen.

• Leere Textblöcke können nicht gecacht werden.

Was den Cache ungültig macht

Änderungen an gecachten Inhalten können den Cache teilweise oder vollständig ungültig machen.

Wie unter Deinen Prompt strukturieren 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 werden. ✘ bedeutet, dass der Cache ungültig wird, während ✓ bedeutet, dass der Cache gültig bleibt.

Bei Modellen, die Tool-Änderungen mitten im Gespräch unterstützen, kannst du mit dem Beta-Header inline-tools-2026-09-15 mitten in einem Gespräch ein Tool hinzufügen oder die Definition eines Tools ändern, ohne tools zu bearbeiten. Sende die Definition in einem tool_addition-Block in einer Systemnachricht mitten im Gespräch und lass tools genau so, wie du es ursprünglich gesendet hast. Das gecachte Präfix stimmt weiterhin überein, sodass nur die angehängte Nachricht als neuer Input verarbeitet wird. Die einzige Ausnahme ist ein tools-Array ohne nicht-verzögertes Tool: Dort verursacht das erste auf diese Weise definierte Tool bei dieser Anfrage einen vollständigen Cache-Miss. Siehe Tools in einer Nachricht definieren.

Cache-Leistung überwachen

Überwache die Cache-Leistung mit diesen API-Antwortfeldern innerhalb von usage in der Antwort (oder im message_start-Event beim Streaming):

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

Caching mit Thinking-Blöcken

Wenn du Nachdenken zusammen mit Prompt-Caching verwendest, verhalten sich Thinking-Blöcke besonders:

Automatisches Caching zusammen mit anderen Inhalten: Obwohl Thinking-Blöcke nicht explizit mit cache_control markiert werden können, werden sie als Teil des Anfrageinhalts gecacht, wenn du nachfolgende API-Aufrufe mit Tool-Ergebnissen durchführst. Das passiert häufig bei der Tool-Nutzung, wenn du Thinking-Blöcke zurückgibst, um das Gespräch fortzusetzen.

Zählung der Input-Token: Wenn Thinking-Blöcke aus dem Cache gelesen werden, zählen sie in deinen Nutzungsmetriken als Input-Token. Das ist wichtig für die Kostenberechnung und die Token-Budgetierung.

Muster der Cache-Invalidierung:

• Der Cache bleibt gültig, wenn nur Tool-Ergebnisse als Benutzernachrichten übergeben werden
• Bei Opus 4.5+ und Sonnet 4.6+ werden Thinking-Blöcke standardmäßig beibehalten, auch wenn Benutzerinhalte hinzugefügt werden, die keine Tool-Ergebnisse sind, sodass der Cache gültig bleibt
• Bei früheren Opus-/Sonnet-Modellen und allen Haiku-Modellen wird der Cache ungültig, wenn Benutzerinhalte hinzugefügt werden, die keine Tool-Ergebnisse sind, wodurch alle vorherigen Thinking-Blöcke aus dem Kontext entfernt werden
• Dieses Caching-Verhalten tritt auch ohne explizite cache_control-Markierungen auf

Weitere Details zur Cache-Invalidierung findest du unter Was den Cache ungültig macht.

Beispiel mit Tool-Nutzung:

Request 1: User: "What's the weather in Paris?"
Response: [thinking_block_1] + [tool_use block 1]

Request 2:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True]
Response: [thinking_block_2] + [text block 2]
# Request 2 caches its request content (not the response)
# The cache includes: user message, thinking_block_1, tool_use block 1, and tool_result_1

Request 3:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]
# On earlier Opus/Sonnet and all Haiku models, non-tool-result user block causes prior thinking blocks to be stripped; on Opus 4.5+/Sonnet 4.6+ they are kept

Bei früheren Opus-/Sonnet-Modellen und allen Haiku-Modellen werden an diesem Punkt alle vorherigen Thinking-Blöcke aus dem Kontext entfernt. Bei Opus 4.5+ und Sonnet 4.6+ werden vorherige Thinking-Blöcke standardmäßig beibehalten und bleiben Teil des gecachten Präfixes.

Ausführlichere Informationen findest du unter Nachdenken und Prompt-Caching.

Cache-Speicherung und -Freigabe

• Isolierung von Organisationen und Workspaces: Caches sind zwischen Organisationen isoliert. Verschiedene Organisationen teilen niemals Caches, selbst wenn sie identische Prompts verwenden. In der Claude API, auf Claude Platform on AWS und Microsoft Foundry sind Caches zusätzlich pro Workspace innerhalb einer Organisation isoliert; Bedrock und Google Cloud verwenden nur eine Isolierung auf Organisationsebene.

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

• Generierung von Output-Token: Prompt-Caching hat keinen Einfluss auf die Generierung von Output-Token. Die Antwort, die du erhältst, ist identisch mit der, die du ohne Prompt-Caching erhalten würdest.

Best Practices für effektives Caching

So optimierst du die Leistung des Prompt-Cachings:

• Beginne bei Gesprächen mit mehreren Runden mit automatischem Caching. Es übernimmt die Verwaltung der Breakpoints automatisch.
• Verwende explizite Breakpoints auf Blockebene, wenn du verschiedene Abschnitte mit unterschiedlicher Änderungshäufigkeit cachen musst.
• Cache stabile, wiederverwendbare Inhalte wie Systemanweisungen, Hintergrundinformationen, große Kontexte oder häufig verwendete Tool-Definitionen.
• Platziere gecachte Inhalte für die beste Leistung am Anfang des Prompts.
• Setze Cache-Breakpoints strategisch ein, um verschiedene cachebare Präfixabschnitte voneinander zu trennen.
• Platziere den Breakpoint auf dem letzten Block, der über Anfragen hinweg identisch bleibt. Bei einem Prompt mit statischem Präfix und variablem Suffix (Zeitstempel, anfragespezifischer Kontext, die eingehende Nachricht) ist das das Ende des Präfixes, nicht der variable Block.
• Analysiere regelmäßig die Cache-Trefferquoten und passe deine Strategie bei Bedarf an.

Optimierung für verschiedene Anwendungsfälle

Passe deine Prompt-Caching-Strategie an dein Szenario an:

• Konversationsagenten: Reduziere Kosten und „latency" (Latenz) bei längeren Gesprächen, insbesondere bei solchen mit langen Anweisungen oder hochgeladenen Dokumenten.
• Coding-Assistenten: Verbessere die Autovervollständigung und Fragen & Antworten zur Codebasis, indem du relevante Abschnitte oder eine zusammengefasste Version der Codebasis im Prompt behältst.
• Verarbeitung großer Dokumente: Binde vollständiges, umfangreiches Material einschließlich Bildern in deinen Prompt ein, ohne die Antwortlatenz zu erhöhen.
• Detaillierte Anweisungssätze: Teile umfangreiche Listen von Anweisungen, Verfahren und Beispielen, um Claudes Antworten feinabzustimmen. Entwickler fügen oft ein oder zwei Beispiele in den Prompt ein, aber mit Prompt-Caching kannst du eine noch bessere Leistung erzielen, indem du mehr als 20 vielfältige Beispiele hochwertiger Antworten einbindest.
• Agentische Tool-Nutzung: Verbessere die Leistung in Szenarien mit mehreren Tool-Aufrufen und iterativen Codeänderungen, bei denen jeder Schritt typischerweise einen neuen API-Aufruf erfordert.
• Mit Büchern, Fachartikeln, Dokumentationen, Podcast-Transkripten und anderen umfangreichen Inhalten sprechen: Erwecke jede Wissensdatenbank zum Leben, indem du das gesamte Dokument bzw. die gesamten Dokumente in den Prompt einbettest und Benutzer Fragen dazu stellen lässt.

Behebung häufiger Probleme

Bei unerwartetem Verhalten:

• Stelle sicher, dass gecachte Abschnitte über Aufrufe hinweg identisch sind. Überprüfe bei expliziten Breakpoints, dass sich die cache_control-Markierungen an denselben Stellen befinden
• Prüfe, ob die Aufrufe innerhalb der Cache-Lebensdauer erfolgen (standardmäßig 5 Minuten)
• Überprüfe, ob tool_choice, die Verwendung von Bildern, die Thinking-Konfiguration und output_config.effort zwischen den Aufrufen gleich bleiben
• Stelle sicher, dass du mindestens die Mindestanzahl an Token für dein Modell und deine Plattform cachst (siehe Cache-Einschränkungen)
• Vergewissere dich, dass dein Breakpoint auf einem Block liegt, der über Anfragen hinweg identisch bleibt. Cache-Schreibvorgänge finden nur am Breakpoint statt, und wenn sich dieser Block ändert (Zeitstempel, anfragespezifischer Kontext, die eingehende Nachricht), stimmt der Präfix-Hash nie überein. Der Lookback findet keine stabilen Inhalte hinter dem Breakpoint; er findet nur Einträge, die frühere Anfragen an ihren eigenen Breakpoints geschrieben haben
• Überprüfe, ob die Schlüssel in deinen tool_use-Inhaltsblöcken eine stabile Reihenfolge haben, da einige Sprachen (zum Beispiel Swift, Go) die Schlüsselreihenfolge bei der JSON-Konvertierung zufällig anordnen, was Caches unbrauchbar macht
• Verwende die Cache-Diagnose, damit die API aufeinanderfolgende Anfragen vergleicht und meldet, welcher Teil des Prompts abgewichen ist

Cache-Dauer von 1 Stunde

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

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

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

Die Antwort enthält detaillierte Cache-Informationen wie die folgenden:

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

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

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

Wenn du bei der Verwendung von Server-Tools wie der Websuche ephemeral_5m_input_tokens-Schreibvorgänge siehst, die du nicht angefordert hast, siehe Tool-Nutzung mit Prompt-Caching.

Wann der 1-Stunden-Cache sinnvoll ist

Wenn du Prompts hast, die in regelmäßigen Abständen verwendet werden (also System-Prompts, die häufiger als alle 5 Minuten verwendet werden), verwende weiterhin den 5-Minuten-Cache, da dieser weiterhin ohne zusätzliche Kosten aufgefrischt wird.

Der 1-Stunden-Cache eignet sich am besten für die folgenden Szenarien:

• Wenn du Prompts hast, die voraussichtlich seltener als alle 5 Minuten, aber häufiger als stündlich verwendet werden. Zum Beispiel, wenn ein agentischer Nebenagent länger als 5 Minuten braucht oder wenn du ein langes Chat-Gespräch mit einem Benutzer speicherst und generell davon ausgehst, dass dieser Benutzer in den nächsten 5 Minuten möglicherweise nicht antwortet.
• Wenn die Latenz wichtig ist und deine Folge-Prompts möglicherweise erst nach mehr als 5 Minuten gesendet werden.
• Wenn du die Auslastung deines Ratenlimits verbessern möchtest, da Cache-Treffer nicht auf dein Ratenlimit angerechnet werden.

Verschiedene TTLs mischen

Du kannst sowohl 1-Stunden- als auch 5-Minuten-Cache-Controls in derselben Anfrage verwenden, allerdings mit einer wichtigen Einschränkung: Cache-Einträge mit längerer TTL müssen vor Einträgen mit kürzerer TTL stehen (das heißt, ein 1-Stunden-Cache-Eintrag muss vor allen 5-Minuten-Cache-Einträgen stehen).

Beim Mischen von TTLs bestimmt die API drei Abrechnungspositionen in deinem Prompt:

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

Dir wird Folgendes berechnet:

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

Hier sind drei Beispiele. Die Darstellung zeigt die Eingabe-Token von 3 Anfragen, die jeweils unterschiedliche „cache hits" (Cache-Treffer) und „cache misses" (Cache-Fehltreffer) aufweisen. Daraus ergibt sich für jede Anfrage eine unterschiedlich berechnete Preisgestaltung, die in den farbigen Kästen dargestellt ist.

Den Cache vorwärmen

„Cache pre-warming" (Vorwärmen des Caches) ermöglicht es dir, deinen System-Prompt oder deine Tool-Definitionen in den Prompt-Cache zu laden, bevor ein Benutzer eine echte Anfrage auslöst. Dadurch entfällt die Latenzeinbuße durch einen Cache-Fehltreffer bei der ersten Benutzerinteraktion, was die „time-to-first-token" (Zeit bis zum ersten Token), oder TTFT, für latenzempfindliche Anwendungen reduziert.

Funktionsweise

Setze max_tokens: 0 in deiner Anfrage. Die API liest deinen Prompt in das Modell ein und schreibt den Cache an jedem cache_control-Breakpoint, kehrt dann sofort zurück, ohne eine Ausgabe zu generieren. Die Antwort enthält ein leeres content-Array, stop_reason: "max_tokens" und einen vollständig befüllten usage-Block.

Platziere den cache_control-Breakpoint auf dem letzten Block, der mit der Folgeanfrage geteilt wird (typischerweise dein System-Prompt oder deine Tool-Definitionen), nicht auf der Platzhalter-Benutzernachricht. Andernfalls ist der Cache-Eintrag an den Platzhalter gebunden, und die Folgeanfrage trifft ihn nicht. Verwende außerdem dieselbe Nachdenk-Konfiguration und denselben output_config.effort-Wert wie in deinen Folgeanfragen: Diese Werte werden in den Prompt gerendert (siehe Was den Cache ungültig macht), sodass ein Vorwärmen mit einer anderen Konfiguration einen Eintrag schreiben kann, den dein echter Traffic nie trifft. Das bedeutet, dass du einen expliziten Cache-Breakpoint statt automatischem Caching verwendest, da automatisches Caching den Breakpoint auf den letzten Block setzt, der hier der Platzhalter ist. Die Platzhalter-Benutzernachricht kann eine beliebige Zeichenkette sein, deren Inhalt nicht nur aus Leerzeichen besteht (die Beispiele hier verwenden "warmup"); ihr Inhalt wird in das Modell eingelesen, aber nie beantwortet.

client = anthropic.Anthropic()

# Führe dies aus, bevor Nutzer kommen, um den gemeinsamen System-Prompt-Cache vorzuwärmen.
prewarm = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=0,
    system=[
        {
            "type": "text",
            "text": "You are an expert software engineer with deep knowledge of distributed systems...",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "warmup"}],
)
print(prewarm.stop_reason)  # "max_tokens"
print(prewarm.content)  # []
print(prewarm.usage)

Die API gibt ein leeres content-Array zurück:

{
  "id": "msg_01XFDUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "content": [],
  "model": "claude-opus-5-5",
  "stop_reason": "max_tokens",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 8,
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 0,
    "cache_creation": {
      "ephemeral_5m_input_tokens": 5120,
      "ephemeral_1h_input_tokens": 0
    },
    "iterations": [
      {
        "input_tokens": 8,
        "output_tokens": 0,
        "cache_read_input_tokens": 0,
        "cache_creation_input_tokens": 5120,
        "cache_creation": {
          "ephemeral_5m_input_tokens": 5120,
          "ephemeral_1h_input_tokens": 0
        },
        "type": "message"
      }
    ],
    "output_tokens": 0,
    "service_tier": "standard",
    "inference_geo": "global"
  }
}

Typisches Nutzungsmuster

Sende eine Vorwärm-Anfrage, wenn deine Anwendung startet (oder in einem geplanten Intervall), und sende dann echte Benutzeranfragen, nachdem das Vorwärmen abgeschlossen ist:

client = anthropic.Anthropic()

SYSTEM_PROMPT = [
    {
        "type": "text",
        "text": "You are an expert software engineer with deep knowledge of distributed systems...",
        "cache_control": {"type": "ephemeral"},
    }
]


def prewarm_cache() -> None:
    """Call this at application startup or on a scheduled interval."""
    client.messages.create(
        model="claude-opus-5-5",
        max_tokens=0,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": "warmup"}],
    )


def respond(user_message: str) -> anthropic.types.Message:
    """The real user request; benefits from a warm cache."""
    return client.messages.create(
        model="claude-opus-5-5",
        max_tokens=1024,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": user_message}],
    )


# Wärme den Cache vor, bevor Nutzer-Traffic eintrifft.
prewarm_cache()

# Wenn der Nutzer später eine Nachricht sendet, ist das System-Prompt-Präfix bereits gecacht.
response = respond("How do I implement a binary search tree?")
for block in response.content:
    if block.type == "text":
        print(block.text)

Beachte, dass die Cache-TTL weiterhin gilt. Sende beim standardmäßigen 5-Minuten-Cache mindestens alle 5 Minuten eine neue Vorwärm-Anfrage, um den Cache warm zu halten. Verwende bei längeren Pausen zwischen Benutzeranfragen stattdessen die 1-Stunden-Cache-Dauer.

Einschränkungen

Eine Anfrage mit max_tokens: 0 wird mit einem invalid_request_error abgelehnt, wenn eine der folgenden Optionen gesetzt ist, da jede davon eine Ausgabe voraussetzt, die ein Budget von null Token nicht erzeugen kann:

• stream: true
• Erweitertes Nachdenken (thinking.type: "enabled")
• Strukturierte Ausgaben (output_config.format)
• tool_choice mit {"type": "tool", ...} oder {"type": "any"}

max_tokens: 0 wird außerdem innerhalb einer Message Batches-Anfrage abgelehnt. Das Vorwärmen zielt auf die Zeit bis zum ersten Token ab, die für die Batch-Verarbeitung keine Rolle spielt, und ein während der Batch-Verarbeitung geschriebener Cache-Eintrag würde wahrscheinlich ablaufen, bevor die Folgeanfrage ausgeführt wird.

Den max_tokens=1-Workaround ersetzen

Bevor max_tokens: 0 verfügbar war, verwendeten einige Anwendungen Aufwärm-Aufrufe mit max_tokens: 1, um denselben Effekt zu erzielen. Der Ansatz mit max_tokens: 0 ist vorzuziehen: Es wird keine Ausgabe erzeugt, sodass keine Ein-Token-Antwort verworfen werden muss, keine Ausgabe-Token berechnet werden und die Absicht der Anfrage eindeutig ist.

Beispiele für Prompt-Caching

Um dir den Einstieg in das Prompt-Caching zu erleichtern, bietet das Prompt-Caching-Cookbook ausführliche Beispiele und Best Practices.

Die folgenden Code-Snippets zeigen verschiedene Prompt-Caching-Muster. Diese Beispiele demonstrieren, wie du Caching in unterschiedlichen Szenarien implementierst, und helfen dir, die praktischen Anwendungen dieser Funktion zu verstehen:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents.",
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [Insert full text of a 50-page legal agreement here]",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "What are the key terms and conditions in this agreement?",
        }
    ],
)
print(response.usage.model_dump_json())

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get the current weather in a given location",
      "input_schema": {
        "type": "object",
        "properties": { "location": { "type": "string" } },
        "required": ["location"]
      }
    },
    {
      "name": "get_time",
      "description": "Get the current time in a given time zone",
      "input_schema": {
        "type": "object",
        "properties": { "timezone": { "type": "string" } },
        "required": ["timezone"]
      },
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "What is the weather and time in New York?" }]
}

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "...long system prompt",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        # ...bisher lange Unterhaltung
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hello, can you tell me more about the solar system?",
                }
            ],
        },
        {
            "role": "assistant",
            "content": "Certainly! The solar system is the collection of celestial bodies that orbit our Sun. It consists of eight planets, numerous moons, asteroids, comets, and other objects. The planets, in order from closest to farthest from the Sun, are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Each planet has its own unique characteristics and features. Is there a specific aspect of the solar system you'd like to know more about?",
        },
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Good to know."},
                {
                    "type": "text",
                    "text": "Tell me more about Mars.",
                    "cache_control": {"type": "ephemeral"},
                },
            ],
        },
    ],
)
print(response.usage.model_dump_json())

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    tools=[
        {
            "name": "search_documents",
            "description": "Search through the knowledge base",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "Search query"}
                },
                "required": ["query"],
            },
        },
        {
            "name": "get_document",
            "description": "Retrieve a specific document by ID",
            "input_schema": {
                "type": "object",
                "properties": {
                    "doc_id": {"type": "string", "description": "Document ID"}
                },
                "required": ["doc_id"],
            },
            "cache_control": {"type": "ephemeral"},
        },
    ],
    system=[
        {
            "type": "text",
            "text": "You are a helpful research assistant with access to a document knowledge base.\n\n# Instructions\n- Always search for relevant documents before answering\n- Provide citations for your sources\n- Be objective and accurate in your responses\n- If multiple documents contain relevant information, synthesize them\n- Acknowledge when information is not available in the knowledge base",
            "cache_control": {"type": "ephemeral"},
        },
        {
            "type": "text",
            "text": "# Knowledge Base Context\n\nHere are the relevant documents for this conversation:\n\n## Document 1: Solar System Overview\nThe solar system consists of the Sun and all objects that orbit it...\n\n## Document 2: Planetary Characteristics\nEach planet has unique features. Mercury is the smallest planet...\n\n## Document 3: Mars Exploration\nMars has been a target of exploration for decades...\n\n[Additional documents...]",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "Can you search for information about Mars rovers?",
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "tool_use",
                    "id": "tool_1",
                    "name": "search_documents",
                    "input": {"query": "Mars rovers"},
                }
            ],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": "tool_1",
                    "content": "Found 3 relevant documents: Document 3 (Mars Exploration), Document 7 (Rover Technology), Document 9 (Mission History)",
                }
            ],
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "text",
                    "text": "I found 3 relevant documents about Mars rovers. Let me get more details from the Mars Exploration document.",
                }
            ],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Yes, please tell me about the Perseverance rover specifically.",
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        },
    ],
)
print(response.usage.model_dump_json())

Datenaufbewahrung

Prompt-Caching (sowohl automatisch als auch explizit) ist ZDR-berechtigt. Anthropic speichert nicht den Rohtext deiner Prompts oder der Antworten von Claude.

KV-Cache-Repräsentationen (Key-Value) und kryptografische Hashes gecachter Inhalte werden nur im Arbeitsspeicher gehalten und nicht dauerhaft gespeichert. Gecachte Einträge haben eine Mindestlebensdauer von 5 Minuten (Standard) oder 1 Stunde (erweitert), nach der sie zeitnah, wenn auch nicht sofort, gelöscht werden. Cache-Einträge sind zwischen Organisationen isoliert und auf der Claude API, Claude Platform on AWS und Microsoft Foundry zusätzlich zwischen Workspaces innerhalb einer Organisation.

Informationen zur ZDR-Berechtigung aller Funktionen findest du unter API und Datenaufbewahrung.

FAQ

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

client.beta.prompt_caching.messages.create(**params)

client.messages.create(**params)

client.beta.promptCaching.messages.create(/* ... */);

client.messages.create(/* ... */);