Kostenkontrolle für Agenten: FinOps für autonome KI

Weil ein Agent kein einzelner Aufruf ist, sondern eine Schleife: Er plant, ruft ein Tool auf, liest das Ergebnis, entscheidet und wiederholt, oft viele Male, bevor eine einzige Aufgabe erledigt ist. Jeder dieser Durchläufe verbraucht Tokens, sowohl für das Reasoning des Modells als auch für das Neulesen des mitgeführten Kontexts, sodass die Rechnung mit der Zahl der Schritte skaliert, nicht mit der scheinbaren Größe der Frage. Zwei Dinge verstärken das weiter. Ein großer, bei jeder Iteration neu gesendeter Kontext vervielfacht den Token-Verbrauch über die ganze Schleife, und Multi-Agent-Systeme legen Nachrichten zwischen Agenten obendrauf, wo Agenten Tokens fürs Miteinanderreden ausgeben. Das Ergebnis ist, dass eine komplexe Aufgabe um Größenordnungen mehr kosten kann als die eine Completion, die in ihrem Kern zu liegen scheint, und weil der Pfad variiert, kann dieselbe Aufgabe von Lauf zu Lauf sehr unterschiedlich kosten. Genau deshalb müssen Kosten ein überwachtes Produktionssignal für Agenten sein, keine Überschlagsrechnung aus dem Token-Preis.

Schleifen und Wiederholungen, dicht gefolgt vom Neulesen eines großen Kontexts bei jeder Iteration. Ein gesunder Agent macht bei jedem Durchlauf Fortschritt; ein ungesunder wiederholt Schritte, versucht dieselbe fehlschlagende Aktion erneut oder kreist ohne Konvergenz, und weil er nicht fehlschlägt, kann er still eine hohe Rechnung auflaufen lassen, bevor jemand auf die Rechnung schaut. Kontext-Neulesen ist der leisere Verwandte: Sendet jede Iteration die volle Historie und ein großes abgerufenes Dokument erneut, zahlen Sie für diese Tokens immer wieder, selbst wenn die Schleife sich gut verhält. Beide sind heimtückisch, gerade weil nichts abstürzt — der Agent wirkt beschäftigt, und die Kosten wachsen im Hintergrund. Die Kontrollen, die sie fangen, sind Loop-Detection, die einen ohne Fortschritt wiederholenden Agenten stoppt, und Budgets pro Aufgabe, die deckeln, was ein einzelner Lauf ausgeben darf, und ihn sicher abbrechen, wenn das Limit erreicht ist. Zusammen verwandeln sie einen offenen Worst Case in einen begrenzten.

Hängen Sie Token- und Kostenattribute an jeden Span Ihrer Traces und aggregieren Sie diese Daten pro Aufgabe, pro Agent und pro Tool, damit Sie nicht nur die Summe sehen, sondern auch, wo sie sich konzentriert. Die Disziplin pro Span zählt, weil eine einzige Zahl auf der Monatsrechnung nichts Umsetzbares sagt; nach Schritten aufgeschlüsselte Kosten zeigen, dass ein Tool oder ein schleifender Sub-Agent für den Großteil der Ausgaben verantwortlich ist. Sobald Kosten in Ihren Dashboards neben Latenz und Completion-Rate stehen, hören sie auf, eine Wochen später eintreffende Überraschung zu sein, und werden zu einer Metrik, die Sie im Moment steuern, mit Alarmen auf Anomalien und durchsetzbaren Budgets. Deshalb sind Kosten im Kern ein Observability-Problem: Man kann keine Zahl steuern, die man nicht sieht, und dasselbe Tracing, das einen Lauf debuggen lässt, lässt ihn auch bepreisen. In vielen Teams ist es zudem das Sichtbarmachen der Kosten, das den ganzen Observability-Aufwand finanziert, denn Finanzen verstehen eine entlaufene Rechnung schneller als eine technische Abstraktion.

Oft ja, wenn Sie nach Schwierigkeit routen, statt ein großes Modell für alles zu nutzen, denn vieles, was ein Agent in jeder Schleife tut, ist Routine — klassifizieren, extrahieren, den nächsten Schritt entscheiden — und braucht nicht Ihr leistungsfähigstes Modell. Das Muster ist Modell-Right-Sizing: Nutzen Sie ein kleines, günstiges Modell für die häufigen, leichten Schritte und reservieren Sie das größte für das wirklich schwere Reasoning, mit einer klaren Regel, wann eskaliert wird. Gut gemacht, senkt das die Kosten erheblich und lässt die End-to-End-Qualität im Wesentlichen unverändert, weil die schweren Schritte weiterhin das starke Modell bekommen. Die Risiken sind real und steuerungswürdig: ein zu aggressives Downgrade kann still die Completion-Rate senken, und eine schlechte Routing-Entscheidung kann einen schweren Schritt an ein schwaches Modell schicken, also brauchen Sie Ihre Evals und Completion-Rate-Metriken, um Regressionen zu erkennen, bevor sie Nutzer erreichen. Behandeln Sie es als gemessene Optimierung, nicht als pauschalen Wechsel — ändern Sie das Routing, beobachten Sie dann Qualität und Kosten zusammen und behalten Sie den günstigeren Pfad nur dort, wo er die Qualität hält.