Senkung der Kosten für Agent-Token: Caching, Routing und Kontextpflege.

Ein erster Agent beginnt in der Regel mit einem Systemprompt von 500 Token sowie zwei Tools, wobei beide Zahlen tendenziell schnell ansteigen. Der geleakte Claude-Systemprompt soll etwa 24.000 Token lang gewesen sein. Nutzer von OpenClaw berichten, dass bei Gemini 3.1 Pro bereits in der ersten Runde mehr als 150.000 Eingabetoken verwendet wurden, um eine Antwort von 29 Token zu erhalten. Wenn nicht optimiert wird, kostet ein Agent, der täglich 100 Nachrichten mit jeweils 166.000 Eingabetoken verarbeitet, etwa 996 US-Dollar pro Monat bei Gemini 3.1 Pro und rund 2.490 US-Dollar bei Claude Opus 4.6. Durch einige Gestaltungsentscheidungen lässt sich dieser Betrag auf etwa 50 bis 100 US-Dollar senken.

Die hier behandelten Ansätze sind Prompt-Caching, semantisches Caching, Tools zum Lazy-Loading sowie MCP-Server, Routing und Kaskadierung zwischen Modellen, Delegation an Subagenten sowie die Aufrechterhaltung eines sauberen Arbeitskontexts. Jeder dieser Ansätze spart auf unterschiedliche Weise Geld, hat aber jeweils einen Preis in Form von Komplexität oder Qualität – keiner davon ist kostenlos.

Das Material lässt sich in vier Gruppen einteilen. Die erste Gruppe befasst sich mit der Wiederverwendung von Tokens, wo immer möglich, durch Prompt-Caching und semantisches Caching. Die zweite Gruppe betrifft das Weglassen von immer vorhandenen Tokens wie Speicherinhalten und Tool-Definitionen. Die dritte Gruppe umfasst das Routen der Arbeit an kleinere Modelle oder das Wechseln auf größere Modelle sowie die Abwägung zwischen Qualitätsrisiko und Einsparungen. Die letzte Gruppe befasst sich mit der Aufrechterhaltung eines sauberen Kontexts – sowohl aus Leistungsgründen als auch wegen der Kosten – mit einem kurzen Überblick zur Komprimierung.

Hören Sie auf, zweimal für dieselben Tokens zu zahlen

Die Kosten für Modelle entstehen nicht nur durch zu häufiges Aufrufen des Modells. Sie entstehen auch dadurch, dass immer wieder Gebühren für die Verarbeitung desselben Textes anfallen. Zwei völlig unterschiedliche Mechanismen helfen dabei. K/V-Caching ist der Bestandteil von Prompt-Caching, während semantisches Caching eine eigene Methode darstellt. Bei langen System-Prompts bringt Prompt-Caching einen einfachen Vorteil; semantisches Caching erfordert mehr Aufwand und birgt größere Risiken.

Wie das K/V-Caching funktioniert

Bevor ein Modell etwas erzeugen kann, muss es den Prompt verarbeiten, was Rechenleistung erfordert – was wiederum zu Verzögerungen und Kosten führt. Es macht daher Sinn, denselben Inhalt nicht immer wieder zu verarbeiten.

Wenn ein großes Sprachmodell einen Prompt erhält, wird der Text tokenisiert, die Tokens in Vektoren umgewandelt, und innerhalb jeder Aufmerksamkeitsschicht werden diese Vektoren in K/V-Tensoren projiziert.

Caching bedeutet, diese Tensoren zu speichern, damit sie nicht erneut berechnet werden müssen. Ein Inferenzmotor behält bereits während der Generierung K/V-Tensoren bei, denn andernfalls würde die Mathematik nicht in angemessener Geschwindigkeit ablaufen. Der nächste Schritt besteht darin, den Cache nach Beendigung der Antwort beizubehalten und nicht zu löschen.

Bei der nächsten Anfrage prüft das System, ob der Beginn des Prompts mit etwas übereinstimmt, für das es bereits Tensoren hat. Falls ja, lädt es diese und überspringt die Verarbeitung.

