Du startest eine tiefgehende Recherche mit einem KI-Assistenten, gibst eine komplexe Frage ein und wartest. Nach einer halben Stunde erhältst du eine Fehlermeldung: „Token-Limit erreicht“. Kein Ergebnis, keine Erkenntnis – nur eine leere Hülle und das Gefühl, dein Budget verbrannt zu haben. Genau das passierte einem Entwickler, der die Ökonomie von KI-Agenten erforschen wollte. Sein Ziel: die wahren Kosten von agentischem Coden verstehen und herausfinden, wie man sie optimieren kann. Der erste Versuch scheiterte – frustrierend und lehrreich zugleich.
Der Entwickler baute für sein Forschungsprojekt eine tiefe Recherche-Pipeline mit mehreren KI-Agenten auf. Sie sollten eine vertrauenswürdige Wissensdatenbank erstellen. Die erste Version dieser Pipeline verbrauchte das komplette Kontingent seines Claude Max 5x-Plans in nur 30 Minuten – ohne ein einziges brauchbares Ergebnis zu liefern. 111 Agenten wurden gestartet, 123 Behauptungen zur Überprüfung eingereiht, aber nur 25 überprüft, bevor das Limit riss. Die finale Synthese fand nie statt. Ironischerweise musste er schon beim ersten Tag damit beginnen, Tokens zu sparen, während er noch herausfand, wie man Tokens überhaupt spart. Learning by doing.
Die Strategie: Vorhandene Abos clever nutzen
Statt sofort in teure Zusatzpakete zu investieren, nutzte der Entwickler das, was er bereits hatte: drei separate KI-Abos – Claude, Codex und Antigravity. Warum nicht alle drei parallel nutzen, mit gemeinsamen Speicher? Er erweiterte das claude-mem-Plugin, sodass alle drei Tools während der Sitzungen auf denselben Speicher zugreifen konnten. Was ein Tool lernte, stand auch den anderen zur Verfügung. Das war der erste Schritt zur Kostenkontrolle, ohne zusätzliches Geld auszugeben.
Doch damit allein war es nicht getan. Der Entwickler erkannte, dass nicht jede Aufgabe den teuersten Frontiermodellen überlassen werden muss. Claude Opus 4.8, Claude Sonnet 5, GPT-5.5 und Gemini 3.1 Pro sind für viele Teilaufgaben bereits exzellent. Er durchforstete Benchmarks wie Terminal-Bench, SWE-bench Pro und Artificial Analysis, um herauszufinden, welches Modell für welche Rolle am besten geeignet ist. Die Benchmarks behandelt er nie als absolute Wahrheit, sondern als grobe Richtwerte, die sich monatlich ändern. Daraus entstand eine Aufgabenteilung:
- Finden übernimmt Claude Sonnet 5 – stark auf agentischen Benchmarks und günstig für Masseneinsätze.
- Verifizieren erledigt Claude Opus 4.8 – das genaueste Claude-Modell; Prüfung erfordert mehr Präzision als Suche.
- Bewerten und Planen bleibt Claude Fable 5 vorbehalten – dem teuersten Modell, nur für die Zerlegung von Problemen und die Lösung von Streitfällen.
- Kleine Aufgaben wie Extraktion und Formatierung übernimmt Claude Haiku 4.5 – günstig und schnell, aber zu schwach für mehrstufige Arbeit.
- Werkzeuge ausführen delegiert der Entwickler an Codex (GPT-5.5) – stark auf Terminal-Benchmarks, klont, installiert, führt aus und prüft Tools.
- Zweite Meinung liefert Antigravity (Gemini 3.1 Pro) – eine andere Modellfamilie, nicht dieselben blinden Flecken.
Das Besondere: Codex und Antigravity laufen als „headless“ Subagenten unter der Orchestrierung von Fable. Die Tokens werden aus den jeweiligen Abos verbraucht, nicht aus dem Fable-Topf. Ein kleines Bash-Skript überwacht die Ausgaben auf „usage limit“- und „out of credits“-Meldungen und gibt einen speziellen Exit-Code zurück. Sobald ein Subagent sein Limit erreicht, schaltet der Orchestrator automatisch auf ein Claude-Modell um – die Forschung läuft weiter, ohne Benutzereingriff. Das Ergebnis: Statt 30 Minuten durchgehender Forschung mit Fable allein konnte der Entwickler die Arbeit nun mehrere Stunden am Stück fortsetzen, ohne mehr zu bezahlen.
Halluzinationen reduzieren: Vertrauen durch harte Regeln
Das Kostenproblem war gelöst, aber ein zweites blieb: die Zuverlässigkeit der Ergebnisse. In der ersten Phase, als alles noch über Fable lief, stieß der Entwickler immer wieder auf Falschinformationen: eine falsche Lizenz in einem Repository, eine Einsparungszahl ohne Quellenangabe, eine Zahl, die auf der zitierten Seite gar nicht stand. Um Halluzinationen einzudämmen, führte er explizite Prüfregeln ein. Jede Behauptung muss diese bestehen, bevor sie in die Wissensdatenbank aufgenommen wird.
Die Grundregel: Wer eine Behauptung findet, darf sie nicht selbst überprüfen. Ein anderes Modell oder ein anderer Agent übernimmt die Verifikation von Links, Zitaten und Zahlen. Nichts landet im Wissensspeicher ohne eine URL und ein wörtliches Zitat aus der Primärquelle. Keine Zahl darf genannt werden, wenn die Quellseite sie nicht enthält. Diese Liste wuchs während der Forschung stetig – jedes Mal, wenn eine neue Fehlerklasse entdeckt wurde, floss sie zurück in die Prompts. Der Entwickler betont, dass ein solcher Rahmen nur dann wirklich effektiv ist, wenn man ihn ständig justiert: Funde durchgehen, nutzlose aussortieren und das Feedback zurück in die Pipeline speisen.
Das Tool /deep-research, das die ganze Geschichte auslöste, blieb im Prozess, aber nun als letzter Schritt, nicht als erster. Statt blindlos das Internet zu durchforsten, arbeitet es sich durch die bereits verifizierten Funde, vertieft sie, eliminiert Unrat und füllt Lücken. So verbraucht es auch weit weniger Tokens – zuletzt 61 Agenten in 22 Minuten, verglichen mit den 111 Agenten und dem leeren Ergebnis zu Beginn. Derselbe Befehl, nur eine viel kleinere Aufgabe.
Die Pipeline im Überblick
Der gesamte Ablauf gleicht einer mehrstufigen Fabrik: Finden mit Sonnet, Prüfen mit Opus, Bewerten mit Fable, Ausführen mit Codex für konkrete Belege, tiefe Validierung per Mehrheitsentscheid, dann menschliche Freigabe. Erst danach wandert das Ergebnis in ein LLM-Wiki in Obsidian – inspiriert von Karpathys LLM-Wiki-Muster: verknüpfte atomare Notizen, Agenten, die die Arbeit erledigen, und ein Mensch, der die Regeln vorgibt. Nach einer Woche enthielt das Wiki bereits Hunderte validierte Notizen zu Preisen, Tools, Benchmarks und Praktiken.
Aber auch automatisierte Prüfungen sind nicht unfehlbar. Einmal lehnte eine Triage-Regel stillschweigend das Projekt „Headroom“ ab, ein Projekt mit 56.000 Sternen und eines der größten seiner Kategorie. Die Agenten hatten korrekt gearbeitet, die Verifikation bestätigte die Legitimität des Projekts, und eine Anspruchsprüfung stellte korrekt fest, dass die Schlagzeilen-Einsparungszahlen nicht qualitätsgesichert waren. Doch die Regel des Entwicklers lautete: „Nicht validierte Behauptungen bedeuten kein Eintrag.“ Also blieb ein Projekt, das die halbe Branche nutzt, unsichtbar. Erst zwei Tage später fiel es auf. Die Lösung: lehne die Behauptung ab, nicht das Projekt. Agenten können suchen und prüfen, aber kein Agent wird dir jemals sagen, dass deine eigene Regel der Fehler ist.
Was die Forschung wirklich lehrte
Die Token-Ökonomie entpuppte sich als komplexer als erwartet. Hier einige Erkenntnisse aus dem aufgebauten Wissen:
1. Das Framework kann so wichtig sein wie das Modell. Auf Terminal-Bench zeigte dasselbe Modell eine ~66-fache Token-Spanne über verschiedene Frameworks hinweg, und die schlankeren Setups erzielten sogar höhere Punktzahlen. Eine andere Studie maß einen Ausschlag von etwa 54 Prozentpunkten beim selben Modell, nur durch Veränderung des Frameworks. Der Entwickler erlebte eine kleine Version davon, als er die wahren Kosten eines einfachen „Hallo“ zu einem KI-Agenten untersuchte.
2. Context Compaction kann die Rechnung verdoppeln, statt sie zu senken. Context Compaction klingt nach Kompression – man nimmt an, es sei immer gut –, aber es ist nicht kostenlos: Das Modell muss den Verlauf zusammenfassen, und dieser Zusammenfassungsaufruf verbraucht ebenfalls Tokens. Außerdem kann es Dateien entfernen, die der Agent noch benötigt, sodass dieser sie erneut einliest, der Kontext sich wieder füllt und die Kompaktion erneut feuert. Eine dokumentierte Regression zeigt, wie böse diese Schleife werden kann: Nachdem ein Framework seinen Kompaktionsschwellenwert angepasst hatte, stieg die Anzahl der Kompaktionen von 4 auf 12–26 pro Sitzung, und der Tokenverbrauch für identische Aufgaben kletterte von 89 Millionen auf 160–185 Millionen.
3. Eine einzige Tooländerung mitten in der Sitzung macht den Cache ungültig und erfasst alles neu. Cache-Lesevorgänge kosten etwa 0,1× des Basis-Input-Preises, aber der Cache invalidiert hierarchisch: zuerst Tools, dann System, dann Nachrichten. Füge ein einzelnes Tool-Schema in der Mitte einer Sitzung hinzu oder ordne es um, und der gesamte bisherige Cache-Abschnitt wird zum vollen Preis neu abgerechnet. Es gibt keinen Fehler, nur eine höhere Rechnung.
4. Dein Token-Zähler ist nicht deine Rechnung. In einem dokumentierten Fall landete ein berechneter Betrag von 3,60 $/Monat als Rechnung von 25–40 $/Monat – eine Lücke von 7–11×, die durch Kontextakkumulation, Wiederholungsverstärkung, Framework-Overhead und Auswertungsaufrufe entstand, die eine einfache Tokenschätzung nie erfasst hätte. Der Entwickler kennzeichnet die meisten dieser Erkenntnisse als mittlere Vertrauensstufe – 1 oder 2 solide Quellen – und macht dies transparent, anstatt sie als gesetzt zu behandeln.
Bevor du dein nächstes Limit verbrennst
Wenn du heute deine Limits mit tiefer Recherche aufbrauchst, versuche, die Reihenfolge umzukehren. Günstige Modelle finden, genaue Modelle prüfen, und die tiefe Recherche kommt zuletzt. Und sieh nach, wie viel Intelligenz du bereits bezahlst. Ein paar Abos mit einer klaren Rolle für jedes Modell geben dir weit mehr als ein blind genutztes Frontier-Modell. Baust du selbst eine Forschungspipeline auf oder wächst deine KI-Rechnung schneller als deine Nutzung – dann schau dir die Erkenntnisse dieses Entwicklers genau an. Die Kombination aus menschlicher Kontrolle, geschickter Modellaufteilung und ständiger Regelanpassung ist der einzige Weg, um sowohl Kosten als auch Vertrauen in den Griff zu bekommen. Denn am Ende zählt nicht, wie viele Tokens du verbrennst, sondern was du aus den Ascheresten zurückgewinnst.
Quelle: quesma.com
