Zerstören dynamische Tools das Prompt-Caching?

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.

---

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%).

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.

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.

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:

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.