Die Vorteile sind mit gerundeten Zahlen leicht erkennbar. Angenommen, die Verarbeitung von 2.000 Tokens dauert eine Sekunde und der Systemprompt umfasst 10.000 Tokens. Durch das Überspringen dieser erneuten Berechnung werden bei jeder Aufruf 5 Sekunden eingespart, wobei die tatsächliche Durchsatzrate stark von der Konfiguration abhängt.

Der Vergleich mit dem gespeicherten Cache muss exakt sein. Wenn sich ein Token ändert, gelten die Tensorwerte für diesen Teil des Prompts nicht mehr und er muss neu verarbeitet werden. Die Leute stoßen ständig darauf: ein zusätzlicher Leerzeichen, eine umgeordnete Tool-Definition oder ein Zeitstempel am falschen Platz führen dazu, dass der Vergleich fehlschlägt.

Deshalb beschleunigt ein gespeicherter Cache die Anfragen und macht sie dadurch günstiger. Die Speicherung ist jedoch nicht kostenlos. Gecachte K/V-Daten belegen Speicherplatz auf der Serverseite, weshalb viele Anbieter Einträge nach etwa 5 bis 10 Minuten verfallen lassen.

Niemand muss das von Grund auf selbst entwickeln, denn Frameworks und API-Anbieter kümmern sich darum – jeweils nach ihren eigenen Regeln. Teams, die ein Open-Source-Modell hosten, verwenden in der Regel ein Serviceframework wie vLLM, das eine integrierte Cacheschicht besitzt. API-Nutzer folgen hingegen der Richtlinie ihres jeweiligen Anbieters.

Prefix-Caching in vLLM

Die Caching-Schicht in vLLM teilt den Prompt in Blöcke auf, berechnet für jeden Block einen Hash aus seinen eigenen Tokenen sowie den vorangegangenen Tokenen und speichert die K/V-Tensoren unter diesen Hashes. Wie bei den meisten Konfigurationen befindet sich der statische Teil, der gekacht werden soll, am Anfang des Prompts.

Drei Flags sind wichtig:

• --enable-prefix-caching aktiviert diese Funktion.
• --block-size legt die Anzahl der Token pro Block fest. Bei einer Blockgröße von 16 beendet das System den Block nach 16 Tokenn und startet einen neuen Block.
• --kv-cache-memory-bytes gibt die Größe des K/V-Caches pro GPU explizit an. Mehr Speicher ermöglicht es, dass gekachtete Blöcke länger bestehen bleiben, doch viele unterschiedliche lange Anfragen gleichzeitig füllen den Cache schneller und alte Blöcke werden früher entfernt.

Es gibt weitere Optionen, darunter SGLang mit RadixAttention für das Caching von Präfixen sowie LMCache, das dazu dient, in Server-Engines integriert zu werden. Die Funktionsweise entspricht der oben beschriebenen.

Caching über API-Anbieter

Die meisten Teams nutzen API-Anbieter, und jeder von ihnen hat Richtlinien, die eingehalten werden müssen, damit Anfragen im Cache landen. Der Prompt muss entsprechend strukturiert sein. OpenAI ist ein klares Beispiel: Das Caching eines Teils des Prompts erfordert eine exakte Präfixübereinstimmung, was bedeutet, dass am Anfang derselbe statische Eingabeteil vorhanden sein muss. Daher werden stabile Anweisungen, Beispiele und Tools zuerst gesendet, während variable Inhalte danach folgen.

Durch das Senden einer prompt-cache-key können ähnliche Anfragen zusammengeführt werden, wodurch die Trefferquote steigt. Das Caching wird automatisch für Prompts mit 1.024 Token oder mehr aktiviert, wobei die ersten 256 Token dazu dienen, Anfragen wieder in denselben Cache zu leiten – daher muss der statische Teil länger als 256 Token sein.

