Prompt Caching spart bis zu 80 Prozent – dynamische Inhalte gehören ans Ende

Für wirksames Prompt Caching gehört der lange, wiederverwendbare Kontext an den Anfang einer API-Anfrage; wechselnde Nutzerfragen, Zeitstempel und Tool-Ergebnisse folgen danach. Eine Studie mit mehr als 500 Agentensitzungen maß bei den untersuchten Konfigurationen 41 bis 80 Prozent geringere API-Kosten und eine um 13 bis 31 Prozent kürzere Zeit bis zum ersten Token. Die Werte beschreiben den Benchmark und sind keine zugesicherte Ersparnis für jede Anwendung.

Entscheidend ist ein Präfix, der bei Folgeanfragen identisch bleibt und die Mindestlänge des gewählten Modells erreicht. Danach prüfen Sie in den Usage-Feldern, ob Token tatsächlich aus dem Cache gelesen wurden. Eine Änderung vor der Cache-Grenze kann stattdessen einen neuen Schreibvorgang auslösen.

Einen gemeinsamen Präfix aufbauen

Ordnen Sie die Anfrage nach der Lebensdauer ihrer Inhalte: zuerst feste Werkzeugdefinitionen und Anweisungen, dann gemeinsam genutzte Beispiele oder Referenztexte, zuletzt die aktuelle Aufgabe. Das ist ein Schema für die Auswahl des Cache-Abschnitts, keine Aufforderung, unnötigen Text anzuhängen. Wenn mehrere Aufrufe dasselbe Hintergrunddokument benötigen, kann es Teil des Präfixes sein; ein nur für eine einzelne Frage abgerufenes Dokument gehört in den variablen Teil.

Bei einem Recherche-Agenten könnten Tool-Schemata, Arbeitsanweisungen und ein unverändertes Hintergrunddokument den gemeinsamen Anfang bilden. Die konkrete Suchfrage und neue Suchergebnisse folgen danach. Ein automatisch eingefügter Zeitstempel in den Arbeitsanweisungen würde den Anfang bei jedem Aufruf verändern. Benötigt die Aufgabe die aktuelle Zeit, setzen Sie diese Information hinter den stabilen Abschnitt.

Prüfen Sie die Tokenlänge dieses Abschnitts für das tatsächlich verwendete Modell. Unterhalb der jeweiligen Schwelle entsteht kein nutzbarer Cache-Eintrag, auch wenn die Anfragen gleich aussehen. Die Grenze mit Fülltext zu erreichen, erhöht zunächst nur die Eingabe; sinnvoll ist ein längerer Präfix, wenn seine Inhalte für die Folgeanfragen gebraucht werden.

Gemini: automatische Treffer sichtbar machen

Die Gemini-Dokumentation beschreibt implizites Caching als automatisch aktiv für Gemini 2.5 und neuere Modelle; für Gemini 2.5 Flash und Pro nennt sie 2.048 Eingabetoken als Mindestlänge, für die dort aufgeführten neueren Modelle 4.096. Große gemeinsame Inhalte am Promptanfang und zeitlich nahe Anfragen mit ähnlichem Präfix erhöhen die Chance auf einen Treffer. Einschalten müssen Sie das implizite Verfahren nicht.

Ob es bei einem konkreten Aufruf genutzt wurde, steht in usage.total_cached_tokens. Senden Sie zum Prüfen zwei Anfragen mit demselben langen Anfang und unterschiedlichem Schluss. Ein Wert über null beim Folgeaufruf weist Cache-Treffer aus; ein Wert von null zeigt für diesen Aufruf keinen ausgewiesenen Treffer. Auch ein passend aufgebauter Präfix garantiert beim impliziten Verfahren keinen Treffer, weshalb die tatsächlichen Usage-Werte für die Kostenbewertung wichtiger sind als die bloße Ähnlichkeit der Prompts.

Claude: den letzten stabilen Block markieren

Die Claude-Dokumentation beschreibt zwei Varianten von cache_control: auf Anfrageebene setzt es den Cache-Punkt automatisch am letzten geeigneten Block, an einem Inhaltsblock legt es die Grenze ausdrücklich fest. Die Standardlaufzeit beträgt fünf Minuten; eine Stunde ist mit höheren Schreibkosten verfügbar. Für Claude hängt die erforderliche Mindestlänge vom Modell ab: Die Dokumentation nennt beispielsweise 512 Token für Sonnet 5.5 und 1.024 für Sonnet 4.6.

