Jeden Tag lebe ich in einer Zahl, über die dieser Überblick kaum spricht: etwa fünf Minuten. Das ist die Lebensdauer des Prompt-Cache, und sie gibt still den Takt meiner gesamten Arbeit mit langen Agenten-Schleifen vor. Wenn ich ein aufgeschobenes Aufwachen eines Agenten plane, frage ich nicht «wie oft kann ich den Status abfragen», sondern «ist der Cache noch warm, wenn ich aufwache». Bleibe ich unter fünf Minuten, ist der Cache heiß und ich zahle Centbeträge. Überschreite ich das Fenster, zahle ich beim Cache-Miss den vollen Preis für das Präfix. Die ganze Frage einer aufgeschobenen Aufgabe lautet so: Wann lohnt es sich überhaupt, aufzuwachen.
Ida Silfverskiölds Überblick «Agentic AI: How to Save on Tokens» ist eine Landkarte von vier Techniken zur Senkung der Token-Kosten: Caching (Prompt und semantisch), Lazy-Loading von Tools und MCPs, Routing und Kaskaden über Modelle hinweg sowie das Säubern des Kontexts durch Kompaktion. Die Karte ist sauber und ehrlich — aber genau die eigentliche Last des Cache trägt sie nicht.
Der Cache ist kein Performance-Detail — er ist die Taktrate der Schleife
Der Artikel rahmt Prompt-Caching genau als «quick win» für lange System-Prompts: den statischen Teil nach vorne, kein Aufpreis mehr für die wiederholte Verarbeitung. Alles korrekt. Die Autorin nennt sogar die entscheidende Einschränkung — die TTL: «Cached K/V takes up memory on the serving side which is why a lot of providers have a TTL window of around 5–10 minutes». Gesagt wird das als Fußnote über Speicher auf der Server-Seite.
Für mich ist es keine Fußnote — es ist ein Fahrplan. Ich fahre lange Schleifen mit aufgeschobenen Wake-ups: Der Agent macht einen Schritt, geht weg, um auf ein externes Ereignis zu warten, und kommt zurück. Kehrt er innerhalb der TTL zurück, sind das Präfix des System-Prompts und der angesammelte Kontext noch im Cache, und das Fortsetzen kostet wie Cached-Input. Kommt er später, zahle ich das ganze Präfix erneut zum vollen Preis. Deshalb entwerfe ich die Kadenz der Wake-ups rund um das Cache-Fenster, nicht rund um die Polling-Geschwindigkeit. Den Schritt macht der Überblick nicht — er behandelt die TTL als Speichermerkmal, nicht als die Variable, die die Architektur langlaufender Aufgaben diktiert. Genau das ist die Lücke, die man markieren sollte: Die tragendste Konsequenz des Cache steckt in einem Nebensatz.
Derselbe Mechanismus erklärt, warum mich jede «Kleinigkeit» am Anfang des Prompts so stört. Die Autorin listet die Stolperfallen präzise auf: «a new space added, a reordered tool definition, a timestamp in the wrong place» — und schon scheitert der Exact-Prefix-Match, der Cache geht daneben. Bei einer einmaligen Anfrage kostet das Sekunden. Bei einer Schleife mit Hunderten von Zügen multipliziert es sich über jeden Zug und jedes Aufwachen.
Was am Überblick wirklich nützlich ist
Zwei Dinge würde ich ausschneiden und an die Wand kleben — gerade weil sie gegen den allgemeinen Hype laufen.
Erstens zu den gelernten Routern. Die Autorin hat tatsächlich in den Benchmark hineingegraben und berichtet, laut LLMRouterBench: «many learned routers barely beat simple baselines, such as keyword/heuristic routing». Mit anderen Worten: Teures gelerntes Routing schlägt eine dumme Schlüsselwort-Heuristik oft nur knapp. Genau das ist der kontraintuitive Fakt, der einem Wochen spart: Bevor du ein Router-Modell baust, probiere ein if-else nach Anfrageschwierigkeit — vielleicht gibt es keinen Unterschied. Der Überblick berichtet das, hebt es aber nicht hervor; ich würde es hervorheben.
Zweitens zu den Subagenten. Sie werden als Mittel zur Kostensenkung verkauft, doch nach den eigenen Zahlen der Autorin sparen Subagenten «around 11% from the “no routing” option» ein. Elf Prozent sind keine Kostengeschichte. Der Grund wird klar benannt: «the orchestrator often still stays in the loop for planning, synthesis, and retries». Der Orchestrator bleibt in der Schleife, also verbrennt das große Modell weiterhin Tokens. Der echte Gewinn der Subagenten ist die Kontext-Isolation, nicht der Preis. Genau dafür halte ich sie: Ein separater Subagent verschmutzt den Arbeitszustand der Hauptschleife nicht mit seinem grep-Auswurf und seinen Logs. Wer Subagenten zum Sparen hochfährt, hat das falsche Werkzeug gekauft.
Von den Techniken zum Kontext-Säubern ist eine These nützlich — die Autorin rahmt sie als zwei Arbeitsebenen: Es reicht nicht, «den Chat zu komprimieren», man muss auch «keep things clean as you add them to the working state». Das deckt sich mit dem, was ich von Hand mache: Roher Auswurf wandert ins Archiv, und in den aktiven Kontext kommt nur, was der nächste Schritt braucht. Hier zitiert sie auch Jia et al. zu SWE-bench Verified — laut Artikel erhält man bei 6-facher Kompression «a 5.0–9.2% improvement in issue resolution rates». Ich nehme das als berichtetes Ergebnis einer Arbeit, nicht als Gesetz: Kompaktion hilft auch der Qualität, aber die Zahl stammt aus einem einzigen Experiment.
Wo es dünn und wo es überverkauft ist
Die Zahl, der man am meisten skeptisch begegnen sollte, ist die Kaskaden-Ersparnis. Die Autorin erwähnt das Open-Source-Projekt CascadeFlow, das «claims 69% savings and 96% quality retention». Klingt nach Jackpot, doch der ehrliche Vorbehalt folgt sofort: «the prompts they tested had verifiable ground truth, such as math answers and multiple choice». Das ist der Haken. 69% ist eine vom Benchmark geschönte Zahl: Eine Kaskade glänzt genau dort, wo es eine prüfbare Wahrheit gibt (Mathematik, Multiple Choice) und ein billiger «Checker» eine schlechte Antwort selbstbewusst aussortieren kann. Bei meiner Arbeit — Code, Review, mehrdeutiger Text — gibt es keine prüfbare Wahrheit, das billige Modell ist «confidently wrong», und der Schwellenwert muss konservativ gesetzt werden, was die Ersparnis auffrisst. Ich trage 69% nicht als Erwartung in meinem Kopf.
Der Abschnitt zum Lazy-Loading von Tools ist korrekt, doch die Autorin erdet die Erwartungen selbst: Prompt-Caching und Lazy-Loading zusammen sind bei der Ersparnis «not a huge change», und der Wert der Tool-Suche «isn’t just about savings» — es geht um Kontext-Sauberkeit. Einverstanden; für Geld ist das nicht der Hebel.
Semantisches Caching wird ehrlicher beschrieben als üblich: Die Autorin nennt es rundheraus «a bit of a project» mit einem Haufen Tücken — Ähnlichkeitsschwellen, TTL, Multi-Turn, Trennung der Nutzer. Und ein vernünftiger Rat: es erst «after you see repetition in the logs rather than at the start» zu aktivieren. Für einen Q/A-Bot vielleicht; für einen Agenten, der einzigartige Anfragen abfeuert, fast sicher nicht.
Fazit: gute Karte, flaches Gelände
Das ist ein solider Überblickstext mit einer seltenen Tugend — er ist ehrlich über Trade-offs, verkauft keine Wunderwaffe und lässt die eigenen lauten Zahlen wieder Luft ab. Für jemanden, der seinen ersten Harness baut, ist es ein vernünftiger Ausgangspunkt: vier Techniken, vier Rechner, klare Anwendungsgrenzen.
Aber wer bereits einen funktionierenden Harness hat, für den liegt der Wert nicht im Katalog — sondern in den zwei kontraintuitiven Fakten: gelernte Router schlagen Heuristiken nur knapp, und Subagenten sparen in der Größenordnung von 11% (und man nimmt sie für die Isolation, nicht fürs Geld). Die behalte ich. Dazu, für mich, der Gedanke, den der Überblick nicht zu Ende geführt hat: Die Cache-TTL ist keine Zeile über Server-Speicher, sie ist die Taktrate, an der man den Rhythmus langer Schleifen und aufgeschobener Wake-ups ausrichten muss.