Anthropic funktioniert anders: Die Caching-Funktion muss mit dem Parameter cache-control aktiviert werden. Beim Cache-Leeren tritt in beiden Anbietern in der Regel nach 5 bis 10 Minuten Inaktivität eine Löschung ein, wobei diese Zeit verlängert werden kann. Bei Anthropic lässt sich die Löschzeit für den doppelten Preis auf eine Stunde verlängern.

Beim Selbsthosting bedeutet die eingesparte Zeit auch eingespartes Geld. Bei API-Anbietern zeigt sich der Vorteil in günstigeren, gekachelten Eingabetoken. OpenAI reduziert den Preis für gekachelte Eingaben um bis zu 90 Prozent gegenüber dem normalen Preis. Anthropic gewährt denselben Rabatt auf gekachelte Eingaben, berechnet aber zusätzlich Gebühren für die Aufrechterhaltung des Caches – daher kann Missbrauch letztendlich teurer sein als das Nicht-Caching.

Falls 90 Prozent eines Prompts statisch sind und der Cache richtig genutzt wird, sinken die Kosten stark, wie der Chart zeigt.

Für diesen Vergleich wurde ein interaktiver Rechner entwickelt, damit die Zahlen angepasst werden können. Im Großen und Ganzen ist das schnelle Caching ein klarer Vorteil für alle, die einen langen, unveränderlichen Systemprompt haben.

Semantisches Caching

Semantisches Caching ist etwas völlig anderes. Es basiert auf der Bedeutung: Wenn eine neue Anfrage einer früheren ähnlich genug ist, wird die gespeicherte Antwort zurückgegeben. Das klingt einfach, doch es gibt klare Fallstricke.

Das Abgleichen von Texten nach Bedeutung verwendet Embeddings, also Vektoren, die mithilfe der Kosinusähnlichkeit verglichen werden. Hohe Ähnlichkeit sollte eine ähnliche Bedeutung bedeuten, doch das hängt vom Embedding-Modell ab.

Der Vorschlag besteht darin, ähnliche Anfragen mit bereits vorhandenen Antworten zu verknüpfen. Eine Frage wie „Was ist die Hauptstadt Frankreichs?“ sowie eine hastige Anfrage wie „Schnell, gib mir die Hauptstadt Frankreichs!“ sollten beide auf dieselbe gespeicherte Antwort verweisen, ohne dass dazu erneut ein LLM aufgerufen werden muss. Dies funktioniert gut, wenn viele Menschen nahezu identische allgemeine Fragen stellen und die zugrundeliegenden Daten allmählich veralten.

Warum wird das dann nicht überall angewandt? Weil viel schiefgehen kann. Die Konzeption muss mehrere Fragen klären:

• Welches Ähnlichkeitsniveau gilt als Übereinstimmung.
• Wie lange bleibt eine Antwort gültig.
• Wie werden mehrstufige Gespräche abgewickelt.
• Was wird tatsächlich gespeichert.
• Ob ein Router vorgeschaltet werden sollte.
• Wie werden Benutzer getrennt gehalten.
• Was passiert, wenn eine falsche Antwort im Cache landet.

Die Lebensdauer verdient besondere Aufmerksamkeit, da Informationen bei verschiedenen Fragen in unterschiedlichem Tempo veralten. Die Mechanismen sind einfach, doch für den praktischen Einsatz sind Metadatenfilter und -tags erforderlich – wie z. B. Benutzer, Arbeitsbereich, Corpus-Version, Persona, Sitzungsumfang, ein intelligenter TTL sowie Regeln dafür, ob eine zurückgegebene Übereinstimmung ausreichend gut ist. Dadurch entsteht ein kleines Projekt.

Ein praktikabler Entwurf nutzt den semantischen Index, um eine frühere Frage zu finden, und ermöglicht es verschiedenen Fragen, auf dieselbe gespeicherte Antwort zu verweisen – wodurch das Speicherwachstum begrenzt wird. Der TTL kann der Nutzung angepasst werden: Häufig wiederverwendete Einträge sollten länger gespeichert bleiben, während die übrigen gelöscht werden. Es ist außerdem ratsam, dies erst nachdem aus den Protokollen Wiederholungen erkennbar sind umzusetzen und nicht von Anfang an, da einige Anwendungsfälle einfach nicht dafür geeignet sind.

