Tokens zeigen nur einen Teil der Rechnung Ein KI-Agent ist kein schnellerer Nutzer

Ein Gastbeitrag von Gabriel-James Safar* 5 min Lesedauer

Anbieter zum Thema

Eine einzige Anweisung an einen KI-Agenten kann Dutzende oder Hunderte weitere Aktionen auslösen – von API-Aufrufen bis zu Datenbankabfragen. Wer nur die Tokenkosten misst, übersieht daher einen großen Teil des tatsächlichen Infrastrukturverbrauchs. So können Unternehmen die Aktivitäten ihrer Agenten sichtbar machen und begrenzen.

KI-Agenten lösen oft zahlreiche Aktionen im Hintergrund aus. Deshalb zeigen die Tokenkosten nur einen Teil der tatsächlichen Rechnung.(Bild: ©  javu - stock.adobe.com)
KI-Agenten lösen oft zahlreiche Aktionen im Hintergrund aus. Deshalb zeigen die Tokenkosten nur einen Teil der tatsächlichen Rechnung.
(Bild: © javu - stock.adobe.com)

Die meisten Diskussionen über die Kosten agentenbasierter künstlicher Intelligenz (KI) drehen sich um Tokens. Teams vergleichen Modellpreise, beobachten Inferenzkosten und verschieben einfache Aufgaben auf günstigere Modelle. Doch für Finanzverantwortliche stellt sich eine andere Frage: Warum wächst die Rechnung schneller als die Zahl der Nutzer?

Der Tokenverbrauch beantwortet diese Frage nur teilweise. Denn eine einzelne Anweisung an einen KI-Agenten kann Dutzende, Hunderte oder Tausende nachgelagerte Operationen auslösen. Der Agent fragt APIs ab, durchsucht Telemetriedaten, ruft Dokumente ab, prüft Hypothesen und wiederholt erfolglose Schritte. Jede dieser Operationen verbraucht Infrastruktur außerhalb des Modells selbst. Und genau diese Last taucht auf keiner Token-Rechnung auf.

Wie real dieses Problem ist, zeigte sich im Frühjahr dieses Jahres bei Uber. Der Fahrdienstvermittler hatte im Dezember 2025 damit begonnen, den agentengestützten Programmierassistenten Claude Code unternehmensweit einzuführen. Innerhalb eines Monats stieg die Nutzung unter den rund 5.000 Entwicklern von 32 auf 84 Prozent. Laut CTO Praveen Neppalli Naga war das für 2026 vorgesehene KI-Budget fürs Programmieren bereits nach vier Monaten aufgebraucht. Uber begrenzte die Ausgaben daraufhin auf 1.500 US-Dollar pro Werkzeug und Mitarbeiter im Monat.

KI-Agenten beanspruchen mehr Infrastruktur als menschliche Nutzer

Bemerkenswert ist, was diese Zahlen nicht zeigen. Sie beziffern die reinen Tokenkosten für Coding-Agenten, nicht jedoch die im Hintergrund erforderliche Infrastruktur, wenn ein Agent Systeme abfragt, Tests ausführt oder Deployments prüft. Genau das ist der blinde Fleck: Selbst ein Unternehmen, das seine Modellkosten auf den Cent genau überwacht, sieht nicht, welche Rechenleistung, Storage-I/O, API-Aufrufe und Netzwerklast ein Agent auslöst, um zu einem Ergebnis zu kommen.

Die meisten Unternehmensanwendungen wurden für das Verhalten von Menschen entworfen. Ein Nutzer öffnet eine Seite, prüft das Ergebnis und entscheidet über den nächsten Schritt – meist nacheinander und mit natürlichen Pausen.

Agenten arbeiten anders. Sie zerlegen ein Ziel in viele Teilaufgaben, führen diese parallel aus und iterieren weiter, bis sie das Ziel als erreicht einstufen. Scheitert ein Versuch, probieren sie eine abgewandelte Variante aus, ohne dabei die kumulierte Last für die zugrunde liegenden Systeme zu berücksichtigen. Wie das in der Praxis aussieht, zeigt ein typischer Fall aus dem Alltag von Engineering-Teams: Ein Incident-Investigation-Agent soll klären, warum die Checkout-Latenz nach dem letzten Deployment gestiegen ist. Er ruft Deployment-Metadaten ab, durchsucht Anwendungslogs, vergleicht Latenzmetriken, prüft Traces, untersucht nachgelagerte Services und wiederholt das Ganze für mehrere Zeitfenster, Servicenamen und Regionen.

Ein kleines Rechenbeispiel: Fünf parallele Untersuchungspfade mit je fünf Wiederholungsversuchen und drei abgefragten Systemen ergäben bereits 75 einzelne Operationen für eine einzige Frage. Bei mehreren gleichzeitig laufenden Vorfällen oder einer zu großzügigen Retry-Policy wächst diese Zahl schnell in die Tausende, und das, bevor es jemand bemerkt.

Wenn Agenten wie automatisierte Angriffe wirken

Unkontrollierte Agenten verursachen nicht nur Kosten, sondern auch Verfügbarkeitsprobleme. Ein Dienst, der plötzlich ungewöhnlich viele Anfragen erhält, aktiviert häufig Rate-Limits oder automatisierte Schutzmechanismen. Aus Sicht des Dienstes sind Hunderte parallele Anfragen eines Agenten kaum von missbräuchlicher Automatisierung zu unterscheiden.

