Kostenbremse für KI-Agenten: 3 Limits, die Sie vor dem Start setzen

Ein Agent, der nachts um drei Uhr eine Aufgabe erledigt, ist ein Gewinn. Ein Agent, der nachts um drei Uhr in einer Schleife hängt und bei jedem Durchlauf ein Sprachmodell aufruft, ist eine Rechnung, die Sie erst am Monatsende sehen. Genau dieses Risiko wird in der Praxis häufig unterschätzt, weil Kosten bei KI-Agenten nicht wie eine Lizenzgebühr funktionieren. Sie entstehen pro Aufruf, pro Token, pro Werkzeugeinsatz. Und sie wachsen, wenn etwas schiefläuft, schneller als jeder Mensch zuschauen kann.

Dieser Beitrag zeigt Ihnen, welche drei Limits Sie festlegen sollten, bevor ein Agent in den Echtbetrieb geht. Er stützt sich auf aktuelle Ankündigungen von AWS und Google Cloud, auf eine prominente Forderung von Simon Willison und auf Praxisberichte zur Kostenkontrolle von Agenten. Wo die Quellenlage dünn oder nicht unabhängig geprüft ist, sagen wir das ausdrücklich dazu.

Warum Agenten teuer werden können, ohne dass es jemand merkt

Ein klassisches Softwareprodukt kostet einen festen Betrag pro Monat. Ein KI-Agent dagegen nutzt in der Regel Pay-per-use-Dienste: Sie zahlen für das, was tatsächlich verbraucht wird. Das ist fair und flexibel, hat aber eine Eigenschaft, die man bei Menschen nicht kennt. Ein Agent arbeitet ohne Pause, ohne Zweifel und ohne das Bauchgefühl, dass „da etwas nicht stimmen kann“. Wenn er in eine Fehlerlage gerät, wiederholt er seine Schritte so lange, bis ihn etwas stoppt.

In den fachlichen Quellen zur Kostenkontrolle tauchen immer wieder dieselben Ursachen auf:

• Nicht endende Schleifen: Der Agent prüft ein Ergebnis, ist unzufrieden, versucht es erneut und kommt nie zu einem Abschluss.
• Wiederholte teure Tool-Aufrufe: Ein Werkzeug, das selbst Kosten verursacht, wird immer wieder mit fast identischen Anfragen angesprochen.
• Prompt-Injection: Ein manipulierter Text in einer E-Mail oder auf einer Webseite sorgt dafür, dass sich eine einzelne Anfrage vervielfacht.

Dazu kommt ein weiterer Faktor, den Simon Willison am 3. Oktober 2026 deutlich benannt hat: Coding-Agenten machen es leichter, versehentlich teure API-Aufrufe auszulösen. Wer einen Agenten Code schreiben und ausführen lässt, hat oft keinen vollständigen Überblick darüber, welche Dienste dabei im Hintergrund angesprochen werden. Willison nennt als Schreckensszenario Rechnungen von „10.000 USD+“. Das ist kein Normalfall, aber es zeigt die Größenordnung, über die in der Branche gesprochen wird.

Pay-per-use-Dienste sollten laut Simon Willison per Default harte Budgetgrenzen haben, die den Dienst tatsächlich stoppen, nicht nur Warn-Mails verschicken. Höhere Limits sollten nur durch bewusstes Opt-in möglich sein.

Diese Forderung ist sinngemäß wiedergegeben. Sie ist für Inhaber und Geschäftsführer im Mittelstand besonders relevant, weil Sie in der Regel keine eigene FinOps-Abteilung haben, die täglich auf Verbrauchsdiagramme schaut. Sie brauchen Mechanismen, die auch dann greifen, wenn niemand hinsieht.

Warnung ist nicht Schutz: Der Unterschied zwischen Alert und Enforcement

