Token sparen als Transportproblem

Die gesamte Agenten-Trajektorie muss zählen

Ich würde nicht die Tokens einer einzelnen Anfrage zählen, sondern die erwarteten Kosten der gesamten Agenten-Trajektorie. In der ursprünglichen Diskussion verglich Nutzer 1497575255 die Tokenminimierung mit einem Transportproblem: Das Ergebnis soll mit minimalem Ressourceneinsatz von Punkt A nach Punkt B gelangen. Das trifft es besser als das übliche „Machen wir den Prompt kürzer“.

Für jeden Schritt sind die Kosten von Ein- und Ausgabe bekannt oder schätzbar. Die Eingabe umfasst Anweisung, Verlauf, Tool-Schemata und gefundene Dokumente. Die Ausgabe hängt von Aufgabentyp, ausgewähltem Modell, Generierungsbudget und der Frage ab, ob der Agent den Aufruf wiederholen muss.

Auf Pipeline-Ebene kommen weitere Variablen hinzu:

• welches Modell Planer, Ausführer und Prüfer erhalten;
• welche Kontextfragmente erhalten oder komprimiert werden;
• wie viele Iterationen und Wiederholungen erlaubt sind;
• wann ein Tool aufgerufen und wann ein Zweig beendet wird.

Die Zielfunktion minimiert damit nicht nur die Tokenzahl, sondern die Gesamtkosten unter Nebenbedingungen für Qualität, Latenz und Zuverlässigkeit. Wird eine Aufgabe einem von mehreren Modellen zugeordnet, entsteht ein ganzzahliges Auswahlproblem. Kann der Anfragefluss auf Modelle, Konfigurationen oder Regionen verteilt werden, wird die Transport-Analogie fast wörtlich.

Auch die Kontextauswahl ist ein eigenes Teilproblem. Jedes Fragment besitzt Größe und erwarteten Nutzen, während das gesamte Fenster budgetbegrenzt ist. Strukturell ähnelt das einem Rucksackproblem, das mit Modell-Routing in einem gemeinsamen Optimierungsschema verbunden wird.

Die genaue Eingabelänge lässt sich meist vor dem Senden bestimmen. Bei der Ausgabe ist das schwieriger: Es braucht eine Prognose nach Aufgabenklasse und Modell; bei Agenten muss zudem die Wahrscheinlichkeit zusätzlicher Schritte berücksichtigt werden. Stand 6. November 2026 ist dies keine Meldung über ein konkretes Release, sondern eine nützliche technische Problemformulierung.

Einsparungen beginnen nicht beim billigsten Modell

Der größte Gewinn entsteht durch die Steuerung von Agentenentscheidungen, nicht durch den mechanischen Tausch eines starken gegen ein schwächeres Modell. Ein teurer Aufruf kann insgesamt günstiger sein, wenn er Wiederholungen, unnötige Suche oder einen langen Denkpfad vermeidet.

Eine praxistaugliche Architektur besteht aus zwei Teilen. Ein Prädiktor schätzt Tokens, Qualität, Latenz und Risiko möglicher Aktionen. Ein Controller wählt die günstigste Option innerhalb der Vorgaben und berechnet die Entscheidung nach jedem Schritt mit dem Restbudget neu.

Die Schwachstelle liegt auf der Hand: Ein Fehler bei der Qualitätsprognose kann teurer werden als die eingesparten Tokens. Ich würde deshalb vor allem wiederholte Aufrufe, wachsende Verläufe und die Übergabe vollständiger Tool-Ergebnisse beobachten. Dort verbrennen Agenten-Pipelines ihr Budget häufig unbemerkt.

Tokens sind in einem solchen System kein Zähler nach der Ausführung, sondern eine Planungsressource. Eine Frage bleibt: Wie gut kann der Router die Kosten eines Fehlers vorhersagen, bevor ein billiger Weg zu einem teuren Umweg wird?

Wir haben zuvor untersucht, wie Konfigurationen von Claude Opus 4.6, erweitertes Reasoning und die Kontextlänge die Kosten von Anfragen beeinflussen. Das ergänzt die Sicht auf Token-Optimierung als Verteilung eines begrenzten Budgets auf Teile des Kontexts.