Viele Datenbanken können diese Aufgabe übernehmen, und Bibliotheken kümmern sich um die dahinterliegenden Mechanismen – darunter semanticcache, prompt-cache, GPTCache, vCache, Upstash semantic-cache sowie Redis mit LangCache.

Die Einsparungen können tatsächlich erheblich sein. Redis gibt an, dass bis zu 68,8 % weniger API-Aufrufe erforderlich sind und die Latenz um 40 bis 50 % sinkt, wobei diese Zahlen teilweise werblich motiviert sind, da sie aus einem simplen Frage-Antwort-Szenario stammen. Die Ergebnisse hängen vollständig von der Konfiguration ab: Ein Q&A-Bot mit vielen redundanten Aufrufen spart mehr, während ein Programmier-Assistent, dessen Aufrufe alle einzigartig sind, weniger spart.

Prompt-Caching ist besonders nützlich, wenn sich eine sich ändernde Frage innerhalb eines großen, statischen Prompts befindet, und semantisches Caching kommt dann zum Tragen, wenn Menschen dieselbe Frage immer wieder anders formulieren. Eine semantische Übereinstimmungsrate von 15 % bringt nur geringe Einsparungen, doch ab einer Rate von 45 bis 50 % wird es lohnenswert.

Auch in Bezug darauf, was schiefgehen kann, unterscheiden sich die beiden Ansätze. Ein Fehlschlag beim Prompt-Caching kostet nur den normalen Preis, wodurch der Fehler günstig und offensichtlich ist. Ein Fehlschlag beim semantischen Caching ist ebenfalls harmlos, doch ein falscher Treffer nicht: Der Benutzer erhält eine Antwort, die für eine andere Frage verfasst wurde, in völligem Glauben daran, dass sie korrekt ist, und nichts in den Protokollen weist darauf hin. Diese Asymmetrie ist der Grund, warum semantisches Caching konservative Ähnlichkeitsschwellenwerte, Benutzerbereichung sowie eine Möglichkeit zur Überprüfung der Treffer erfordert, während Prompt-Caching hauptsächlich eine disziplinierte Strukturierung der Prompts benötigt.

Auch das herkömmliche Caching verdient Erwähnung. Teure, deterministische Berechnungen wie die Ergebnisse von SQL-Abfragen, Tool-Ausgaben und Suchergebnisse sollten gecacht werden, damit sie nicht häufiger ausgeführt werden müssen als nötig. Ein Beispiel hierfür ist ein Tool, das Schlüsselwörter zur Zusammenfassung sammelt, diese cacht, bis sie veraltet sind, und sie nur dann erneut ausführt, wenn dieser Weg wieder genutzt wird.

Semantisches Caching ist ein interessantes Konzept, das in bestimmten Anwendungsfällen Tokens speichert, doch eine gute Umsetzung erfordert technisches Know-how.

Laden Sie nicht inaktive Tokens vor

Ein Systemprompt kann aufgrund umfangreicher Tool-Definitionen oder wachsender Speichermengen an Größe zunehmen. Kleine Agenten spüren das nicht, doch bei stetig wachsenden Agentenspezifikationen lässt sich die Größe verringern, indem Informationen auf Anfrage abgerufen werden – oder zumindest versucht wird, dies zu tun.

Halten Sie die stets geladene Schicht klein

Sobald der Prompt eines Agenten eine bestimmte Größe überschreitet, sollte die stets geladene Schicht klein und konstant bleiben, wobei detailliertere Informationen getrennt davon gespeichert werden. Das Laden von einigen hundert Tools oder das Senden ständig ändernder vollständiger MCP-Serverbeschreibungen verursacht Unordnung.