Bevor es um die drei Limits geht, lohnt sich eine Unterscheidung, die in der Praxis oft verwischt wird. Ein Budget-Alert ist eine Benachrichtigung: Ihr Verbrauch hat eine bestimmte Schwelle erreicht. Ein Enforcement dagegen ist ein Eingriff: Der Dienst wird gestoppt oder pausiert. Beides hat seinen Platz, aber nur das zweite schützt Sie tatsächlich vor einer Überraschungsrechnung.

Der Grund ist einfach. Ein Alert informiert Sie, nachdem das Geld ausgegeben wurde. Wenn die Mail an einem Freitagabend eintrifft und Sie sie erst am Montag lesen, hat der Agent das gesamte Wochenende weitergearbeitet. Fachbeiträge zur Kostenkontrolle von Agenten kommen deshalb übereinstimmend zu dem Schluss: Alerts sind nützlich zur Beobachtung, aber kein Ersatz für eine harte Grenze, die den Agenten anhält.

Als wirksamste Kontrolle wird in den Quellen ein hartes Budget beschrieben, das vor jedem Modellaufruf geprüft wird. Die Logik dahinter lässt sich in einem Satz sagen: Wenn die bisher aufgelaufene Summe plus die erwarteten Tokens des nächsten Aufrufs das Limit überschreiten würde, wird der Aufruf nicht gesendet, sondern abgebrochen. Das ist keine komplizierte Technik, aber sie muss bewusst eingebaut werden. Von allein tun das die wenigsten Agenten-Setups.

Limit 1: Das harte Monatsbudget mit Abschaltung

Das erste Limit ist die äußere Mauer. Es legt fest, wie viel Geld ein Projekt oder ein Dienst in einem Monat höchstens verbrauchen darf, und es stoppt die Nutzung, wenn die Grenze erreicht ist. Zwei große Cloud-Anbieter haben in den vergangenen Monaten Funktionen angekündigt, die genau diesem Muster folgen.

Das Muster bei AWS

AWS hat am 16. September 2026 im Rahmen der „New AWS Builder Experience“ angekündigt, dass sich nach dem Upgrade auf einen Bezahlplan ein monatliches Ausgabenlimit je Projekt setzen lässt. Wird das Limit erreicht, pausiert das Projekt für den Monat. Laut einer Drittquelle (factualminds.com) gibt es Warnungen bei 50, 75 und 90 Prozent, und das Mindestlimit liegt beim Höheren aus 20 US-Dollar oder der AWS-Schätzung. Dieselbe Quelle nennt für den Stand vom 23. September 2026 einen noch limitierten Rollout.

Zwei Hinweise sind wichtig. Erstens: Diese Details stammen aus der Drittquelle und sind nicht aus der AWS-Primärseite bestätigt. Prüfen Sie die aktuellen Bedingungen bei AWS selbst. Zweitens: Das Feature ist laut den Quellen für Experimente und Sandbox-Umgebungen gedacht, nicht als Account-Deckel für Produktion. Außerdem gilt: Wer die Pause 90 Tage lang ignoriert, dem werden die Projektdaten gelöscht. Eine Pause ist also kein Dauerzustand, sondern ein Signal, das Sie aktiv bearbeiten müssen.

Das Muster bei Google Cloud

Google Cloud hat am 28. Juli 2026 die „Spend Caps“ als Public Preview vorgestellt. Sie erlauben ein monatliches Limit je Dienst und Projekt. Wird es erreicht, stoppt die kostenpflichtige Nutzung innerhalb von Minuten, die Daten bleiben erhalten, und die Freigabe erfolgt per Klick. Alerts gibt es bei 50, 80 und 100 Prozent. Unterstützt werden unter anderem die Gemini API, die Agent Platform und Cloud Run.

Auch hier gibt es Einschränkungen: Ein Cap gilt für ein Projekt und einen Dienst, und feste Commitments wie CUD oder Provisioned Throughput laufen weiter. Da es sich um eine Public Preview handelt, kann sich das Feature noch ändern.

