--- title: "Warum unser Cloud-Agent seinen Prompt-Cache verfehlte, und was eine TTL von einer Stunde geändert hat" description: "So misst du die Trefferquote des Prompt-Caches eines Claude-Agenten, wohin die vier Breakpoints gehören, wann sich eine 1-Stunden-TTL lohnt und wann sie mehr kostet." author: "Foxl Team" date_published: "2026-10-23" date_modified: "2026-10-27" canonical_url: "https://foxl.ai/de/blog/agent-prompt-cache-hit-rate" markdown_url: "https://foxl.ai/de/blog/agent-prompt-cache-hit-rate/index.md" image: "https://foxl.ai/blog/agent-prompt-cache-hit-rate-cover.png" social_image: "https://foxl.ai/blog/social/agent-prompt-cache-hit-rate.png" content_type: "Deep dive" topics: ["Prompt caching","AI agents","Amazon Bedrock","Cost","Measurement"] products: ["Foxl Agent"] --- # Warum unser Cloud-Agent seinen Prompt-Cache verfehlte, und was eine TTL von einer Stunde geändert hat > Unser Cloud-Agent hat in seinen ersten 19 Runden in Produktion 42,6 % seiner Eingabe aus dem Prompt-Cache gelesen, und jeder große Schreibvorgang in den Cache kam nach einer Pause, die länger war als die fünf Minuten, die der Cache lebt. Eine TTL von einer Stunde hob eine gemessene Sitzung mit neun Aufrufen von 71,8 % auf 85,7 % (93,9 % nach dem ersten Aufruf) und senkte ihre Kosten um 8 %, aber ein Chat, der innerhalb von fünf Minuten endet, zahlt etwa 23 % mehr. Wie wir gemessen haben, wohin die vier Breakpoints gehören und wann sich die längere TTL lohnt. - Author: Foxl Team - Published: 2026-10-23 - Last reviewed: 2026-10-27 - Reading time: 14 minutes - Canonical HTML: [https://foxl.ai/de/blog/agent-prompt-cache-hit-rate]() ![Zwei Chat-Blasen aus Papier, weit auseinander, und zwei Papierstreifen, die unter der ersten beginnen: Der kurze ist lange vor der zweiten Blase abgerissen, der lange reicht bis unter sie. Ein Cache-Eintrag mit fünf Minuten ist weg, wenn die Person antwortet; ein Eintrag mit einer Stunde ist noch da.]() Der Cloud-Agent von Foxl beantwortet die Chats, die jemand vom Handy oder aus dem Web schickt, während der eigene Computer aus ist. In seinen ersten 19 Runden in Produktion hat er 42,6 % seiner Eingabe aus dem Prompt-Cache gelesen. Als wir uns die großen Schreibvorgänge in den Cache angesehen haben, kam jeder einzelne nach einer Pause von mehr als fünf Minuten, und so lange lebt ein Cache-Eintrag standardmäßig. Wer vom Handy aus antwortet, braucht oft länger. Wir haben den Cache-Einträgen des Agenten eine Lebensdauer von einer Stunde gegeben und eine gemessene Sitzung mit neun Aufrufen erneut laufen lassen. Die Trefferquote stieg von 71,8 % auf 85,7 %, oder auf 93,9 %, wenn man den ersten Aufruf weglässt, der immer schreibt. Die Sitzung kostete insgesamt 8 % weniger und bei der Eingabe 15 % weniger, obwohl ein Schreibvorgang mit einer Stunde das Doppelte des Basis-Eingabepreises kostet. Bei einem Chat, der innerhalb von fünf Minuten vorbei ist, kommt es umgekehrt: Er zahlt für jeden Schreibvorgang das Doppelte und liest nie etwas davon zurück, und ohne die Pause kosten dieselben neun Aufrufe mit der Ein-Stunden-Einstellung etwa 23 % mehr als mit der Fünf-Minuten-Einstellung. Die Änderung kam mit Foxl v0.9.3-beta.5, und die Methode gilt für jeden Agenten, der Claude über die Messages API aufruft, bei Anthropic oder auf Amazon Bedrock. ## Wie misst man die Trefferquote eines Prompt-Caches? Die Trefferquote ist der Anteil der Eingabe-Tokens eines Aufrufs, den der Anbieter aus seinem Cache gelesen hat, statt ihn neu zu verarbeiten: `cache_read / (uncached input + cache_read + cache_write)`. Der Cache arbeitet mit Breakpoints. Ein **Cache-Breakpoint** ist eine `cache_control`-Markierung an einem Block der Anfrage, die den Anbieter bittet, alles bis zu diesem Block zu cachen, das **Präfix**. Der Eintrag lebt für seine **TTL** (Time to Live, die Lebensdauer), standardmäßig fünf Minuten, und die nächste Anfrage, die mit demselben Präfix beginnt, liest ihn, statt erneut dafür zu zahlen. Bedrock nennt Breakpoints Checkpoints. Jede Antwort der Messages API meldet drei Eingabezähler, und die Seite von Anthropic nennt ihren Zusammenhang: `total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens`. `input_tokens` zählt also nur, was weder aus dem Cache gelesen noch in ihn geschrieben wurde, und wer `cache_read` durch `input_tokens` teilt, bekommt eine andere, viel größere Zahl. Die Converse API von Bedrock dokumentiert dasselbe für ihre eigenen Felder: Mit aktiviertem Caching steht `inputTokens` „nur für die nicht gecachten Eingabe-Tokens“. Wir nennen für jeden Lauf zwei Werte. Die Trefferquote über alle Aufrufe enthält den ersten Aufruf nach dem Ablauf des Caches, der immer schreibt. Die Trefferquote nach dem ersten Aufruf zeigt, was ein Gespräch kostet, sobald sein Cache gefüllt ist. Ein Teil des Prompts ist für alle Nutzer gleich (der erste Breakpoint unten), daher kann in Produktion der erste Aufruf einer Person lesen, was das Gespräch von jemand anderem geschrieben hat, und das zeigt nur der Wert über alle Aufrufe. Unser Test lief als eine einzige Person und misst das deshalb nicht. Der Ausgangswert in Produktion stammt aus den Abrechnungsdaten von Foxl für den Cloud-Agenten: 19 Runden in 8 Gesprächen seit dem Start, mit 35.054 aus dem Cache gelesenen Tokens, 47.173 geschriebenen und 72 ungecachten. 35.054 / (35.054 + 47.173 + 72) ergibt 42,6 %. Der Agent hat mehr geschrieben als gelesen: Mindestens 12.119 Tokens (47.173 minus 35.054), etwa ein Viertel dessen, wofür er beim Cachen bezahlt hat, wurden nie zurückgelesen. ## Warum ein Chat-Agent seinen eigenen Cache verfehlt Das Relay von Foxl, der Server zwischen den Apps von Foxl und Bedrock, setzte schon drei Breakpoints auf jede Claude-Anfrage: auf das letzte Tool, auf den System-Prompt und auf die letzte Nachricht des Nutzers, alle mit der Standard-TTL von fünf Minuten. Wenn die Aufrufe dicht aufeinander folgten, gab es Treffer. Eine Rückfrage 15 Sekunden nach einer Antwort las 3.616 Tokens und schrieb 44. Die großen Schreibvorgänge kamen alle nach Pausen von mehr als fünf Minuten. Eine Nachricht 26 Minuten nach der letzten Antwort oder ein Chat, der zwei Stunden nach dem letzten geöffnet wurde, schrieb das ganze Präfix neu, etwa 3.600 Tokens aus Tools und System-Prompt. Die Empfehlung von AWS für den Ein-Stunden-Cache beschreibt fast genau diesen Fall: „wenn du ein langes Chat-Gespräch mit einem Nutzer speicherst und im Allgemeinen erwartest, dass dieser Nutzer in den nächsten 5 Minuten nicht antwortet“. Ein Treffer frischt den Eintrag außerdem kostenlos auf („Der Cache wird jedes Mal ohne zusätzliche Kosten aufgefrischt, wenn der gecachte Inhalt verwendet wird“). Ein Agent, der eine Tool-Schleife abarbeitet, stößt daher selten an die Fünf-Minuten-Grenze, es sei denn, ein einzelner Aufruf oder ein Tool dauert länger als fünf Minuten. Ein Chat mit einem Menschen stößt zwischen den Runden daran, und genau dort verbringt so ein Chat die meiste Zeit. ## Wohin die vier Breakpoints gehören Eine Claude-Anfrage kann höchstens vier Breakpoints tragen (Anthropic: „Du kannst bis zu 4 Cache-Breakpoints definieren“; Bedrock nennt 4 für jedes Claude-Modell in seiner Tabelle). Das gecachte Präfix wird in der Reihenfolge `tools`, `system`, `messages` gelesen, und eine Änderung an irgendeiner Stelle macht alles danach ungültig. Die Breakpoints des Relays hatten alle fünf Minuten, deshalb setzt der Cloud-Agent jetzt alle vier selbst, jeden mit seiner TTL. Das Relay lässt eine Anfrage, die schon Breakpoints trägt, in Ruhe und fügt keine eigenen hinzu. ![Eine Messages-Anfrage als Zeile gezeichnet: Tools, der gemeinsame System-Prompt, der persönliche Teil des System-Prompts, die früheren Nachrichten, die vorige Nachricht des Nutzers und die neueste Nachricht. Vier nummerierte Markierungen sitzen am Ende des gemeinsamen Systemteils, am Ende des System-Prompts, an der vorigen Nachricht des Nutzers und an der neuesten Nachricht. Die erste beendet den Teil, den alle Chats teilen, die zweite den Teil dieser Person, die dritte ist die Stelle, an die der vorige Aufruf geschrieben hat, und die vierte ist der Schreibvorgang, den der nächste Aufruf liest.]() _Abbildung 1. Die vier Breakpoints eines Cloud-Aufrufs. Alles vor dem ersten ist für jedes Gespräch jeder Person auf einem Modell gleich._ 1. **Das Ende des gemeinsamen Teils des System-Prompts.** Wir teilen unseren System-Prompt dort, wo das persönliche Gedächtnis des Nutzers beginnt, an einer Überschrift `## Memory`. Die Tools und alles über dieser Überschrift (wer der Agent ist, was er in der Cloud kann und was nicht) sind für jedes Gespräch jeder Person auf einem Modell gleich, daher beginnt ein ganz neuer Chat, egal von wem, damit, sie zu lesen. 2. **Das Ende des System-Prompts.** Der zweite Breakpoint fügt das eigene Gedächtnis der Person und eine Datumszeile hinzu. Die Datumszeile nennt den Tag, nicht die Uhrzeit, und ändert das Präfix deshalb zwischen den Aufrufen nicht. 3. **Der letzte cachebare Block der vorigen Nachricht des Nutzers.** Genau dorthin hat der vorige Aufruf geschrieben, also hängt das Lesen nicht vom Zurückschauen der API ab. Ohne diesen Breakpoint beginnt die API beim neuesten und sucht rückwärts nach einem früheren Cache-Eintrag, aber nur begrenzt weit („Das Lookback-Fenster umfasst 20 Blöcke“), und eine Runde mit vielen Tool-Aufrufen kann den vorigen Schreibvorgang außer Reichweite schieben. Wie diese Blöcke gezählt werden, hängt davon ab, wo du Claude aufrufst: Die API von Anthropic zählt eine Folge aufeinanderfolgender `tool_use`- oder `tool_result`-Blöcke als eine Position, während die Seite von Bedrock nur „etwa 20 Inhaltsblöcke“ sagt und keine solche Ausnahme macht. 4. **Der letzte cachebare Block der neuesten Nachricht.** Das ist der Schreibvorgang, den der nächste Aufruf liest. Alle vier nutzen dieselbe TTL. Bedrock akzeptiert beide TTLs in einer Anfrage, solange jeder Ein-Stunden-Eintrag zuerst kommt („ein 1-Stunden-Cache-Eintrag muss vor allen 5-Minuten-Cache-Einträgen stehen“), und eine TTL für alle vier stellt das ohne jede Prüfung sicher. Breakpoints kommen nur an Blöcke vom Typ `text`, `image`, `document`, `tool_use` und `tool_result`, also an die Nachrichteninhalte, die Anthropic als cachebar aufführt. Die Ein-Stunden-TTL bekommen nur die Claude-Modelle, die die Tabelle von Bedrock mit „Supported TTL: 5 minutes, 1 hour“ führt. Bedrock warnt, dass das Senden des Feldes an ein Modell, das nur fünf Minuten unterstützt, „zu einer `ValidationException` führen kann“, deshalb bekommen die anderen Claude-Modelle dieselben vier Breakpoints ohne `ttl`. GPT-5.6 und neuer auf Bedrock lassen wir in Ruhe: Sie nutzen ihr eigenes Feld `prompt_cache_breakpoint` und laut derselben Seite eine „Mindest-TTL von 30 Minuten“. ``` // the marker on each of the four blocks, on a model that takes it "cache_control": { "type": "ephemeral", "ttl": "1h" } ``` Es gibt auch eine Mindestgröße. Bedrock cacht einen Checkpoint nur, wenn alles davor die Mindestlänge des Modells erreicht: 512 Tokens bei den 5.5-Modellen und 1.024 oder 4.096 bei einigen älteren. Unter dem Minimum „ist deine Inferenz trotzdem erfolgreich, aber dein Präfix wird nicht gecacht“. Bei einem Modell mit einem Minimum von 4.096 Tokens cachen die Breakpoints für Tools und System bei einem Prompt von 3.600 Tokens nichts, bis das Gespräch selbst das Präfix über das Minimum schiebt. Prüf die Tabelle also für jedes Modell, das du anbietest. ## Kostet ein Ein-Stunden-Cache mehr, als er spart? Zu den Preisen von Anthropic kostet ein Schreibvorgang mit fünf Minuten das 1,25-Fache des Basis-Eingabepreises, einer mit einer Stunde das 2-Fache, und ein Lesevorgang das 0,1-Fache (das 0,05-Fache bei Opus 5.5 und Sonnet 5.5). Ein Ein-Stunden-Schreibvorgang kostet also das 0,75-Fache des Basispreises mehr als ein Fünf-Minuten-Schreibvorgang. Diesen Aufschlag zahlst du auf das Präfix einmal pro Stunde und auf den neuen Inhalt jedes Aufrufs jedes Mal. Dafür schreibt eine Pause von mehr als fünf Minuten nicht mehr das ganze Präfix zum 1,25-Fachen neu; das Präfix wird stattdessen gelesen. Für die Messung haben wir den Produktionscode des Cloud-Agenten über eine lokale Kopie unseres Relays gegen das echte Bedrock laufen lassen. Das Szenario ist ein Chat mit vier Runden (ein Plan, der mit einem Tool verfolgt wird, eine Rückfrage, das Speichern einer Datei, dann 6,5 Minuten später eine Frage zur ersten Runde), gefolgt von einem neuen Chat. Das ergibt neun Modellaufrufe auf Sonnet 5.5, weil eine Runde mit einem Tool mehr als einen Aufruf macht. Die Nutzung wurde aus dem Stream gelesen, den Bedrock zurückgab, und die Kostenspalte nutzt die eigenen Token-Preise von Foxl für Sonnet 5.5. | Einstellung | Cache gelesen | Cache geschrieben | Treffer, alle 9 Aufrufe | Treffer, Aufrufe 2-9 | Kosten des Laufs | | --- | --- | --- | --- | --- | --- | | fünf Minuten (die Breakpoints des Relays) | 29.979 | 11.755 (5 Min.) | 71,8 % | 78,7 % | 0,0538 $ | | eine Stunde (vier Breakpoints) | 35.859 | 5.974 (1 Std.) | 85,7 % | 93,9 % | 0,0494 $ | | eine Stunde, plus Gedächtnisdateien (unten erklärt) | 177.347 | 20.108 (1 Std.) | 89,8 % | 98,6 % | 0,1219 $ | Fast der ganze Unterschied steckt im Aufruf nach der Pause von 6,5 Minuten. Mit Fünf-Minuten-Einträgen schrieb er sein Präfix von 5.873 Tokens neu. Mit Ein-Stunden-Einträgen las er 5.750 Tokens und schrieb 133, und Bedrock meldete jeden Schreibvorgang als `ephemeral_1h_input_tokens`. Daran sehen wir, dass die längere TTL angewendet und nicht stillschweigend ignoriert wurde. Der Ein-Stunden-Lauf las 5.880 Tokens mehr als der Fünf-Minuten-Lauf (35.859 minus 29.979); 5.750 davon kamen aus diesem einen Aufruf und die übrigen etwa 130 aus der Verschiebung der Breakpoints. Das Szenario hatte keine Runde mit vielen Tool-Aufrufen, also nicht den Fall, für den der dritte Breakpoint da ist. Die ungecachte Eingabe lag in jedem Lauf bei 28 Tokens. Die Fünf-Minuten-Einstellung kommt in diesem Test auf 71,8 % gegenüber 42,6 % in Produktion, weil der Test eine einzige Pause von 6,5 Minuten hat, während sich die 19 Runden in Produktion auf 8 Gespräche mit Pausen von 26 Minuten und zwei Stunden verteilten. Derselbe Code erzielt bei unterschiedlichem Traffic sehr unterschiedliche Werte, also vergleiche Trefferquoten nur zwischen Läufen desselben Szenarios. Ohne die Pause dreht sich das Ergebnis um. Nimmt man sie aus denselben Messungen heraus, schreibt die Fünf-Minuten-Einstellung ihr Präfix nie neu und ist damit die günstigere: Der Ein-Stunden-Lauf kostet insgesamt etwa 23 % mehr und bei der Eingabe etwa 48 % mehr, weil er für jeden Schreibvorgang das Doppelte des Basispreises zahlte und nach Minute fünf nichts davon zurückgelesen wurde. Für deinen eigenen Traffic auf Sonnet 5.5 oder Opus 5.5 vergleichst du zwei Zahlen: - **Ersparnis:** Jedes Präfix-Token, das du nach einer Pause neu schreiben müsstest, spart etwa das 1,2-Fache des Basispreises (ein Neuschreiben zu 1,25, ersetzt durch ein Lesen zu 0,05). - **Aufschlag:** Jedes Token, das in dieser Stunde geschrieben wird, kostet das 0,75-Fache des Basispreises mehr (2 statt 1,25). Die Ein-Stunden-TTL liegt vorn, wenn die Ersparnis größer ist. Ein Chat mit einer Pause von fünf bis sechzig Minuten kommt meistens dorthin, ebenso ein zweiter Chat, der innerhalb der Stunde beginnt; ein Chat, der innerhalb von fünf Minuten vorbei ist, ohne dass in dieser Stunde sonst etwas passiert, nicht. Für Menschen, die vom Handy antworten, haben wir eine Stunde gewählt. Für einen Agenten, dessen Aufrufe Sekunden auseinanderliegen, sind fünf Minuten die bessere Einstellung. Wenn du vor jedem Aufruf Guthaben reservierst, ändert die TTL auch die Reservierung. Das Relay von Foxl reserviert für den schlimmsten Fall, also wird eine Anfrage, die eine TTL von einer Stunde verlangt, zum Ein-Stunden-Schreibpreis reserviert. Dieser Preis (das 2-Fache) ist das 1,6-Fache des Fünf-Minuten-Preises (das 1,25-Fache), daher reserviert ein Aufruf mit Sonnet 5.5 und 100.000 Tokens Kontext etwa 0,40 $ für die Eingabe statt 0,25 $. Berechnet wird weiterhin, was der Aufruf verbraucht hat, aber bei einem fast leeren Guthaben kann die Ablehnung einen Aufruf früher kommen. ## Was die Obergrenze bestimmt Der neue Inhalt. Jede neue Nachricht des Nutzers und jede Antwort wird einmal in den Cache geschrieben, bevor sie gelesen werden kann, also lässt keine Platzierung der Breakpoints einen Aufruf die Tokens lesen, die er gerade hinzufügt. Im Ein-Stunden-Lauf las der erste Aufruf nichts, weil die Fünf-Minuten-Einträge des vorigen Laufs abgelaufen waren. Alle 35.859 gelesenen Tokens kamen also aus den Aufrufen 2 bis 9: 93,9 % der rund 38.200 Eingabe-Tokens, die sie verbrauchten. Die übrigen etwa 2.300 waren die neuen Nachrichten und Antworten dieses Laufs, womit 93,9 % die Obergrenze für dieses Szenario ist. Ein längerer Chat bringt pro neuem Token mehr Verlauf mit, deshalb liegt seine Obergrenze höher. ![Balken für drei Läufe derselben Sitzung mit neun Aufrufen. Die Fünf-Minuten-Einstellung las insgesamt 71,8 % der Eingabe aus dem Cache und 78,7 % nach dem ersten Aufruf. Die Ein-Stunden-Einstellung las 85,7 % und 93,9 %. Mit den Gedächtnisdateien im Prompt waren es 89,8 % und 98,6 %.]() _Abbildung 2. Dieselben neun Aufrufe mit drei Einstellungen. Die Lücke zwischen den beiden Balken eines Laufs ist der erste Aufruf, der immer schreibt._ Ein größeres stabiles Präfix hebt die Quote ebenfalls, ohne irgendetwas billiger zu machen. Das haben wir gesehen, als der Cloud-Agent eine Option bekam, die Gedächtnisdateien des Nutzers einzubeziehen: vier Markdown-Dateien (SOUL.md, USER.md, MEMORY.md und AGENTS.md), die die Desktop-App von Foxl in ihren eigenen Prompt setzt. Das Handy oder der Browser kopiert sie, während der Computer verbunden ist, kürzt sie mit demselben Code wie die Desktop-App und schickt sie mit jeder Cloud-Nachricht mit. Ein echter Satz dieser Dateien, auf diese Weise gekürzt, kam auf etwa 41.000 Zeichen, also rund 14.000 Eingabe-Tokens pro Aufruf; der dritte Lauf nutzte eine Testdatei derselben Größe. In diesem Lauf schrieb der erste Aufruf 17.619 Tokens des Prompts der Person, jeder spätere Aufruf las sie, und die Trefferquote nach dem ersten Aufruf erreichte 98,6 %. Der Lauf kostete aber auch 0,1219 $ gegenüber 0,0494 $, weil der Prompt um ein Vielfaches größer ist; ohne Cache hätten dieselben neun Aufrufe 0,4187 $ gekostet. Er hatte die beste Trefferquote der drei Läufe und die höchste Rechnung, und deshalb stellen wir neben jede Trefferquote, die wir nennen, die Kosten. ## Was wir nicht gemessen haben - **Produktion nach der Änderung.** Stand 23. Oktober 2026 ist seit dem Deployment der Änderung keine Cloud-Runde in Produktion gelaufen. 42,6 % ist daher der einzige Produktionswert, und die Werte danach stammen vom lokalen Relay auf dem echten Bedrock. - **Andere Modelle.** Wir haben nur Sonnet 5.5 laufen lassen. Die anderen Claude-Modelle, die die Ein-Stunden-TTL bekommen, bekommen sie auf Grundlage der Tabelle von Bedrock und, bei Opus 5.5, einer früheren Messung über unser Relay. - **Andere Szenarien.** Neun Aufrufe nach einem Muster, keiner davon eine Runde mit vielen Tool-Aufrufen. Ein Chat, der über eine Stunde ruht, zahlt den ersten Schreibvorgang erneut, und eine Stunde ist die längste TTL, die einer der beiden Anbieter für Claude anbietet. Wenn du eigene Claude-Agenten betreibst, ist die Trefferquote das Günstigste, was du prüfen kannst. Addiere pro Aufruf die drei Zähler, teile die Lesevorgänge durch die gesamte Eingabe und sieh dir an, was vor jedem Aufruf kam, der ein großes Präfix geschrieben hat. Folgte er auf eine Pause von mehr als fünf Minuten, behebt eine Ein-Stunden-TTL das, so wie sie fast den ganzen Gewinn in diesem Szenario gebracht hat. Folgte er auf einen Aufruf von wenigen Sekunden zuvor, hat sich entweder das Präfix zwischen den beiden Aufrufen geändert, oder der vorige Schreibvorgang lag außerhalb der Reichweite des Zurückschauens, und genau das verhindert der dritte Breakpoint. Ein früherer Beitrag erklärt, [wie ein Subagent im Cache seines Eltern-Agenten bleibt]() (auf Englisch), dieselbe Präfix-Regel innerhalb einer einzigen Runde. ## Quellen und weiterführende Lektüre 1. [Anthropic: Prompt Caching]() - Documentation 2. [Amazon Bedrock: Prompt Caching für schnellere Modellinferenz]() - Documentation 3. [Release Foxl v0.9.3-beta.5]() - Release