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.
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.
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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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?