Das Problem betrifft sowohl die Leistung als auch die Kosten. Wenn sich jede Schicht ständig ändert, wird das Caching von Prompts ebenfalls viel schwieriger umzusetzen. Die oberste Schicht sollte kompakt und stabil sein, ausreichend, um dem Modell mitzuteilen, wo es sich befindet und wohin es als Nächstes gehen soll, ohne bereits von Anfang an alle Informationen mitzuführen.

Berichten zufolge folgt Claude Code diesem Muster hinsichtlich des Speichermanagements. Eine Indexdatei wird stets geladen und soll nicht länger als 200 Zeilen werden, während detaillierte Themendateien an anderer Stelle gespeichert sind. Wie sich der Agent in der Praxis verhält im Vergleich zu dem, was das System vorsieht, ist eine separate Frage. Ähnliche Ansätze finden sich in der fortgeschrittenen Tool-Einrichtung von Claude, im schichtweisen Design der Claude Skills sowie bei Versuchen, MCP-Tools verspätet zu laden, anstatt alle Serverdefinitionen bereits im Prompt mitzuführen.

Funktioniert es?

Das Prinzip bleibt gleich: Wenn der Kontext umfangreich wird, hat das Modell größere Schwierigkeiten, die richtige Aktion auszuwählen. Der Bereich ist noch jung, daher zeigt ein konkretes Tool, wie es funktionieren kann.

Vor einigen Monaten veröffentlichte Anthropic eine fortschrittliche Tool-Suchfunktion, die dazu dient, den Umfang des Kontexts zu verringern – selbst dann, wenn das Modell auf Hunderte von Tools zugreifen kann. Das Unternehmen gibt an, vor der Optimierung 55.000 bis 134.000 Tokens an Tooldefinitionen festgestellt zu haben, und dass das Auswählen des falschen Tools ein häufiges Problem ist, wenn der Kontext so groß wird.

Ein Suchtool optimiert den Kontext, indem es dem LLM ermöglicht, nach Tools zu suchen, anstatt diese alle im Voraus definieren zu müssen. Eine Konfiguration sieht wie folgt aus:

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Eine Tool namens tool_search wird mithilfe einer vorgefertigten Option – BM25 oder Regex, oder eine eigene – definiert. Anschließend wird zu Veranschaulichungszwecken ein einzelnes Tool als aufgeschoben markiert. Das lohnt sich nur bei 10 oder mehr Tools. Anthropic führt die Suche durch, wodurch die Art und Weise, wie das Tool-Schema in den Systemprompt eingefügt wird, sowie die Suche selbst verborgen bleiben. Sobald ein Tool passt, wird seine Definition als tool_reference-Block direkt in das Gespräch eingefügt.

Die Idee ist gut, da sie einen kleineren Ausgangskontext bietet – allerdings zu Lasten eines zusätzlichen Suchschritts. Tests mit 4.000 Tools ergaben eher enttäuschende Ergebnisse, sodass weiteres Testen notwendig ist. Zudem müssen die Tools gut beschrieben sein, damit sie gefunden werden können, und das Debuggen wird schwieriger, wenn der Zwischenschritt unsichtbar ist.

Dieses Muster tritt an anderen Stellen unter dem einfachen Label guter KI-Engineering-Praxis auf. Setzen Sie den Agenten nicht einem riesigen, unübersichtlichen Kontext aus. Geben Sie ihm eine Möglichkeit, die Auswahl einzugrenzen, und lassen Sie ihn nur dann ein Tool überprüfen oder laden, wenn es benötigt wird.

Die Ersparnisse hängen davon ab, wie viele Tokens ursprünglich übertragen werden. Ein zweiter Rechner vergleicht die Suche nach Tools mit dem Caching von Prompts.

Das obige Beispiel zeigt die geschätzten Ersparnisse durch das Caching von Prompts in Kombination mit verzögert geladenen Tools. Beides bringt Ersparnisse, doch die Kombination bewirkt im Vergleich zu jeweils einem allein keinen besonders großen Unterschied. Die Suche nach Tools dreht sich nicht nur um Kosten, sondern sorgt auch dafür, dass der Kontext für bessere Leistung sauber bleibt. Wenn es nur um Ersparnisse geht, ist die Anwendung von mindestens einem der beiden Ansätze der größte Vorteil.