Was Sie daraus für sich ableiten

Entscheidend ist weniger, welchen Anbieter Sie nutzen, sondern die Frage, die Sie jedem Anbieter stellen sollten: Gibt es bei diesem Dienst einen echten Hard Cap, der die Nutzung stoppt, oder nur Warnungen? Wenn nur Warnungen existieren, müssen Sie die Grenze selbst bauen, etwa über ein Budget, das Ihr Agent vor jedem Aufruf prüft. Für die Anbieter, bei denen wir keine Recherche zu den Limits durchgeführt haben, etwa die direkten APIs der großen Modellhersteller, machen wir hier bewusst keine Aussage. Prüfen Sie diese Konditionen bitte selbst, bevor Sie sich auf sie verlassen.

Ein Hard Cap pausiert Dienste. Für Inhaber ist das meist akzeptabler als eine Überraschungsrechnung, aber es bedeutet auch: Sie brauchen einen Plan für den Fall, dass der Agent ausfällt. Wer nimmt die Aufgabe in dieser Zeit manuell wieder auf? Welcher Prozess läuft als Fallback? Diese Frage sollten Sie vor dem Go-live beantworten, nicht erst dann, wenn die Pause eintritt.

Limit 2: Ein Budget pro Agent und Aufgabe, plus Schleifenabbruch

Das Monatsbudget schützt Sie vor dem großen Unfall. Es schützt Sie aber nicht davor, dass ein einzelner fehlerhafter Lauf einen großen Teil dieses Budgets aufbraucht, bevor Sie es merken. Dafür brauchen Sie ein zweites Limit, das näher am einzelnen Prozess sitzt.

Dieses Limit hat zwei Bestandteile:

• Ein Token-Budget pro Lauf: Jede Aufgabe bekommt eine feste Obergrenze an Tokens beziehungsweise Kosten. Ist sie erreicht, bricht der Lauf ab und meldet das Problem.
• Eine maximale Schrittzahl: Der Agent darf nur eine bestimmte Anzahl von Schritten ausführen, bevor er anhalten muss. Das ist die einfachste und wirksamste Gegenmaßnahme gegen Endlosschleifen.

Warum ist das so wichtig? Weil Schleifen selten laut sind. Ein Agent, der in einer Schleife hängt, produziert keine Fehlermeldung, sondern scheinbar sinnvolle Arbeit. Er ruft ein Werkzeug auf, wertet das Ergebnis aus und ruft es erneut auf. Ohne harte Obergrenze pro Lauf gibt es keinen Punkt, an dem das System von selbst sagt: „Das reicht jetzt.“

Ein Fallbeispiel mit Vorbehalt

In einem Blogbeitrag auf dev.to wird ein Fall beschrieben, in dem vier Agenten im November 2025 elf Tage lang in einer Endlosschleife liefen und dabei 47.000 US-Dollar verursachten; zwei davon, ein Analyzer und ein Verifier, hätten sich gegenseitig Anfragen geschickt. Wir erwähnen das ausdrücklich nur mit Vorbehalt: Die Quelle ist der Blog eines Anbieters mit eigenem Interesse an dem Thema, und der Fall ist nicht unabhängig verifiziert. Als Illustration eines Mechanismus taugt die Geschichte trotzdem, nämlich dass sich zwei Agenten gegenseitig beschäftigen können, ohne dass jemand eingreift. Als belegte Tatsache sollten Sie sie nicht behandeln.

Die Lehre ist unabhängig vom Wahrheitsgehalt des Einzelfalls: Wenn mehrere Agenten miteinander kommunizieren, braucht jeder Lauf ein Limit, und es braucht eine Grenze für die Zahl der Runden zwischen ihnen. Ein Alert allein hätte in einem solchen Szenario nur dokumentiert, wie teuer es wird.

