Hauptbereich
Agency
KI-Konzepte API-Nutzung

Prompt Caching bei LLM-APIs — Mechanik, Kosten und TTL-Wahl

Martin Rau ·

Ein System-Prompt mit Tool-Definitionen, Repository-Kontext oder einer langen Wissensbasis wiederholt sich bei jedem Aufruf einer Konversation fast wortgleich. Ohne Gegenmaßnahme zahlt man diesen Block bei jeder einzelnen Anfrage neu — in Tokens und in Latenz. Prompt Caching löst genau das: Ein Anbieter speichert die internen Modell-Zustände nach einem stabilen Prompt-Abschnitt zwischen und liest sie bei der nächsten Anfrage wieder ein, statt sie neu zu berechnen. Der Glossar-Eintrag zu Prompt Caching liefert die Kurzdefinition dazu — dieser Artikel geht in die Mechanik: wie das Caching technisch greift, was es kostet, wo sich Modelle unterscheiden und wann es sich im Agenten- und API-Alltag tatsächlich lohnt.

Wie Prompt Caching technisch funktioniert

Prompt Caching ist ein reiner Präfix-Abgleich. Der Anbieter berechnet für einen Prompt-Abschnitt die internen Key-Value-Zustände einmal und legt sie unter einem Hash der exakten Bytes ab. Bei der nächsten Anfrage vergleicht er den Anfang des neuen Prompts byteweise mit dem gecachten Präfix — stimmt er überein, werden die gespeicherten Zustände wiederverwendet, und nur der Teil danach muss neu verarbeitet werden.

Zwei Details entscheiden darüber, ob das in der Praxis greift:

  • Reihenfolge zählt. Anfragen setzen sich aus Tool-Definitionen, System-Prompt und Nachrichten-Verlauf zusammen — in genau dieser Reihenfolge gerendert. Was weiter vorne im Prompt steht, muss stabiler sein als das, was danach kommt. Ein einziges verändertes Byte macht alles ab dieser Stelle uncachebar, unabhängig davon, wie viele Cache-Marker gesetzt sind.
  • Cache-Marker (cache_control) setzen die Bruchstellen. Bei Anthropic markiert {"type": "ephemeral"} explizit, bis wohin ein Block gecacht werden soll — maximal vier solcher Bruchstellen pro Anfrage. OpenAI und Google brauchen dafür keine expliziten Marker (siehe unten), folgen aber demselben Präfix-Prinzip.

Klassischer Aufbau für einen Agenten-Loop: eine Bruchstelle am Ende des statischen System-Prompts (Rolle, Tool-Beschreibungen, feste Anweisungen), eine zweite am Ende des mitwachsenden Gesprächsverlaufs. Volatile Inhalte — Zeitstempel, Zufalls-IDs, die aktuelle Nutzerfrage — gehören danach, nie davor.

Was Prompt Caching kostet

Cache-Treffer sind deutlich billiger als der reguläre Input-Preis, aber das Anlegen eines Caches selbst kostet einen Aufschlag — die Rechnung lohnt sich erst ab einer bestimmten Wiederverwendung.

Bei Anthropic gilt aktuell (Stand September 2026):

  • Cache schreiben (erste Anfrage, die den Block neu ablegt): das 1,25-Fache des regulären Input-Preises bei 5-Minuten-TTL, das 2-Fache bei 1-Stunden-TTL.
  • Cache lesen (Treffer bei einer Folgeanfrage): rund das 0,1-Fache des regulären Input-Preises.

Daraus ergibt sich ein einfacher Break-even: Bei 5-Minuten-TTL amortisiert sich der Schreib-Aufschlag bereits ab der zweiten Anfrage mit demselben Präfix (1,25× + 0,1× ≈ 1,35× gegenüber 2× ungecacht für zwei Anfragen). Bei 1-Stunden-TTL braucht es mindestens drei Anfragen, weil der doppelte Schreibpreis mehr Treffer zum Ausgleich verlangt. Caching lohnt sich also nicht bei einer einzelnen isolierten Anfrage — sondern erst, sobald derselbe Prompt-Anfang mehrfach wiederverwendet wird, etwa in einem Multi-Turn-Dialog oder bei wiederholten, orchestrierten Aufrufen mit gleichem System-Prompt.