Das erklärt, warum nicht alle Zugriffsbeschränkungen von API- oder Plattformanbietern rein monetär motiviert sind: Einige sind technisch notwendig, um zu verhindern, dass ein fehlkonfigurierter oder in einer Schleife gefangener Agent den Dienst überlastet. Wer die eigenen Agenten nicht begrenzt, riskiert also nicht nur die eigene Rechnung, sondern läuft Gefahr, von fremden Systemen fälschlicherweise als Angriffsmuster blockiert zu werden.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

KI-Agenten beanspruchen mehr Infrastruktur als menschliche Nutzer

Wer die Kosten kontrollieren will, muss zunächst sehen, wo sie entstehen. Der erste Schritt besteht darin, jeden Agenten als eigenständigen Produktions-Workload zu behandeln und eine einzelne Nutzeranweisung mit der vollständigen Kette der daraus entstehenden Operationen zu verknüpfen. Dazu zählen Modellaufrufe, Tool-Aufrufe, API-Anfragen, Datenbankabfragen, Wiederholungsversuche und parallele Zweige. Offene Standards wie OpenTelemetry liefern dafür inzwischen ein herstellerunabhängiges Format, das unabhängig vom eingesetzten Observability-Werkzeug ist.

Sechs Messgrößen sind besonders relevant:

  • 1. Anfrage-Amplifikation: Wie viele nachgelagerte Operationen erzeugt eine einzelne Anweisung?
  • 2. Nebenläufigkeit: Wie viele Operationen kann der Agent gleichzeitig auslösen?
  • 3. Retry-Verhalten: Welche Fehler führen zu einem weiteren Versuch und wie oft erfolgt dieser?
  • 4. Untersuchungstiefe: Wie viele rekursive Schritte erfolgen, bevor der Agent stoppt?
  • 5. Infrastrukturverbrauch: Welche Rechen-, Speicher-, Netzwerk- und API-Kapazität nutzt jede Aufgabe?
  • 6. Wertbeitrag: Hat die Aktivität ein brauchbares Ergebnis geliefert?

Ein Anstieg bei einer dieser Größen ist nicht automatisch ein Problem, denn ein komplexer Vorfall kann Hunderte Abfragen rechtfertigen. Entscheidend ist die Abweichung vom Normalfall: Agenten, die plötzlich deutlich mehr Anfragen stellen als üblich, dieselben Ressourcen wiederholt abfragen oder Kapazität verbrauchen, ohne das Ergebnis zu verbessern.

Budgets und Sicherheitsgrenzen für KI-Agenten festlegen

Die Leitplanken für Agenten sollten sowohl den Infrastrukturverbrauch als auch die Sicherheitsberechtigungen abdecken. Jeder Agent benötigt ein Anfragebudget, ein Nebenläufigkeitslimit sowie eine für seine Aufgabe angemessene maximale Untersuchungstiefe. Aufwändige Operationen sollten eine stärkere Freigabe erfordern. Wiederholte Abfragen mit nahezu identischen Parametern sollten eine Schleifenerkennung auslösen.

Auch Tool-Schnittstellen können Verschwendung reduzieren. Anstatt uneingeschränkten Zugriff auf einen Rohdatenspeicher zu gewähren, liefern strukturierte Operationen genau den Kontext, der für eine konkrete Entscheidung nötig ist. Retries benötigen besondere Aufmerksamkeit: Sie sollten „Backoff“ nutzen, „Rate-Limit“-Antworten respektieren und stoppen, wenn ein weiterer Versuch die Störung wahrscheinlich nicht behebt.

Und schließlich sollten Untersuchung und Handlung getrennt bleiben. Die Berechtigung, ein System zu prüfen, sollte nicht automatisch die Berechtigung einschließen, es zu verändern. Aktionen, die die Verfügbarkeit beeinflussen, benötigen eine eigene Autorisierung und, wo das Risiko es verlangt, eine menschliche Freigabe.

KI-Kosten nach dem Ergebnis statt nach der Aktivität optimieren

Mit der wachsenden Verbreitung agentenbasierter Systeme in der Softwareentwicklung, der Incident-Response und dem Tagesgeschäft entsteht mehr Maschine-zu-Maschine-Traffic, als sich über Inferenzpreise allein steuern lässt.

Entscheidend ist nicht der Token oder die Anfrage, sondern die abgeschlossene Aufgabe und der Wert, den sie schafft. Ein Agent, der ein teures Modell nutzt, aber in wenigen disziplinierten Schritten zu einer korrekten Antwort kommt, kann kostengünstiger sein als ein Agent, der ein preiswertes Modell nutzt und dabei Hunderte unnötiger Abfragen absetzt. Ohne Einblick in den gesamten Ablauf bleibt dieser Unterschied verborgen, so wie es bei Uber lange der Fall war, bis die Rechnung kam.

Ein KI-Agent ist kein weiterer Nutzer, sondern ein autonomer Workload, der aus einer Anweisung ein Infrastrukturereignis machen kann. Entsprechend sollte er überwacht und begrenzt werden.


* Der Autor Gabriel-James Safar ist CEO und Mitgründer von Tsuga, einem im Jahr 2024 in Paris gegründeten Observability-Anbieter mit Bring-your-own-Cloud-Ansatz. Zuvor gründete er Madumbo, eine KI-gestützte Plattform für Website-Tests, die von Datadog übernommen wurde. Anschließend leitete er dort das Produktmanagement für das Digital-Experience-Monitoring. Ihn beschäftigt vor allem eine Frage: Wie können Unternehmen ihre KI-Systeme so gestalten, dass sie leistungsfähig und zugleich nachvollziehbar bleiben?

Bildquelle: Tsuga

(ID:50996786)