Budget-Alerts informieren Sie nach dem Geld-Ausgeben. Erst ein Enforcement, das den Agenten stoppt, verhindert die Rechnung.

So legen Sie das Pro-Lauf-Limit fest

Gehen Sie von der Aufgabe aus, nicht vom Modell. Fragen Sie sich: Wie viele Schritte braucht ein normaler, erfolgreicher Lauf? Setzen Sie die Obergrenze so, dass sie diesen Normalfall mit Reserve abdeckt, aber einen entgleisten Lauf deutlich vor dem Monatsbudget abfängt. Dokumentieren Sie, was beim Erreichen des Limits passiert: Der Lauf endet, der Vorgang landet in einer Warteschlange, und eine benannte Person erhält eine Meldung.

Limit 3: Menschliche Freigabe ab einer Schwelle

Die ersten beiden Limits sind automatische Bremsen. Das dritte ist eine bewusste Entscheidung durch einen Menschen. Es greift bei Aktionen, die einzeln oder in Summe teuer werden können. Die Idee ist einfach: Unterhalb einer von Ihnen festgelegten Betragsschwelle arbeitet der Agent selbstständig. Oberhalb dieser Schwelle hält er an und wartet auf eine Freigabe.

Das passt zu dem, was Willison für Pay-per-use-Dienste insgesamt fordert: Höhere Limits sollen kein Zufallsprodukt sein, sondern ein bewusstes Opt-in. Übertragen auf Ihren Betrieb heißt das: Niemand sollte ein Limit stillschweigend anheben können, weder der Agent noch ein Entwickler, der es „nur kurz“ für einen Test tut.

Typische Kandidaten für eine Freigabepflicht sind:

• Läufe, die ein definiertes Kostenbudget überschreiten würden,
• Aktionen mit teuren Werkzeugen oder externen kostenpflichtigen Diensten,
• jede Anhebung eines bestehenden Limits,
• die Wiederaufnahme nach einer automatischen Pause.

Wichtig ist, dass die Freigabe praktikabel bleibt. Wenn jede Kleinigkeit bestätigt werden muss, wird die Freigabe zum Reflex und verliert ihren Wert. Wählen Sie die Schwelle deshalb so, dass sie nur bei wirklich relevanten Beträgen oder Abweichungen anschlägt.

Verantwortlichkeiten klar benennen

Ein Limit ohne Verantwortlichen ist ein Limit, das niemand beachtet. Legen Sie vor dem Start schriftlich fest:

• Wer erhält die Alerts, und wer vertritt diese Person im Urlaub?
• Wer gibt Läufe oberhalb der Schwelle frei?
• Wer darf ein Limit wieder anheben, und mit welcher Begründung?

Gerade im Mittelstand, wo Zuständigkeiten oft informell geregelt sind, ist dieser Punkt der unscheinbarste und zugleich der wichtigste. Die beste technische Bremse nützt wenig, wenn die Pause-Meldung in einem Postfach landet, das niemand liest.

Rechenbeispiel: Vom Prozess zum Monatsbudget

Wie kommen Sie zu sinnvollen Zahlen? Die Quellen liefern dafür eine einfache Grundformel: Kosten pro Prozess entsprechen den Tokens pro Lauf, multipliziert mit dem Preis pro Token und mit der Zahl der Läufe pro Monat. Dazu kommt ein Sicherheitsfaktor. Aus dem Ergebnis leiten Sie das Monatsbudget und das Pro-Lauf-Limit ab.

Ein Hinweis vorweg: Wir haben keine aktuellen Tokenpreise recherchiert. Die folgenden Werte sind deshalb reine Beispielwerte zur Veranschaulichung der Rechnung. Setzen Sie für Ihre Planung die aktuellen Preise Ihres Anbieters ein und gleichen Sie diese vor der Entscheidung direkt bei ihm ab.

