# Zerstören dynamische Tools das Prompt-Caching?
> Ein häufiger Einwand gegen dynamische Tools ist, dass veränderte Tool-Schemas das Prompt-Caching der Provider zerstören. Ich habe 10.186 Turns bei OpenAI, Gemini und OpenRouter ausgewertet, um Cache-Miss-Raten, Ursachen und reale Kosten zu messen.
*Mohammed Reschreiter · 2026-08-30*
Tags: Prompt Caching, KI-Agenten, Architektur, Telemetrie, Token-Ökonomie
---
**Kurze Antwort: Nein.**
Dynamische Tool-Aktivierung zerstört das Prompt-Caching der Provider nicht. In einer Auswertung von 10.186 Assistant-Turns über OpenAI, Google Gemini und OpenRouter verursachte das Zuschalten und Bereinigen von Tools nur bei **2,4% bis 3,4% aller Turns** einen Cache-Miss, während **71,2 Millionen ungenutzte Schema-Tokens** vermieden und die durchschnittlichen Kosten pro Turn um **32,5% gesenkt** wurden.
Über 82,5% aller Cache-Misses entstehen durch Routine-Dateioperationen, Kontext-Kompaktierung und 5-Minuten-Cloud-Timeouts, nicht durch Tool-Wechsel.
> Dieser Beitrag ist die empirische Fortsetzung meiner Architektur-Analyse: [Wie ich über 80% Context-Overhead in meinem Coding-Agenten eingespart habe](/blog/how-i-cut-80-percent-context-overhead-dynamic-tools).
---
Als ich meine Architektur zur dynamischen Tool-Aktivierung in KI-Coding-Agenten vorstellte, kam auf Hacker News sofort ein zentraler Gegenwind auf:
> *"Tools dynamisch zuzuschalten ist ja schön, aber sie wieder zu entfernen ist eine furchtbare Idee. Schema-Änderungen verändern den Prompt-Präfix und zerstören permanent das Prompt-Caching des Providers."*
Auf dem Papier klingt dieser Einwand plausibel. Große LLM-Provider (Anthropic, OpenAI, Google) cachen Prompt-Präfixe. Ändert man System-Prompts oder Tool-Schemas, ändert sich der Präfix-Hash, und das Modell muss einen neuen Cache-Eintrag zu regulären oder höheren Schreibpreisen anlegen.
Um zu prüfen, ob dynamische Tool-Aktivierung dem Prompt-Caching in der Praxis tatsächlich schadet, habe ich **93 Coding-Sessions und 10.186 Assistant-Turns** in Pi über OpenAI, Google Gemini und OpenRouter hinweg detailliert analysiert.
Hier sind die realen Telemetriedaten.
---
## Der Datensatz
Ich habe alle interaktiven Coding-Sessions über einen Zeitraum von 11 Tagen ausgewertet, in denen die dynamische Tool-Aktivierung im täglichen Entwicklungsbetrieb aktiv war.
* **Gesamtzahl Sessions:** 93 Sessions
* **Gesamtzahl Assistant-Turns:** 10.186 Turns
* **Gesamtzahl Tool-Aufrufe:** 11.461 Ausführungen
* **Getestete Modelle:** OpenAI (GPT-5.6 Sol, GPT-5.6 Luna, Codex), Google Gemini 3.7 Flash und OpenRouter-Community-Endpunkte.
* **Verarbeitete Tokens gesamt:** 1,22 Milliarden Tokens
---
## 1. Wie oft nutzen Agenten überhaupt Standby-Tools?
Die Grundannahme hinter der Sorge vor Cache-Verlusten ist, dass der Agent alle zwei Runden ständig neue Werkzeuge lädt und entlädt.
In der Praxis folgt die Softwareentwicklung einer klaren Pareto-Verteilung.
Von 11.461 Tool-Ausführungen entfielen:
* **Die 4 Basis-Tools (`bash`, `read`, `edit`, `write`):** 10.805 Aufrufe (**94,28%**).
* **Standby-Tools bei speziellem Bedarf:** 656 Aufrufe (**5,72%**).
```text
Basis-Tools (bash, read, edit, write): ██████████████████████████████ 94,28%
Standby-Tools (browser, loops, image): █ 5,72%
```
Über 94% der Arbeit eines Agenten besteht aus dem Lesen von Dateien, Bearbeiten von Codezeilen und Ausführen von Shell-Befehlen. Weil die 4 Standard-Tools den Prompt nie verlassen, bleibt der Tool-Schema-Präfix in 85% bis 90% der gesamten Session absolut identisch und gecacht.
---
## 2. Was löst Cache-Misses tatsächlich aus?
Über alle 10.186 Turns hinweg gab es **2.030 Cache-Misses oder Zero-Cache-Ereignisse** (eine Miss-Rate von 19,93%, was einer Cache-Hit-Rate von 80,08% entspricht).
Ich habe jeden einzelnen Cache-Miss nach seiner technischen Ursache kategorisiert:
*Abbildung 1: Ursachen von Cache-Misses über 10.186 Assistant-Turns. Über 82,5% der Misses entstehen durch Routine-Dateioperationen und Cloud-TTLs, nicht durch Tool-Wechsel.*
| Ursache | Cache-Misses | Anteil an Misses | Anteil an **ALLEN 10.186 Turns** |
| :--- | :--- | :--- | :--- |
| **Große Dateiaufrufe & Kontext-Kompaktierung** | **1.422** | **70,05%** | **13,96%** |
| **Tool-Aktivierung & TTL-Ablauf** | **354** | **17,44%** | **3,47%** |
| **Provider-Inaktivitäts-Timeouts (>5 min)** | **150** | **7,39%** | **1,47%** |
| **Turn-0 Session-Warmup** | **89** | **4,38%** | **0,87%** |
| **Modellwechsel** | **15** | **0,74%** | **0,15%** |
| **Gesamt** | **2.030** | **100%** | **19,93%** |
### Wichtigste Erkenntnisse:
1. **Tool-Aktivierungen betreffen lediglich 3,47% aller Turns.**
Über alle Provider und Modelle hinweg führte das Zuschalten oder Bereinigen von Tools nach Ablauf des 2-Runden-TTLs in nur 354 Turns zu einem Cache-Übergang. Die restlichen **96,53% aller Turns** liefen ohne jeglichen tool-bedingten Cache-Nachteil.
2. **Bei OpenAI-Modellen lag die Miss-Rate durch Tools bei nur 2,40%.**
In 4.164 OpenAI-Turns verursachte die Tool-Aktivierung exakt 100 Cache-Übergänge.
3. **Über 82,5% aller Cache-Misses hatten nichts mit Tools zu tun.**
Der Hauptgrund für Cache-Verluste ist das ungefilterte Einlesen von 2.000 Zeilen langen Dateien in den Kontext, was die Kontextgrenzen verschiebt und Session-Kompaktierungen auslöst.
---
## 3. Warum Cache-Hit-Raten je nach Provider variieren
Beim Vergleich der Hit-Raten über verschiedene Anbieter hinweg liegen die Unterschiede in den jeweiligen Caching-Architekturen:
*Abbildung 2: Gemessene Cache-Hit-Raten nach Modell und Provider-Endpunkt.*
| Provider / Modell | Turns gesamt | Cache-Hit-Rate | Mindest-Token-Grenze | Dokumentierte Cache-TTL |
| :--- | :--- | :--- | :--- | :--- |
| **OpenAI (GPT-5.6 / Codex)** | 4.164 | **86,5%** | **1.024 Tokens** | 30 Minuten |
| **Google (Gemini 3.7 Flash)** | 3.683 | **78,8%** | **32.768 Tokens (32k)** | 1 Stunde |
| **OpenRouter / Free-Endpunkte** | 2.237 | **65,2%** | Variabel | Keine / Server-Wechsel |
### Die 32k-Grenze bei Google Gemini
Die Hit-Rate von 78,8% bei Gemini sah auf den ersten Blick schlechter aus als die 86,5% bei OpenAI. Ein Blick in die offizielle Dokumentation von Google Cloud liefert die Erklärung:
* OpenAI beginnt mit dem Caching automatisch ab einer Mindestlänge von **1.024 Tokens**.
* Google Gemini aktiviert sein Context-Caching erst ab einer Mindestlänge von **32.768 Tokens**.
In kurzen Sessions oder den ersten Runden (< 32k Tokens) lieferte Gemini per Definition `cacheRead: 0`. Von 772 Gemini-Cache-Misses entstanden **471 Misses (61,0%)** einzig dadurch, dass der Prompt Googles 32k-Schwelle noch nicht erreicht hatte. Sobald Sessions über 32k Tokens wuchsen, stieg die Cache-Hit-Rate bei Gemini auf über 90%.
---
## 4. Die finanzielle Rechnung: Cache-Writes vs. Schema-Ballast
Prompt-Cache-Reads sind stark rabattiert, aber nicht kostenlos. OpenAI berechnet **10% bis 50% des regulären Preises** für Cache-Reads (0,30 $ bis 1,25 $ / MTok bei GPT-5.6 / GPT-4o).
Wer in Umgebungen wie Codex 79 statische Tools permanent lädt, überträgt **in jedem einzelnen Turn rund 12.000 zusätzliche Schema-Tokens**.
Hier ist die reale Abrechnung aus meinen 4.164 OpenAI-Turns:
| Strategie | Mitziehender Schema-Ballast | Cache-Rebuild-Kosten | Cache-Read-Gebühren | Netto-Kostenwirkung |
| :--- | :--- | :--- | :--- | :--- |
| **Statische Tools (79 Tools permanent geladen)** | **49,96 Millionen Tokens** | 0,00 $ | +62,45 $ | **+62,45 $ Aufpreis** |
| **Dynamische Tools (4 Basis + Standby bei Bedarf)** | **0 Tokens** | ~0,80 $ (100 Writes) | 0,00 $ | **-61,65 $ Nettoersparnis** |
79 statische Tools mitzuschleppen zwingt dazu, bei jedem Turn eine Cache-Read-Gebühr auf 12.000 ungenutzte Tokens zu zahlen.
Durch das Bereinigen von Standby-Tools nach 2 ungenutzten Runden habe ich **~0,80 $** für 100 Cache-Neuschreibungen investiert, um **62,45 $** an Cache-Read-Gebühren einzusparen. Das entspricht einem **~77-fachen Return on Investment (ROI)**.
Über alle Modelle und Sessions hinweg sanken meine durchschnittlichen Kosten pro Turn von **0,0609 $ auf 0,0411 $ pro Turn (-32,5% direkte Rechnungsreduktion)**.
---
## 3 Regeln für maximale Cache-Stabilität im Agenten
Aus diesen 10.000 Turns ergeben sich drei klare Regeln für stabile Caches:
### 1. Häufig genutzte Such-Tools in die Basis aufnehmen
In meinem ersten Entwurf lagen `web_search` und `web_fetch` auf Standby. Da Websuchen 36% aller Tool-Aktivierungen ausmachten, eliminierte die Aufnahme in die Standard-Tools 36 Cache-Übergänge für nur ~350 Tokens.
Schwere Werkzeuge (`browser_use`, Loops, Bildgenerierung) bleiben auf Standby, während leichte, hochfrequente Lookups in der Basis verbleiben.
### 2. Deterministische Prompt-Sortierung erzwingen
Standby-Tool-Listen müssen vor der Prompt-Injektion alphabetisch sortiert werden (`standby.sort()`). Variiert die Reihenfolge geladener Erweiterungen, ändert sich der Byte-String und bricht das Präfix-Matching.
### 3. Gezielte Lese-Befehle statt voller Datei-Dumps
Große Dateiaufrufe verursachen 70% aller Cache-Misses. Eine einzige Richtlinie in den Projektanweisungen verhindert, dass Agenten ungefiltert 2.000-Zeilen-Dateien in den Kontext laden:
> Erst mit `rg -n` nach relevanten Zeilen suchen und `read` mit `offset` und `limit` (100–200 Zeilen) nutzen, statt ganze Dateien in den Kontext zu laden.
---
## Fazit
Dynamische Tool-Aktivierung bricht das Prompt-Caching nicht.
Weil über 94% aller Programmieraufgaben rein auf Basis-Werkzeugen beruhen, bleibt der Prompt-Präfix über die große Mehrheit aller Turns stabil gecacht. Die wenigen auftretenden Cache-Übergänge kosten Bruchteile von Cents, sparen jedoch zig Millionen abgerechneter Schema-Tokens ein und halten das Kontextfenster des Modells dauerhaft aufmerksam und sauber.