Prompt-Caching

Wie ein Cache-Treffer funktioniert

Ein Sprachmodell liest jede Anfrage vom ersten Token an. Ein KI-Agent mitten in einer Aufgabe schickt bei jedem einzelnen Aufruf seine Anweisungen, seine Tool-Definitionen und das gesamte bisherige Gespräch mit, sodass dieses wiederholte Lesen bei einer langen Aufgabe den Großteil dessen ausmacht, was Sie bezahlen. Prompt-Caching erlaubt dem Anbieter, Arbeit zu überspringen, die er gerade erst erledigt hat: Stimmt der Anfang Ihrer Anfrage Token für Token mit dem Anfang einer kürzlich gestellten überein, wird dieser Abschnitt aus dem bedient, was der Anbieter aufbewahrt hat, und zum Cache-Tarif abgerechnet.

Drei Details entscheiden, ob das passiert:

• Es ist ein Präfix-Abgleich. Der Cache deckt alles vom ersten Token bis zum ersten Unterschied ab und nichts danach. Ändern Sie ein einziges Zeichen weit oben, wird jedes Token unterhalb dieser Stelle wieder vollständig gelesen und abgerechnet.
• Er läuft ab. Einträge überstehen Minuten ohne Aktivität, keine Tage, und das Zeitfenster unterscheidet sich je nach Anbieter und Modell. Eine Anfrage nach einer langen Pause zahlt deshalb den vollen Preis, auch wenn sich an ihr nichts geändert hat.
• Er hat eine Untergrenze. Unterhalb einer Mindestlänge des Prompts wird überhaupt nichts gecacht, und dieses Minimum ist pro Modell festgelegt. Lesen Sie es in der aktuellen Dokumentation des Anbieters nach, statt eine Zahl aus einem alten Blogbeitrag zu übernehmen.

Stand September 2026 rechnen Anthropic, OpenAI und Google einen Cache-Lesezugriff auf ihren aktuellen Modellen jeweils mit etwa einem Zehntel des normalen Eingabepreises ab. Google und OpenAI cachen automatisch; Anthropic cacht bis zu Haltepunkten, die Sie in der Anfrage markieren, und verlangt für das Schreiben eines Eintrags einen Aufschlag. Ein Abstand von zehn zu eins ist groß genug, dass oft der gecachte Anteil Ihrer Eingabe und nicht die Größe Ihres Prompts darüber entscheidet, was ein Agentenlauf kostet.

Warum das Kürzen des Kontexts unsere Agenten teurer gemacht hat

Wir betreiben langlebige Agenten, die für Kunden Websites bauen und bearbeiten, und eine einzige Sitzung beim Bau einer Website hat uns gezeigt, was unbegrenzter Kontext kostet. In knapp vier Stunden machte sie 622 Modellaufrufe, während das Gespräch, das bei jedem Aufruf erneut gelesen wurde, auf rund 310.000 Tokens anwuchs. Der Text, den das Modell tatsächlich schrieb, machte etwa 6% der Rechnung aus. Alles andere war das erneute Lesen derselben Historie.

Die naheliegende Lösung war Pruning: vor jedem Aufruf alte Tool-Ergebnisse entfernen, auf die der Agent bereits reagiert hatte. Wir haben das in unserem eigenen Test-Workspace gemessen, insgesamt 366 echte Modellaufrufe, und in dem Abschnitt, in dem es tatsächlich griff, kostete jeder Aufruf etwa 28% mehr, während nur rund 23.000 Tokens pro Prompt wegfielen. Der Pruner arbeitete sich vom ältesten Ergebnis aus vorwärts und schrieb deshalb bei jedem Aufruf eine etwas spätere Stelle innerhalb des Präfixes um, das der Anbieter gerade gecacht hatte. Die nicht gecachte Eingabe pro Aufruf stieg von 2–8 Tausend Tokens auf 5–25 Tausend, und bei einem Preisverhältnis von zehn zu eins hat das die Ersparnis mehr als aufgefressen. Die Rechnung lohnt sich zu merken: Eine Änderung innerhalb eines gecachten Präfixes muss ungefähr neunmal so viele Tokens entfernen, wie sie ungültig macht, nur um die Gewinnschwelle zu erreichen.

Funktioniert hat stattdessen eine Obergrenze statt eines Zuschnitts. Wir haben den Kontext, den ein Agent ansammeln darf, auf 200.000 Tokens begrenzt, sodass seine Historie in einem Durchgang verdichtet wird, wenn sie sich dieser Grenze nähert, statt bei jedem Aufruf ein wenig bearbeitet zu werden, und wir haben das Pruning pro Aufruf abgeschaltet. Einmal umschreiben, danach eine lange Reihe von Aufrufen, die nur anhängen: Das ist die Form, die Caching belohnt. Unsere Lehre daraus: Lesen Sie bei jedem Aufruf die gecachte und die nicht gecachte Eingabe ab, bevor Sie glauben, eine Änderung habe Geld gespart, denn die Prompt-Größe allein sagte uns das Gegenteil dessen, was auf der Rechnung stand.

So behalten Sie Ihre Cache-Treffer

Der Großteil der Ersparnis kommt aus der Reihenfolge, nicht aus der Konfiguration. Wenn Sie auf einer Modell-API aufbauen, decken vier Gewohnheiten fast alles ab:

• Stabiles zuerst, Veränderliches zuletzt. Anweisungen, Tool-Definitionen und Referenzdokumente gehören nach oben und bleiben zwischen den Aufrufen Byte für Byte identisch. Ein Zeitstempel, der Name eines Nutzers oder eine Request-ID weit oben in einem System-Prompt hebelt den Cache unbemerkt bei jeder Anfrage aus.
• Anhängen, nicht bearbeiten. Fügen Sie neue Gesprächsrunden am Ende des Gesprächs an. Frühere Runden an Ort und Stelle umzuschreiben, umzuordnen oder zusammenzufassen, macht alles nach der Änderung ungültig — genau der Fehler, den unser Pruning Schritt für Schritt gemacht hat.
• Selten umschreiben, und dann alles auf einmal. Muss die Historie schrumpfen, tun Sie es in einer einzigen Verdichtung an einer selbst gewählten Obergrenze, und nehmen Sie einen teuren Aufruf in Kauf, um danach eine lange günstige Strecke zu bekommen.
• Den Anteil messen, nicht die Größe. Anbieter weisen gecachte und nicht gecachte Eingabe in den Nutzungsdaten jeder Antwort getrennt aus. Eine Änderung, die Ihren Prompt verkürzt und die nicht gecachte Menge erhöht, hat die Sache teurer gemacht, ganz gleich, was die Prompt-Länge sagt.

Die Zahlen oben stammen aus dem Betrieb von AgentCeres — dem AI Growth Officer auf agentceres.com —, wo ein Team spezialisierter Agenten Seiten, Beiträge und Ansprachen entwirft und ausgehende Arbeit standardmäßig auf die Freigabe durch einen Menschen wartet. Wenn Sie ein Produkt bepreisen, das auf solchen Aufrufen aufbaut, erklärt Wie bepreise ich ein KI-Produkt, wenn meine Kosten variabel sind?, warum gemessene Kosten pro Aufruf unter den Preis gehören.