Angenommen, ein Agent bearbeitet eingehende Anfragen. Beispielhaft nehmen wir an, ein Lauf verbraucht 20.000 Tokens, der Preis liege bei 1 Euro pro eine Million Tokens, und es gibt 1.000 Läufe im Monat. Dann ergibt sich: 20.000 Tokens je Lauf mal 1.000 Läufe sind 20 Millionen Tokens, bei 1 Euro je Million also 20 Euro im Monat. Mit einem Sicherheitsfaktor von 3 setzen Sie das Monatsbudget bei 60 Euro an. Das Pro-Lauf-Limit könnte bei einem Mehrfachen der erwarteten 20.000 Tokens liegen, damit ein normaler Lauf nie abgebrochen wird, ein entgleister aber früh.

Der eigentliche Wert dieser Übung liegt nicht in der Genauigkeit der Zahl, sondern darin, dass Sie überhaupt eine Erwartung formulieren. Wer weiß, was ein Prozess kosten sollte, erkennt eine Abweichung. Wer nie gerechnet hat, hat keinen Maßstab, an dem sich eine Überraschung messen lässt.

Prüfen Sie nach den ersten Wochen im Betrieb, wie weit Ihre Erwartung vom tatsächlichen Verbrauch entfernt war, und passen Sie Budget und Limits bewusst an. Dieser Schritt ist selbst eine Freigabeentscheidung im Sinne von Limit 3: Ein Mensch hebt oder senkt die Grenze, nicht der Agent.

Checkliste vor dem Go-live

Bevor Sie einen Agenten in den Echtbetrieb nehmen, sollten Sie diese Punkte mit Ja beantworten können:

• Gibt es bei jedem genutzten Cloud- oder API-Dienst ein hartes Monatsbudget, das die Nutzung stoppt, oder haben wir uns bewusst für eine eigene Prüfung vor jedem Modellaufruf entschieden?
• Hat jeder Agent beziehungsweise jede Aufgabe ein Token- oder Kostenbudget pro Lauf und eine maximale Schrittzahl?
• Gibt es eine Betragsschwelle, ab der ein Mensch freigeben muss?
• Sind Alert-Empfänger, Freigeber und die Person, die Limits anheben darf, namentlich benannt?
• Gibt es einen Prozess-Fallback, falls der Dienst durch einen Hard Cap pausiert wird?
• Haben wir eine Kostenerwartung pro Prozess berechnet, mit aktuellen Preisen des Anbieters?
• Wissen wir, was bei einer Pause mit den Daten passiert und bis wann wir handeln müssen?

Diese Liste ist bewusst kurz. Sie ersetzt keine vollständige Governance, aber sie verhindert die häufigsten und teuersten Fehler. Wer sie abgearbeitet hat, hat aus einem offenen Kostenrisiko ein begrenztes, kalkulierbares gemacht.

Fazit: Erst die Bremse, dann das Gaspedal

KI-Agenten sind für Betriebe ein enormer Hebel, aber ihr Kostenmodell verlangt eine andere Sorgfalt als klassische Software. Die aktuellen Entwicklungen zeigen, dass die großen Anbieter das Problem erkannt haben: AWS führt Ausgabenlimits je Projekt ein, Google Cloud bietet Spend Caps in der Public Preview, und Simon Willison fordert harte Budgetgrenzen als Standard. Diese Funktionen sind jedoch teils noch im Rollout, teils eingeschränkt und nicht überall verfügbar. Verlassen Sie sich deshalb nicht darauf, dass Ihr Anbieter die Bremse schon eingebaut hat.

Setzen Sie vor dem Start drei Limits: ein hartes Monatsbudget mit Abschaltung, ein Budget pro Lauf mit Schleifenabbruch und eine menschliche Freigabe ab einer Schwelle. Benennen Sie dazu die Verantwortlichen und planen Sie den Fallback für den Fall einer Pause. So bleibt ein Fehler ein Ärgernis und wird nicht zum Schaden.