TTL-Varianten: 5 Minuten vs. 1 Stunde

Anthropic bietet zwei Lebensdauern für einen Cache-Eintrag an, die sich nach dem zeitlichen Abstand zwischen Anfragen richten, die sich denselben Präfix teilen:

| Abstand zwischen Anfragen | Empfohlene TTL | |---|---| | Unter 5 Minuten (durchgehender Traffic, schnelle Agenten-Turns) | 5 Minuten (Standard) — jede Anfrage erneuert den Eintrag von selbst | | 5 bis 60 Minuten (Nutzer antwortet nach einer Pause, längere Hintergrundaufgabe) | 1 Stunde — hier zahlt sich der doppelte Schreibpreis erst aus | | Über 1 Stunde | Keine TTL hilft direkt — Cache gezielt vorwärmen oder den Cache-Miss akzeptieren |

Wichtig dabei: Ein Cache-Lesevorgang verlängert die Lebensdauer kostenlos, aber die Uhr läuft ab dem Start der Anfrage — nicht erst nach der Antwort. Eine Generierung, die vier Minuten dauert, lässt bei 5-Minuten-TTL nur noch rund eine Minute Zeit für die nächste Anfrage.

Modellunterschiede: Mindestlänge für einen Cache-Treffer

Ein Prompt-Abschnitt muss eine Mindestlänge erreichen, damit er überhaupt gecacht wird — kürzere Präfixe werden still ignoriert, ohne Fehlermeldung, erkennbar nur daran, dass der Cache-Schreibwert bei null bleibt. Diese Mindestlänge ist bei Anthropic modellabhängig und nicht durchgehend gestaffelt:

| Modell-Generation (Beispiele) | Minimum | |---|---:| | Claude Opus 5 (neueste Generation) | 512 Tokens | | Claude Sonnet 5 | 1.024 Tokens | | Ältere Zwischengenerationen | 2.048 Tokens | | Manche kleinere/ältere Modelle | 4.096 Tokens |

Ein kurzer System-Prompt von rund 700 Tokens cacht demnach auf Claude Opus 5 problemlos, bleibt auf einem Modell mit 4.096er-Minimum aber wirkungslos — ohne dass der Aufruf selbst fehlschlägt. Wer zwischen Modellen wechselt, sollte diesen Wert beim jeweiligen Anbieter prüfen, statt ihn aus einer früheren Modellgeneration zu übernehmen.

Wann Prompt Caching wirklich greift

Vier Situationen, in denen sich Caching im Alltag messbar auszahlt:

  1. Multi-Turn-Agenten-Dialoge. Ein Coding-Agent mit 30.000 Tokens Repository-Kontext zahlt diesen Kontext nach dem ersten Aufruf nur noch zum Cache-Lesepreis — die nächsten zwanzig Gesprächsrunden kosten voll nur die jeweils neuen Tokens.
  2. Orchestrierte Aufrufe mit festem System-Prompt. Mehrere Worker-Agenten, die denselben System-Prompt und dieselben Tool-Definitionen nutzen, teilen sich den Cache-Eintrag — solange die Anfragen aus demselben Workspace kommen und der Präfix byteidentisch bleibt.
  3. Wiederholte Aufrufe gegen dieselbe Wissensbasis. Ein langes Referenzdokument, das als System-Kontext für viele Einzelfragen dient (Support-Bot, Dokumenten-Q&A), profitiert stark, weil das Dokument selbst gecacht wird und nur die jeweilige Frage frisch verarbeitet wird.
  4. Batch-artige Aufgaben mit gemeinsamem Präfix. Klassifizierung oder Extraktion über viele Datensätze mit identischen Instruktionen im System-Prompt — hier zahlt sich Caching schon bei wenigen Wiederholungen aus, sofern die TTL zur Aufrufgeschwindigkeit passt.

