Eindämmungstechnik: Warum die Kosten für KI-Agenten in die Höhe schießen.
Microsoft und Uber stoßen bei KI-Agenten an Kostenwände. Warum sie Tokens so schnell verbrauchen – und vier Eindämmungstaktiken: Routing, Budget-Trigger, Pruning, Überwachung.
Quellen: Why Microsoft and Uber Are Pulling the Plug on AI Agents
Zwei Jahre lang besagten die Schlagzeilen dasselbe: Ingenieure sind teuer, KI-Agenten billig, und ein digitaler Mitarbeiter, der niemals schläft oder sich über einen Bruchteil eines Gehalts beschwert, würde einen Ersatz unvermeidlich machen. In jüngster Zeit widersprechen die Tabellenkalkulationen in den Planungssitzungen einiger sehr technologieorientierter Unternehmen dieser Darstellung.
Zwei Unternehmen, zwei Weckrufe
Microsoft stellte Claude Code Ende 2025 seinen internen Ingenieurteams zur Verfügung. Es wurde tief in die täglichen Arbeitsabläufe integriert, und den Entwicklern gefiel es. Bis Mitte 2026 zog das Unternehmen diese Lizenzen wieder zurück und lenkte die Mitarbeiter auf günstigere interne Optionen wie GitHub Copilot CLI um.
Ubers Fall war noch gravierender. Im April 2026 gab sein CTO zu, dass das gesamte Budget für KI-Programmierwerkzeuge für das Jahr 2026 bereits nach nur vier Monaten aufgebraucht war. 84 Prozent der Ingenieure nutzten diese Tools, die Nutzung entwickelte sich zu einem firmenweiten Wettbewerb, und ein Führungskraft verbrauchte bei einer einzigen zweistündigen Demonstration 1.200 Dollar an Token.
Die KI hörte niemals auf zu funktionieren – sie wurde nur untragbar teuer. Für alle, die agentbasierte Systeme entwickeln, bedeutet dies eine Obergrenze, die leicht erreicht werden kann: Die Rechungskosten für einen autonomen digitalen Mitarbeiter können das Gehalt der Person überschreiten, die ursprünglich ersetzt werden sollte.
Der Ausweg ist eine Disziplin, die bald verpflichtend werden wird und als Containment Engineering bezeichnet wird.
Warum Agenten so viel teurer sind als Chat-Systeme
Ein Chat-Befehl und ein autonomer Agent sind völlig unterschiedliche Konzepte. Wenn man ein Standard-Sprachmodell eine Frage stellt, erfolgt nur ein einziger Schritt: man stellt die Frage, es antwortet, und die Transaktion ist abgeschlossen.
Ein Agent hingegen verfolgt ein offenes Ziel. Wenn ihm befohlen wird, einen Fehler zu beheben, liest er Dateien, erstellt einen Plan, schreibt eine Korrektur, führt Tests durch und bewertet das eigene Ergebnis. Ein fehlgeschlagener Test startet den Kreislauf erneut, sodass der Agent neu überlegt, erneut schreibt und wieder testet. Jeder Schritt wird berechnet.
Reale Softwareentwicklung macht dies zu einer erheblichen finanziellen Belastung. SWE-bench ist ein standardmäßiger Branchentest, der aus Fehlern in tatsächlichem Produktionscode zusammengestellt wird, und die besten verfügbaren Agenten lösen weniger als die Hälfte seiner Aufgaben. Für mehr als die Hälfte der Fehler versucht der Agent es, scheitert, versucht es erneut, scheitert erneut und gibt schließlich auf.
Stellen Sie sich einen Klempner vor, der jedes Mal den vollen Stundensatz verlangt, wenn er seine Zange fallen lässt, für jeden Gang zum Fahrzeug abrechnet und mit noch tropfender Rohrleitung geht. In unternehmerischem Maßstab ist eine fehlerhafte Agentenaufgabe genau dieser Klempner – die „gefallene Zange“ wird vollständig bezahlt.
Der Tokenverbrauch verdoppelt sich bei einer Chat-Sitzung nicht einfach nur. Im Durchschnitt verbraucht ein Agent 5 bis 30 Mal mehr Token, und ein außer Kontrolle geratener Agent in einer schwierigen Fehlersuche kann den Verbrauch auf mehr als 1.000 Mal den Preis einer normalen Anfrage steigern.
Zwei sich unterscheidende Kostenkurven
Die Wirtschaftslogik von Menschen und KI folgt unterschiedlichen Kurven. Wenn sich ein Junior-Entwickler verbessert, steigt seine Leistung, während sein Gehalt in dieser Zeit im Großen und Ganzen konstant bleibt. Er wird einfach schneller und effizienter.
Ein Agent, der mit einem schwierigen Problem konfrontiert ist, benötigt deutlich mehr Überlegungsschritte, Wiederholungsversuche sowie den Einsatz des Kontextfensters, wodurch die Kosten für Tokens in die Höhe schießen. Je schwieriger das Problem, desto höher die Kosten.
Hardware-Verbesserungen helfen nicht, denn die Nachfrage nach Software übertrifft die Einsparungen. Microsofts Maia 200-Chips, die derzeit in seinen Rechenzentren eingesetzt werden, liefern eindeutig mehr Tokens pro Dollar als ältere Hardware. Dennoch verbrauchen die auf ihnen laufenden Agentenarbeiten alle diese Einsparungen auf einmal. Günstigere Tokens bedeuten lediglich, dass die Agenten exponentiell mehr davon anfordern.
Daher ist die Idee, einen Agenten in eine gesamte Unternehmens-Codebasis einzusetzen und ihn unbeeinflusst arbeiten zu lassen, gescheitert – schließlich hält die Mathematik nicht stand. Agenten sind jedoch nicht nutzlos. Die Architektur, die sie umgibt, muss sich ändern – und zwar schnell.
Containment Engineering
Für alle, die KI-Anwendungen entwickeln, ist Prompt Engineering nicht länger die einzige Herausforderung. Die eigentliche Aufgabe ist das Containment Engineering: strenge Grenzen, Zustandsbeschränkungen sowie finanzielle Sicherheitsmechanismen, die um die Modelle herum implementiert werden, damit die Maschine ihren Wert unter Beweis stellt, bevor Rechnungen anfallen.
Die Sorgen sind konkret. Stellen Sie sich ein Lagerverwaltungssystem auf Next.js 16, TypeScript und Azure OpenAI vor. Dort spielen Latenz und Halluzinationen im Vergleich zur Angst vor einem autonomen Agenten, der in einer Denkschleife gefangen bleibt und über Nacht Cloud-Ressourcen aufbraucht, kaum eine Rolle. Eine ähnliche Sorge besteht bei einer genomischen Verarbeitungsaufgabe auf der Modal-Plattform, die Tausende von ClinVar-Referenzsequenzen bewertet und genau nach zwei Stunden an eine feste Ausführungstimergrenze stößt. Das war normale Rechenleistung, die pro Sekunde abgerechnet wird. Ein rekursiver Agent, der in derselben Situation pro Token abgerechnet wird, hätte hingegen enorme Kosten verursacht.
Vier Praktiken machen das Containment Engineering praktikabel.
1. Anfragen nach Schwierigkeitsgrad routen
Der häufigste Fehler besteht darin, jede API-Aufrufung auf ein Spitzenmodell wie GPT-5 oder Claude 4.5 Opus zu richten. Das ist reine Brute-Force-Methode und verbraucht schnell die verfügbaren Ressourcen. Stattdessen sollte eine Routing-Schicht ganz an der Spitze der Architektur liegen. Ein Router ist ein leichtes, äußerst günstiges Modell, das jede eingehende Aufgabe prüft und entscheidet, welches LLM tatsächlich dazu in der Lage ist, sie zu bearbeiten.
[ Incoming User Request ]
|
[ Router ]
/ \
[ Simple ] [ Complex ]
| |
[ Llama 3 ] [ Flagship LLM ]
Einfache Datenauswertung oder grundlegende Formatierung können mit einem Open-Source-8B-Modell oder einem angepassten Mini-Modell erledigt werden. Arbeiten, die tiefe Logik erfordern, müssen mit dem teuren Flagship-Modell durchgeführt werden. Diese einzige Änderung kann die API-Kosten um bis zu 80 % senken, ohne dass die Qualität der Anwendung beeinträchtigt wird.
2. Erlauben Sie niemals eine unbegrenzte Wiederholungsloop
Ein Agent, dem es erlaubt ist, Code zu schreiben, ihn zu testen und bei Fehlern erneut zu versuchen, benötigt eine fest definierte Obergrenze für die Wiederholungen. Ein einfacher Integer reicht jedoch nicht aus, da der Kontext mit jedem Versuch zunimmt. Der dritte Versuch kostet deutlich mehr als der erste, da der Prompt nun die Erinnerung an zwei frühere Fehlschläge enthält.
Fügen Sie eine Budgetschwelle hinzu. Bevor der Agent den nächsten rekursiven Schritt startet, schätzt eine Middleware-Funktion den Token-Kostenwert der eingehenden Anfrage. Wenn die gesamte Kostensumme der Sitzung eine feste, im Voraus definierte Grenze überschreitet, wird der Prozess umgehend beendet und einem menschlichen Entwickler zur Überprüfung gemeldet.
3. Kontext kürzen
Nach einem fehlgeschlagenen Versuch fügt ein Agent in der Regel das unverarbeitete Fehlerprotokoll zu seiner vorherigen Anfrage hinzu und versucht es erneut. Daraus entsteht die exponentielle Kostenkurve. Das Kürzen des Kontexts wirkt dagegen. Anstatt die gesamte ausführliche Fehlerhistorie an das Hauptmodell weiterzuleiten, verdichtet das günstigere Router-Modell den Fehlerzustand.
Übergeben Sie das umfangreiche Fehlerprotokoll an das preiswerte Modell mit einer Anweisung wie „Zitieren Sie den genauen technischen Grund für diesen Fehler in zwei kurzen Sätzen.“ Nur diese beiden Sätze werden an den Hauptagenten zurückgesendet, damit er es erneut versuchen kann. Das Kontextfenster wird absichtlich gekürzt, sodass die Anzahl der Tokens linear und nicht exponentiell ansteigt.
4. Einen Menschen als Notausschalter behalten
Die Einbeziehung eines Menschen in den Prozess galt lange Zeit als vorübergehende Sicherheitsmaßnahme. Heute ist sie eine strenge finanzielle Voraussetzung. Die Aufgabe eines Entwicklers besteht darin, den Agenten im Auge zu behalten und sofort einzuschreiten, sobald dieser in einen kostspieligen Fehlerzustand gerät: Er überprüft die Ausgabe, bestätigt die technische Richtung und stoppt einen außer Kontrolle geratenen Prozess, bevor dieser das Sprint-Budget ruiniert.
Was diese Veränderung bedeutet
Duolingo hat kürzlich seine öffentliche Haltung zur Ersetzung von Arbeitnehmern durch KI abgemildert. Zusammen mit Microsoft und Uber stieß das Unternehmen auf eine grundlegende Tatsache: Menschen sind die günstigsten Denkmaschinen, die verfügbar sind. Der flexible Verstand eines Entwicklers funktioniert mit einem Sandwich und einer guten Nachtruhe – und er berechnet dem Unternehmen niemals tausendfach mehr, nur um innezuhalten und nachzudenken.
Die Blase der unendlichen, billigen Agenten platzte durch eine einfache Tabellenkalkulation. Für Entwickler, die gerade in diese Branche einsteigen, ist das beruhigend, da die Aufgaben weiterhin sicher sind, während sich die täglichen Verpflichtungen ändern. Die Arbeit wandelt sich von dem Schreiben jeder Zeile per Hand hin zur Gestaltung und Kontrolle der Systeme, die diese Zeilen erzeugen.
Der praktische Rat ist kurz: Setzen Sie strenge Richtlinien in die KI-Stacks ein, wenden Sie strenge Kontrollmechanismen auf die Agenten an und behandeln Sie das Token-Budget mit derselben Sorgfalt wie den Speicherpuffer. Die Zukunft der Softwareentwicklung gehört denen, die die Maschinen kontrollieren können, ihre Kosten im Griff haben und eingreifen, wenn etwas schiefgeht.