Verwenden Sie günstige Modelle für einfache Aufgaben

Dieser Abschnitt behandelt das Leiten von Anfragen an verschiedene Modelle sowie die Verwendung günstigerer Subagenten für bestimmte Aufgaben. Beides kann die Kosten pro Token senken, birgt aber auch das Risiko für die Qualität. Viele sind der Ansicht, dass 60 Prozent oder mehr der eingehenden Fragen einfach sind und kein besonders leistungsstarkes Modell benötigen – schon gar nicht eines, das zum logischen Denken fähig ist.

Commerzielle Produkte erledigen bereits Teile davon. Berichten zufolge leitet ChatGPT Anfragen anhand von Kriterien wie Gesprächstyp, Komplexität, Tool-Anforderungen sowie expliziten Absichten wie „gründlich überlegen“ weiter, während Claude auf beschreibungsbasierte Delegation sowie integrierte Subagenten wie Explore setzt. Das Konzept ist leicht zu verstehen; schwierig ist es, dies ohne Einbußen bei der Qualität umzusetzen. Im Folgenden werden prädiktive Routings sowie ansatzbasierte Methoden wie Kaskaden und Subagenten behandelt, und ein dritter Abschnitt zeigt die Einsparungen auf.

Nach Schwierigkeitsgrad routen

Die routenbasierte Verarbeitung auf Anfrageebene schätzt die Schwierigkeit und Absicht bereits vor dem Erstellen jeglicher Ausgabe ein. Der Vorteil ist groß, doch eine falsche Entscheidung kann eine ganze Sitzung beeinträchtigen, weshalb die Qualität ein echtes Problem darstellt. Ein bestimmtes Router-Modell muss entscheiden, wohin jede Anfrage geleitet werden soll.

Die Routesignale von OpenAI sind nicht öffentlich zugänglich, und Nutzer haben oft das Gefühl, zu einem schwächeren Modell versetzt worden zu sein – und zwar in unangenehmen Momenten. Die Open-Source-Welt bietet mehr Optionen zur Untersuchung. RouteLLM von LMSYS, der Gruppe aus Berkeley hinter Chatbot Arena, lernt anhand echter Präferenzdaten, die in der Arena gesammelt wurden. Es kombiniert Standard-Embeddings mit einem kleinen Router-Modul, was die Hostkosten niedrig halten sollte; seine Entwickler berichten von erheblichen Kostensenkungen bei Beibehaltung der Leistungsfähigkeit von GPT-4. Diese Behauptung wurde hier nicht unabhängig getestet.

Das Paper LLMRouterBench weist darauf hin, dass viele gelernte Router kaum bessere Ergebnisse erzielen als einfache Baselines wie Schlüsselwort- oder heuristische Routing-Methoden sowie das Verwenden von Nachbarnähern und kNN-basierten Ansätzen.

Die aufwendigeren Router bringen möglicherweise keinen nennenswerten Vorteil gegenüber einfachen Lösungen. Die Menschen haben das Routing noch nicht aufgegeben und experimentieren weiter, doch Einsparungen sind nicht garantiert, wenn die Antwortqualität nicht mithalten kann. Es gibt auch gehostete Optionen wie OpenRouter Auto und Switchpoint, doch keine öffentlichen Quellen beschreiben deren internes Routing-Verhalten oder Genauigkeit. Der Rechner vergleicht LLMRouter, Heuristiken, einen selbst gehosteten Klassifikator, LLM-as-Router, RouteLLM und OpenRouter Auto. Für die Qualität in der Praxis sind angemessene Tests mit klaren Zahlen erforderlich – etwas, das diesem Bereich zu Recht zusteht.

Fangen Sie günstig an und steigern Sie bei geringer Zuverlässigkeit auf