Umgekehrt bringt Caching nichts bei echten Einzelanfragen ohne Wiederholung, bei Prompts, die jedes Mal komplett unterschiedlich sind, oder wenn eine dynamische Komponente (Zeitstempel, Sitzungs-ID) versehentlich vor der Bruchstelle landet.

Abgrenzung: Wie andere Anbieter cachen

Nicht jeder Anbieter setzt Prompt Caching gleich um — die Unterschiede betreffen vor allem Automatik und Kostenmodell:

  • OpenAI cacht automatisch, ohne dass explizite cache_control-Marker gesetzt werden müssen — ab einer Prompt-Länge von 1.024 Tokens, in Schritten von weiteren 128 Tokens. Das betrifft auch Modelle wie GPT-6 Astra. Es gibt keinen separaten Schreib-Aufschlag wie bei Anthropic; Cache-Treffer werden direkt vergünstigt abgerechnet.
  • Google Gemini kennt zwei Mechanismen parallel: implizites Caching läuft automatisch im Hintergrund (etwa bei Modellen wie Gemini 3 Pro) und senkt bei einem Treffer den Preis, ohne Garantie, dass ein Treffer überhaupt eintritt. Explizites Caching legt dagegen einen Cache-Eintrag aktiv und mit Kostengarantie an — dafür fällt zusätzlich eine zeitbasierte Speichergebühr für die Lebensdauer des Eintrags an, unabhängig davon, ob er gelesen wird.

Für die praktische Arbeit heißt das: Bei Anthropic steuert man Bruchstellen und TTL selbst und zahlt einen Schreib-Aufschlag, der sich erst ab mehreren Treffern rechnet. Bei OpenAI passiert Caching automatisch im Hintergrund ohne Zusatzkosten fürs Anlegen. Bei Google muss man sich zwischen automatischem, unsicherem Caching und explizitem, aber zeitbasiert kostenpflichtigem Caching entscheiden.

FAQ

Muss ich Prompt Caching manuell aktivieren? Bei Anthropic ja — über cache_control-Marker an den gewünschten Bruchstellen, sonst wird nichts gecacht. Bei OpenAI läuft es automatisch ab der Mindestlänge, ohne Zutun. Bei Google gibt es beide Varianten: automatisch (implizit) und manuell (explizit, mit Kostengarantie).

Woran erkenne ich, ob ein Cache-Treffer tatsächlich stattgefunden hat? An den Nutzungswerten der Antwort: ein Feld für neu geschriebene Cache-Tokens und eines für gelesene Cache-Tokens. Bleibt der Lesewert über mehrere Anfragen mit demselben Präfix bei null, liegt ein stiller Invalidierungsfehler vor — meist ein dynamisches Element vor der Bruchstelle.

Lohnt sich die 1-Stunden-TTL gegenüber der 5-Minuten-Variante? Nur bei Abständen zwischen 5 und 60 Minuten zwischen Anfragen mit demselben Präfix. Bei durchgehendem Traffic unter 5 Minuten erneuert sich der günstigere 5-Minuten-Cache ohnehin von selbst — die teurere Stunden-Variante bringt dann nur den doppelten Schreibpreis ohne Zusatznutzen.

Warum cacht mein kurzer System-Prompt nicht? Jedes Modell hat eine Mindestlänge für den Präfix, ab der überhaupt ein Cache-Eintrag entsteht — sie reicht je nach Modell von wenigen Hundert bis zu mehreren Tausend Tokens. Unterhalb dieser Schwelle bleibt der Aufruf technisch fehlerfrei, cacht aber schlicht nicht.

Was ist der Unterschied zu diesem Lexikon-Artikel und dem Glossar-Eintrag? Der Glossar-Eintrag liefert die kompakte Definition in wenigen Sätzen. Dieser Artikel geht in die Mechanik: Kostenmodell mit konkreten Multiplikatoren, TTL-Wahl, modellabhängige Mindestlängen und die Abgrenzung zu anderen Anbietern.

Themenuebersicht

KI-KonzepteAPI-Nutzung