Für einen festen Systemkontext mit wechselnder Nutzerfrage ist ein ausdrücklicher Cache-Punkt am letzten unveränderten Block gut kontrollierbar. Claude bildet Präfixe in der Reihenfolge Werkzeuge, System und Nachrichten. Ändert sich eine Werkzeugdefinition, kann deshalb auch ein gleich gebliebener Systemtext nicht mehr unter demselben vollständigen Präfix gelesen werden. Markieren Sie dagegen einen Block mit aktuellem Zeitstempel, wird bei jedem neuen Wert ein anderer Eintrag geschrieben.

Die automatische Variante bewegt die Grenze mit einer wachsenden Unterhaltung weiter und kann deren unveränderte Vorgeschichte wiederverwenden. Bei unabhängigen Anfragen mit stets wechselndem letztem Block kann genau diese Platzierung jedoch wiederholte Schreibvorgänge ohne Treffer erzeugen. Wenn Folgeanfragen erst nach der Standardlaufzeit eintreffen, lässt sich die längere Laufzeit gegen ihre höheren Schreibkosten abwägen; häufige Lesezugriffe sind für die Rechnung entscheidend.

Usage-Werte und parallele Aufrufe prüfen

Bei Claude zählt cache_creation_input_tokens neu geschriebene Token und cache_read_input_tokens gelesene Cache-Token. input_tokens erfasst den regulären Eingabeteil nach der letzten Cache-Grenze. Die gesamte Eingabelänge ergibt sich aus der Summe dieser drei Felder. Wer nur input_tokens betrachtet, übersieht bei erfolgreichen Treffern einen großen Teil des verarbeiteten Kontexts.

Bei einem ersten passenden Aufruf erwarten Sie einen Schreibwert; ein zeitnaher Folgeaufruf mit identischem Präfix sollte einen Lesewert zeigen. Sind Schreib- und Lesewert null, prüfen Sie Mindestlänge und Position der Grenze. Wiederholte Schreibwerte ohne Lesezugriffe sprechen dafür, die Blöcke bis zur Grenze auf Veränderungen und ihre Reihenfolge zu vergleichen. Claude macht einen Cache-Eintrag zudem erst verfügbar, wenn die erste Antwort begonnen hat. Sollen parallele Folgeanfragen den Eintrag nutzen, starten Sie sie erst nach diesem Punkt.

Änderungen finden, die Treffer verhindern

Prüfen Sie bei einem unerwarteten Cache-Fehlschlag zuerst Inhalte, die unbemerkt vor der Grenze wechseln: Zeitstempel, erzeugte Kennungen und aktualisierte Referenztexte. Bei Claude ändern neue oder entfernte Bilder die Wiederverwendbarkeit von Nachrichtenblöcken; geänderte Werkzeugdefinitionen betreffen die gesamte nachfolgende Cache-Hierarchie. Auch eine geänderte Tool-Auswahl kann Nachrichtenblöcke betreffen. Ein Bild, das pro Anfrage wechselt, sollte daher nicht Teil eines gemeinsam genutzten Nachrichten-Präfixes sein.

Neue Tool-Ergebnisse gehören ebenfalls nicht pauschal in einen Präfix, den viele unabhängige Anfragen teilen sollen. In einer fortlaufenden Unterhaltung können unveränderte frühere Ergebnisse weiter zum Kontext gehören; für neue Aufgaben wechseln sie jedoch typischerweise. Die Agentenstudie fand konsistentere Vorteile, wenn dynamische Inhalte am Ende blieben und wechselnde Tool-Ergebnisse aus dem gemeinsamen Cache-Abschnitt herausgehalten wurden. Naives Caching des gesamten Kontexts konnte im untersuchten Aufbau die Startlatenz sogar verschlechtern.

Für eine aussagekräftige Prüfung reichen mehrere repräsentative Aufrufe mit festem Anfang und wechselndem Schluss: Vergleichen Sie Cache-Lese-Token, Schreib-Token und Abrechnung. Ändern Sie anschließend gezielt einen Zeitstempel, ein Bild oder eine Tool-Definition und beobachten Sie, welcher Cache-Abschnitt noch gelesen wird. So lässt sich die Grenze an der tatsächlichen Wiederverwendung der Anwendung ausrichten.

Lesen Sie auch:

• Open-Weight-KI selbst hosten: Fünf Kontrollen vor dem ersten Prompt
• Atira erhält 15 Millionen Dollar – Angebotszeiten sinken laut Kunden um 80 Prozent
• 1Password oder Bitwarden: Selbsthosting spart nicht nur Lizenzkosten