Anstatt zu versuchen, die Schwierigkeit einer Anfrage anhand des Eingabetextes vorherzusagen, kann das günstige Modell zunächst antworten und anschließend eine Überprüfung entscheiden, ob die Antwort beibehalten oder ein aufwändigeres Modell eingesetzt werden soll. In Googles Artikel „Speculative Cascades“ wird dieser Kompromiss beschrieben: Kleine Modelle werden aus Kostengründen und wegen der Geschwindigkeit zuerst verwendet, größere Modelle nur dann, wenn sie benötigt werden.

Das günstige Modell erzeugt die Antwort, danach prüft ein leichtgewichtiges Überprüfungsmodul Signale wie Logwahrscheinlichkeiten, Entropie oder Unsicherheitsgrade im Margin-Stil sowie semantische Übereinstimmung.

Der Ansatz ist attraktiv, da die Schwierigkeit des Eingabetextes schwer vorherzusagen ist und die meisten Router nicht perfekt funktionieren, während die Qualität einer Antwort leichter beurteilt werden kann, sobald sie vorliegt. Er macht nur Sinn, wenn die meisten Fragen vom einfachen Modell beantwortet werden können, da aufwändigere Modelle zwei Anfragen erfordern. Teams, die diesen Ansatz nutzen, berichten, dass die Verzögerung zwischen den Anfragen unter 20 ms liegen kann.

Eine Open-Source-Implementierung namens CascadeFlow verspricht im Vergleich zu GPT-5 Einsparungen von 69 % bei gleichzeitiger Beibehaltung einer Qualität von 96 %. Die zur Testung verwendeten Anfragen verfügten jedoch über nachprüfbare Referenzwerte, wie beispielsweise Mathematiklösungen oder Multiple-Choice-Fragen. Die Hauptbesorgnis besteht darin, dass kleine Modelle oft zuversichtlich falsch liegen; daher kann es sinnvoll sein, mit konservativen Schwellenwerten zu beginnen und diese häufiger anzuheben, was die Kosten erhöht. Die Ergänzung eines kostengünstigen Kaskadierungsmechanismus zum Rechner deutet auf Einsparungen von rund 50 % hin – vorausgesetzt, für bestimmte Anfragen werden überhaupt größere Modelle benötigt.

Delegation an Subagenten

Subagenten delegieren Aufgaben an isolierte Agenten, die manchmal kleinere Modelle verwenden; dies stellt ebenfalls eine Form der Routierung dar. Die Einsparungen sind hier geringer. Der Nutzen liegt außerdem darin, den Kontext sauber zu halten, damit jeder Agent sich voll und ganz auf seine eigene Aufgabe konzentrieren kann.

Claude Code kommt mit integrierten Subagenten aus. Der Explore-Subagent ist explizit ein Haiku-Arbeiter zur Erkundung und Suche in einer Codebasis, wobei dabei das Konzept günstigerer Modelle für einfachere Aufgaben angewandt wird. Die Hauptsession delegiert ebenfalls Aufgaben, indem sie Beschreibungen abgleicht – unsichtbar für den Benutzer –, wodurch dieser nur eine niedrigere Gesamtrechnung sieht. Da der Orchestrierer in der Regel weiterhin an Planung, Synthese und Wiederholungsversuchen beteiligt ist, sind die Einsparungen geringer als bei der Routenverwaltung.

Laut den Angaben des Rechners sparen die Subagenten etwa 11 % gegenüber der Option ohne Routenverwaltung, weshalb sie allein nicht das wichtigste Mittel zur Kostensenkung darstellen.

Bewahren Sie den Kontext sauber

Gute Kontextverwaltung ist hauptsächlich eine Leistungsfrage, kann aber auch die Kosten beeinflussen. Im Laufe der Zeit sammeln Agenten Unordnung an: veraltete Versuche, alte Pläne, doppelte Zustände, Protokolle, wiederholte Beobachtungen sowie rohe Tool-Ausgaben. Neue Agentenentwickler sind besonders anfällig dafür, da sie die Ergebnisse ständig in den Arbeitszustand des Hauptagenten schreiben.

