„In FreeInference, user idle causes more misses than any other pause.“ Der Satz stammt aus der Auswertung von 12.002 Sitzungen eines kostenlosen Inference-Gateways, das Forschende der Harvard University betreiben. Er lenkt den Blick auf einen Punkt, an dem die meisten öffentlichen Messungen aufhören. Die Pausen, in denen ein Coding-Agent auf einen Menschen wartet, sind genau die Momente, in denen sein Zwischenspeicher verfällt – und damit die Rechnung, die kaum jemand sieht. Wer verstehen will, warum Agenten beim Warten teuer werden, muss zuerst verstehen, was da zwischengespeichert wird.
Ein Coding-Agent schickt dem Modell bei jedem Schritt die komplette bisherige Konversation erneut: Systemprompt, Werkzeugdefinitionen, alle bisherigen Antworten, alle Dateiauszüge. Der Server kann die Arbeit, die er am unveränderten Anfang dieses Prompts bereits geleistet hat, im Speicher behalten und beim nächsten Mal überspringen. Diesen gespeicherten Zwischenstand nennt man KV-Cache. Im Kern ist er eine Werkbank, auf der halbfertige Teile liegen bleiben dürfen. Liegen sie noch da, geht es schnell weiter; sind sie weggeräumt, muss alles neu zugeschnitten werden.
Die vorliegende Analyse trägt die öffentlichen Messungen zu diesem Effekt zusammen, Stand 18. Oktober 2026, und ordnet sie nach Quellentyp: Angaben von Anbietern, Preprints, Simulationen, Blogposts. Sie führt keine eigenen Experimente durch. Siddhant Khare baut selbst kleine offene Werkzeuge zum Tracing und Messen von Inference; diesen Interessenkonflikt benennt er offen. Der Beitrag zeigt nicht nur Zahlen, sondern auch, wo die Zahlen aufhören.
Was ein KV-Cache im Coding-Agenten tatsächlich macht
Ein Modell liest einen Prompt nicht auf einmal, sondern Stück für Stück, und für jedes Stück legt es Zwischenergebnisse ab. Ändert sich der Anfang des Prompts nicht, kann der Server diese Zwischenergebnisse wiederverwenden; nur der neue Teil am Ende muss vorgerechnet werden. Dieses Vorrechnen heißt Prefill und ist der teuerste Teil einer Anfrage, weil dabei viele Token gleichzeitig durch die GPU laufen. Der Anteil des Prompts, der aus dem Cache kommt, ist die Cache-Hit-Rate – die zentrale Kennzahl dieser Analyse.
Die Bedingung ist streng: Nur ein exakt passender Prefix lässt sich wiederverwenden. Schon eine veränderte Zeile im Systemprompt, ein anderes Werkzeug-Set oder eine neu sortierte Dateiliste bricht die Kette ab, und der Server fängt wieder bei null an. Ein Treffer spart nicht nur Geld, sondern vor allem Zeit bis zum ersten Token, kurz TTFT. Diese Wartezeit fällt Nutzern am stärksten auf, und sie wächst mit jedem fehlenden Cache-Treffer.
Der Cache ist dabei kein Selbstzweck, sondern eine Ressource mit begrenzter Haltbarkeit. Er liegt im GPU-Speicher, dessen Platz endlich ist, und er hat eine Lebensdauer, die der Betreiber festlegt. Aus diesen zwei Begrenzungen ergeben sich zwei verschiedene Fehlerbilder, die getrennt zu betrachten sind.
Zwei Arten von Cache-Misses: zu voll und zu lange gewartet
Der erste Fall ist der Kapazitäts-Miss. Der Speicher ist voll, ein neuer Block braucht Platz, und die Verdrängungslogik wirft einen alten hinaus – auch wenn er noch gebraucht würde. Beim Retention-Miss wäre Speicher frei, aber die Zeit ist abgelaufen und der Cache wurde verworfen. Im ersten Fall hilft mehr Platz, im zweiten längeres Behalten. Der Unterschied ist klein, aber folgenreich: Er trennt eine Hardware- von einer Politikfrage.
Innerhalb des Werkzeug-Loops, in dem der Agent im Sekundentakt wiederkommt, sind die Trefferquoten hoch. In der FreeInference-Auswertung liegt die mittlere Hit-Rate nach gewöhnlichen Werkzeugpausen bei 97,5 Prozent, mit einer Spanne von 94 bis 99 Prozent. Eine Simulation im selben Paper kommt auf 98,6 Prozent Idealtreffer über 600 Trajektorien, ein Blogbeitrag zu Lumiere auf 95,7 Prozent der Input-Token, eine Anbieter-Messung von vLLM mit Mooncake auf 94,2 Prozent über 610 Codex-Läufe. Auch der TensorRT-LLM-Technikblog von NVIDIA berichtet einen Wert um 0,97 auf einer Coding-Agenten-Spur.
Die verbleibenden Verluste entstehen in diesen Messungen fast immer durch einen vollen Speicher. NVIDIA zeigt eine „KV-Cache Eviction Cliff“ genannte Klippe: Laufen zu viele Sitzungen gleichzeitig, fällt die Trefferquote auf einer Coding-Spur gegen 0,73. Ein Replay von AgentX- und Mooncake-Spuren ergab, dass eine TTL von fünf Minuten unter Kapazitätsdruck nie auch nur ausgelöst wurde – das Fazit der Autoren lautet knapp „capacity, not liveness“. Der Speicher war voll, lange bevor der Timer ablief.
Was die FreeInference-Spuren über menschliche Pausen zeigen
Die Retention-Misses liegen woanders, nämlich dort, wo der Mensch ins Spiel kommt: Du liest einen Diff, beantwortest eine Rückfrage des Agenten oder machst Mittagspause. In der FreeInference-Auswertung ist Nutzer-Idle damit die häufigste Ursache für Fehltreffer, noch vor allen technischen Gründen. Die mittlere Hit-Rate fällt bei Pausen von 15 bis 30 Minuten auf etwa 58 Prozent und jenseits einer Stunde auf 18 Prozent. Zum Vergleich: nach Werkzeugpausen liegt sie bei 97 Prozent, nach Rückfragen des Agenten an den Nutzer bei 92, nach Subagenten bei 91 und nach einer Nutzerrunde bei 84 Prozent.
Die vorgelagerten Anbieter gehen mit derselben Last sehr unterschiedlich um. In derselben Spur hält ein Anbieter die Trefferquote noch kurz vor der Ein-Stunden-Marke hoch, ein anderer fällt schon nach 15 Minuten unter eine mediane Trefferquote von 50 Prozent. Das ist kein Modellunterschied, sondern ein Unterschied in der Cache-Politik. Für die Praxis heißt das: Die Retention-Eigenschaften eines Anbieters sind ein Beschaffungskriterium, kein Implementierungsdetail.
Die Rechnung dahinter macht eine Simulation im selben Paper greifbar. Bei einer TTL von 15 Minuten müssen menschlich gesteuerte Sitzungen 60,9 Prozent mehr Token im Prefill verarbeiten als bei unendlicher Retention; bei 30 Minuten sind es noch 35 Prozent, bei einer Stunde 21, bei sechs Stunden sieben, bei einem Tag etwa ein Prozent. Die Autoren halten daraus fest: Benchmark-only evaluations therefore substantially understate the retention requirements observed in production.
Warum Benchmarks den Werkzeug-Loop messen und nicht menschliche Pausen
Der Grund für diese Schieflage ist strukturell. Viele öffentliche Replays bauen auf SWE-bench- oder TerminalBench-Läufen auf, in denen kein Mensch mitwirkt; die erwähnten vLLM-Mooncake- und AgentPerfBench-Messungen gehören dazu. Solche Spuren enthalten keine menschlichen Pausen, also können sie auch keine Retention-Misses zeigen. SemiAnalysis‘ AgentX ist teilweise anders gebaut und spielt aufgezeichnete Pausen aus echten Claude-Code-Sitzungen ab, begrenzt aber die systemweite Idle-Zeit im Szenario auf zehn Sekunden und profiliert ein Fenster von einer Stunde. Der Autor der Analyse sieht darin eine Einschränkung: Ein Stundenfenster könne keine Retention über Tage zeigen, also messe auch AgentX überwiegend Kapazität. Das ist seine Interpretation, keine Aussage von SemiAnalysis.
Jeder Benchmark legt einen anderen Ausschnitt fest. AgentX ersetzt die echten Prompts durch synthetischen Text und begrenzt das Offloading auf 3 TB DRAM, was Modellqualität als Messgröße ausschließt. NVIDIA argumentiert in seinem Technikblog für Kennzahlen auf Aufgabenebene, also Jobs pro Stunde pro Nutzer und Jobs pro Stunde pro GPU, weil das Zählen wiederverwendeter Prefix-Token den Durchsatz pro GPU etwa fünfmal zu hoch erscheinen lässt. AgentPerfBench wiederum kritisiert, dass bestehende Benchmarks das Kontextwachstum ignorieren, und AgentSysBench findet, dass in fünf von zehn agentischen Anwendungen nicht das Modell die Latenz dominiert, sondern Sandbox und Infrastruktur – mit Arbeitsständen bis 28 GB pro Sitzung.
Die produktionsnahe Gegenprobe liefert eine Auswertung aus einer Woche GitHub-Copilot-Traffic. Dort liegen die KV-Trefferquoten innerhalb eines Turns bei durchschnittlich 90 Prozent, über Turn-Grenzen hinweg bei 55 Prozent. Modellwechsel und Kontextkompaktierung, bei der das Harness alten Kontext zu einer Zusammenfassung einkocht, machen den Cache nach Einschätzung der Autoren drastisch ungültig. Diese Zahl zeigt, wie weit Produktionsbetrieb und Werkzeug-Loop auseinanderliegen.
Cache-Retention und TTL: wo die Kostenkurve flach wird
Eine TTL funktioniert wie ein Timer an der Werkbank: Jede Anfrage, die den Cache nutzt, setzt ihn zurück. Überlebt die Pause den Timer, wird aufgeräumt, und die nächste Anfrage liest alles neu. Die Analyse sammelt die veröffentlichten Zeitmarken auf einer logarithmischen Achse, von der Sekunde bis zum Tag, und macht damit sichtbar, wie weit die typischen Einstellungen von den tatsächlichen Pausen entfernt sind. Ein Tool-Gap liegt im 90. Perzentil bei 17,2 Sekunden, eine Subagenten-Phase bei 6,2 Minuten, eine Rückfrage an den Nutzer bei 6,3 Minuten, eine Nutzerrunde bei 17,4 Minuten.
Auf der anderen Seite stehen die Grenzen der Systeme: vLLM hat 480 Sekunden als Standard für die Lebensdauer von Decoder-KV-Blöcken, ein Anbieter mit kurzer Prompt-Cache-TTL hielt nach einer Pause von 390 Sekunden null Prozent des Kontexts, einer mit langer TTL noch 82,5 bis 86,5 Prozent. Eine Arbeit zur Ökonomie von Keepalives beziffert das günstigste Client-Intervall unter einer Fünf-Minuten-TTL auf etwa vier Minuten. Und die Kostenkurve selbst hat einen flachen Punkt: In der Simulation sind die Infrastrukturkosten bei 15 Minuten TTL am niedrigsten, die API-Kosten liegen bei 30 Minuten auf dem 0,65-Fachen einer Ein-Minuten-TTL und damit innerhalb von vier Prozent ihres Minimums.
Für SWE-bench-artige Läufe, in denen kein Mensch eingreift, reichen laut Simulation etwa fünf Minuten Retention, um fast die gesamte Wiederverwendung zu behalten. Für menschlich geführte Sitzungen braucht es rund einen Tag. Beide Fälle in einen gemeinsamen Benchmark zu pressen, ergibt keinen Sinn – genau das passiert aber oft.
Was das konkret bedeutet
Die technische Antwort ist zweigeteilt, weil das Problem zweigeteilt ist. Kapazitäts-Misses reagieren auf mehr Speicher, also Offload-Stufen, auf eine bessere Verdrängungspolitik und auf Routing, das zusammengehörige Sitzungen auf demselben Server hält. Retention-Misses reagieren auf längere Lebensdauern für ruhende Sitzungen, auf Pinning, auf Keepalives vom Client und auf Hinweise aus dem Harness, wann eine Pause bevorsteht. Ein Benchmark-Erfolg auf der einen Seite sagt über die andere Seite wenig.
Für den Betrieb heißt das: Wenn du einen Coding-Agenten über längere Zeit begleitest, ist die Cache-Hit-Rate keine Nebenmetrik, sondern eine Stellschraube für TTFT und Prefill-Kosten zugleich. Eine TTL, die auf den Werkzeug-Loop zugeschnitten ist, verschenkt genau das, was den Unterschied zwischen einem flüssigen und einem zähen Arbeitsfluss ausmacht. Die Wahl des Anbieters entscheidet mit, weil dieselbe Last bei unterschiedlichen Cache-Policies zu sehr verschiedenen Trefferquoten führt.
Offen bleibt ein Messproblem. Keine der versammelten Arbeiten beantwortet, ob die Aufgabe tatsächlich fertig wurde und was jeder Erfolg gekostet hat. Alle beantworten, wie schnell der Server auf agentenförmigem Verkehr läuft. Solange die Pausen im Dunkeln liegen, bleibt Prompt-Caching für Coding-Agenten ein Feld, auf dem viel gemessen und wenig gewusst wird.
Quelle: siddhantkhare.com