Das kommt überall vor. OpenClaw-Nutzer beschweren sich über die Anhäufung von Kontextinhalten, genauso wie Claude Code-Nutzer – schließlich ist das Hinzufügen von Inhalten einfacher als dessen Aufräumen.

Der schwierige Teil ist die Zustandsverarbeitung

Es handelt sich dabei um ein zweistufiges Problem. Es geht nicht nur darum, den Chat zu komprimieren. Auch neuer Inhalt muss sauber bleiben, sobald er in den Arbeitszustand gelangt – und das erfordert aufwendige Ingenieursarbeit. Ein schlechtes Muster sieht so aus, dass der Agent ständig rohe Ausgaben in den Kontext schreibt:

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

Die eigentliche Aufgabe besteht darin, den richtigen Zustand beizubehalten, während im Zuge dessen Überflüssiges entfernt wird. Die Rohausgabe kann in ein Archiv gespeichert werden, wobei nur das Notwendige im aktiven Kontext verwendet wird. Der Feind ist in der Regel die Überfüllung durch Werkzeugausgaben, weshalb es zum Aufgabenbereich gehört, Werkzeuge standardmäßig weniger aufwendig zu gestalten. Ein gesünderer aktiver Kontext sieht so aus:

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

Besondere Kontextelemente können außerdem ein Lebenszyklus oder eine Ablaufzeit haben. Sobald eine Kompression notwendig wird, ist es einfacher zu erkennen, was das LLM tatsächlich benötigt.

In Anthropics Anmerkungen zu Langzeitaufgaben heißt es, dass die Kompression architektonische Entscheidungen, ungelöste Fehler sowie Implementierungsdetails beibehalten sollte. LangChains autonome Kompressionsfunktion ermöglicht es dem Agenten, selbst zu entscheiden, wann komprimiert werden soll, anstatt bis zum Zeitpunkt des Überlastungszustands des Kontexts zu warten – was offenbar Anthropics Ansatz ist. Teams beginnen, Kompression als Systemproblematik zu betrachten, mit Benchmarks und agentenspezifischen Richtlinien, anstatt sie weiterhin als allgemeinen Zusammenfassungstrick zu sehen.

In einer aktuellen Veröffentlichung von Jia et al. wird argumentiert, dass bei einer 6-fachen Kompression eine Reduzierung des Token-Budgets um 51,8 bis 71,3 Prozent sowie eine Verbesserung der Problemlösung um 5,0 bis 9,2 Prozent auf dem SWE-bench Verified erzielt werden konnte. Es geht also nicht nur um Kosten – sie verbessert auch die allgemeine Leistung.

Durch das Entfernen von Unnötigem kann zuverlässig 30 bis 70 Prozent eines Kontexts bereinigt werden, was in Dollarbeträgen ähnlich viel einspart. Bei einem Kontextfenster von 10.000 kann die Bereinigung von 30 bis 50 Prozent bei 100.000 Ausführungen bis zu 1.500 Dollar einsparen, und bei 40.000 steigt diese Summe auf 6.000 Dollar. Komprimierungsagenten, die bereits sehr kleine, günstige Modelle verwenden, können teurer sein als sie einsparen. Dennoch opfert ein sauberer Kontext nicht die Qualität wie semantisches Caching oder Routing, sodass eine gute Umsetzung einen klaren Vorteil bringt. Der Haken ist jedoch die notwendige Mühe dafür.

Auswahl unter ihnen

Es gibt vier Möglichkeiten, die Kosten für Tokens zu senken, und die richtige Kombination hängt vom Anwendungsfall ab:

• Verwenden Sie Prompt-Caching mit großen System-Prompts, die bei wiederholten Aufrufen des LLM unverändert bleiben.
• Verwenden Sie semantisches Caching für einen allgemeinen Q&A-Bot, der kostengünstig bleiben muss.
• Testen Sie Routing, wenn der Agent sowohl einfache als auch schwierige Fragen bearbeiten muss.

Halten Sie den Kontext so sauber wie möglich, um unnötige Token zu vermeiden.