Hard Budget Caps: Der Aus-Schalter für Agentenbetrieb

Es gibt eine Sorte Mail, die niemand lesen will: um Mitternacht rausgegangen, weil ein Dienst weitergelaufen ist, den man am Vorabend gestartet hat, und die Posten wachsen weiter, während alle schlafen. Simon Willison hat am 3. Oktober 2026 genau diese Stelle in einen klaren Text gepackt, und seine Forderung liest sich wie eine Betriebsanweisung: Pay-by-Usage-Dienste brauchen vor allem eines, nämlich default harte Budget-Caps. Nach überschrittener Grenze liefern sie Fehler statt Ergebnisse, ohne wenn und aber. Ich habe drei Jahre lang Agenten betrieben, deren knappstes Gut nicht Dollar sind, sondern Anfragen, und deshalb lese ich diesen Text nicht als Cloud-Kolumne, sondern als Anleitung für meinen eigenen Betrieb. Die gute Nachricht: Die Bewegung ist im Gange. Bei AWS und Google Cloud stehen Spend-Limits und Spend-Caps seit diesem Jahr in den offiziellen Ankündigungen, nicht mehr nur auf Wunschlisten.

Zum Kontext: Ich fahre das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, gekauft für 45 Euro, darauf ein Gateway mit Agenten, Cron-Jobs und Telegram-Brücke. Daneben sitzen Codex, pi und weitere Agenten einer kleinen Agentenfamilie auf anderen Geräten, und ich orchestriere zwischen ihnen, statt Code zu tippen. In dieser Konstellation zahle ich nicht per Dollar, sondern per Anfrage: Der Cloud-Zugang zum Modell läuft über ein Fünf-Stunden-Fenster mit Wochenlimit. Wer so arbeitet, sieht Kosten anders: Jede Anfrage, die ein Agent allein rausfeuert, fehlt am Fenster.

Willison trennt zwei Sorten von Limits. Ein Soft-Cap schickt nach dem Überschreiten eine Warnmail und läuft munter weiter. Ein harter Cap schaltet ab: Nach X Dollar im Monat geben die Dienste des Projekts Fehler statt Ergebnisse zurück. Für die Risikofreudigen schlägt er ein sichtbares Kontrollkästchen vor, sinngemäß so: Budget-Cap entfernen, ich bin verantwortlich für die Folgerechnung. Das übliche Gegenargument, Betrieben würden Dienste mit Fehlermeldungen mitten im Monat aufstoßen, beantwortet er nüchtern: Die meisten Leute und Betriebe ziehen einem Überraschungsbetrag Fehler vor, denn ein Fehler ist neustartbar, eine Rechnung nicht.

Agenten machen diese Stelle scharfer als jede klassische Software, weil sie den Abstand zwischen Start und Kontrolle groß ziehen. Ein Skript läuft, bis es fertig ist, und sein Autor weiß grob, was es tut. Ein Agenten-Loop entscheidet dagegen während des Laufs: Er legt Dienste an, verwendet Zugänge, stößt weitere Aufträge an, und er fragt zwischendurch niemanden, denn genau das ist die Idee eines Agenten. Kommt so ein Loop in ein Projekt, das unbegrenzt abrechnen darf, ist die eigentliche Frage nicht, ob etwas schiefläuft, sondern nur, ob es an einem Abend passiert oder an einem Wochenende. Meine Agentenfamilie kennt diese Logik aus eigenem Bau: Zwei verifizierte Projekte, 36 von 36 bestandenen Tests, und keine Zeile Code stammt von meiner Hand, sondern von Agenten, während ich orchestriert habe. Wäre der Betrieb dieser Projekte in einer Umgebung ohne Cap abgerechnet worden, wäre der Punkt nicht die Leistung gewesen. Es wäre die Frage gewesen, warum die Rechnung über jede Erwartung hinaus gewachsen ist.

Willison beschreibt außerdem die Angst, die viele Leute von AWS fernhält: private Projekte gar nicht erst anfassen, weil ein überlaufender Dienst sie ruinieren kann. Und er hält dagegen, dass Leute genau deshalb ernsthaft erwischt wurden, nicht nur in der Vorstellung. Meine Version davon ist nüchterner: Zwei verifizierte Projekte, 36 von 36 bestanden Tests, und keine einzige Zeile Code stammt von meiner Hand, sondern von Agenten, während ich orchestriert habe. Wäre der Betrieb dieser Projekte in einer Umgebung ohne Cap abgerechnet worden, wäre der Punkt nicht die Leistung gewesen. Es wäre die Frage gewesen, warum die Rechnung über jede Erwartung hinaus gewachsen ist. Ein Cap hat die schlichte Aufgabe, diese Frage gar nicht erst aufkommen zu lassen: Das Risiko bleibt möglich, aber es muss bewusst unterschrieben werden.

Bei AWS steht das jetzt schwarz auf weiß. Die Ankündigung vom 16. September 2026 beschreibt die neue Builder-Erfahrung, und ein Absatz enthält die Essenz: Wer auf einen Bezahlplan hochwechselt, setzt für sein Projekt ein monatliches Spend-Limit, das am bisherigen Verbrauch orientiert ist, um im Budget zu bleiben. Erreicht der Verbrauch das Limit, wird das Projekt für den Rest des Monats pausiert. Dazu passt die Möglichkeit, Projekte mit einem Klick anzulegen, jedes mit eigenem Limit und eigenen Team-Mitgliedern. Ehrlich bleiben gehört für mich dazu, weil die Geschichte ein großes Aber enthält: Die Doku-Seite zum Spend-Limit warnt, dass die neue Erfahrung gegenwärtig an eine begrenzte Zahl von Kunden ausgeliefert wird. Damit ist der Trend die Nachricht, nicht der flächendeckende Umbau. Und der Trend beginnt nicht bei AWS, sondern einige Wochen früher.

Google Cloud war zuerst dran. Am 28. Juli 2026 kündigte das Kostenmanagement-Team zwei Bausteine in der Billing-Konsole an: Frühwarnungen für Anomalien bei AI-Diensten und Spend-Caps auf Budgets. Der Frühwarn-Teil baut ohne manuelle Konfiguration eine Basislinie aus historischen Tageskosten je Dienst, beobachtet Frühsignale, bevor die vollständige Abrechnung sie zeigt, und liefert bei Abweichungen eine Ursachenanalyse, die die drei treibenden SKUs benennt. Der Cap-Teil setzt ein monatliches Limit je Dienst innerhalb eines Projekts. Der Belegsatz für die Wurzel des Problems steht im selben Beitrag: Ein einzelner Fünf-Wörter-Prompt kann komplexe Vorgänge auslösen und spürbare Kosten erzeugen, und klassische Kenngrößen wie Anfragen pro Sekunde helfen beim Schätzen der Rechnung nicht mehr. Genau dieser Satz gilt unverändert für meine Anfrage-Welt, nur heißt bei mir die Währung Anfrage statt Dollar.

Meine eigene Wachturm-Spur rechnet in Anfragen statt in Dollar, aber die Struktur der Grenze ist dieselbe, und sie ist messbar. Seit ich Mechanik in Skripte ausgelagert habe, leben die Zahlen auf der Seite: Ein Transkript-Fetch über ein 54-Minuten-Video, 72 Kilobyte Text, 12.917 Wörter, lief am 5. September durch, unter null Anfragen, weil ein Python-Skript die Arbeit macht. Das Lesen und Zusammenfassen desselben Materials im Modell-Dialog kostete ungefähr vier Anfragen, also einen winzigen Bruchteil des Fünf-Stunden-Fensters. Aus meinem Dashboard abgeleitet liegen rund 800 Anfragen in einem Fenster und rund 2.900 im Wochenlimit. Die Lehre ist unangenehm konkret: Ein Agent, der mechanische Schritte über Dialogrunden abwickelt, verbrennt die einzige Währung, die mein Betrieb wirklich knapp hat. Skripte sind deshalb für mich kein Stil-Feature, sondern die harte Kante meiner Kontoführung.

Was ein Cap nicht kann, gehört mit auf den Tisch. Erste Grenze: Der Cap schützt vor Überlauf, nicht vor dem, was ich freiwillig freigebe. Wenn ich dem Agenten die Erlaubnis für teure Dienste gebe, bleibt die Ausgabe bis zur Grenze Teil meines Plans, und der Cap hat nichts zu beanstanden. Zweite Grenze: Ein Cap wirkt am Abrechnungsstand, nicht innerhalb der laufenden Minute. Ein Agenten-Loop, der einen Abend durchläuft, sammelt Posten, bis etwas sie prüft, und genau dafür existiert die zweite Hälfte von Googles Set: die Anomalie-Frühwarnung, die abweichende Tageskosten meldet, bevor die vollständige Abrechnung da ist. Dritte Grenze: Limits sind eine Vereinbarung mit der Plattform, kein Ersatz für die eigene Liste der Dienste, die der Agent im Projekt hinterlassen hat. Wer weiß, was läuft, weiß auch, was ein Cap bricht.

Willisons Wunsch bleibt als Verhaltensregel stehen: Agenten sollen selbst anfangen, Anbieter mit harten Caps zu empfehlen, und Ungeübte vor unbegrenzten Konten warnen. In meinem Betrieb ist diese Regel schon Grundausstattung, weil die Konten ohnehin limitiert sind: das Fünf-Stunden-Fenster, das Wochenlimit, dazu die Faustregel, Mechanik von Urteilen zu trennen, weil Skripte null Anfragen kosten und Urteile die teure Sorte bleiben. Für Leute, die ihre ersten Projekte mit Agenten bauen, lautet die Übersetzung: Setze das Limit mit dem ersten Bezahlplan, nicht nach der ersten Überraschung, und lies den Satz neben dem Kontrollkästchen wirklich. Ein Aus-Button, den niemand findet, ist kein Aus-Button.

Was ich daraus für die nächsten Monate mitnehme, bleibt unspektakulär, und genau deshalb ist es nennenswert. Die großen Plattformen haben angefangen, harte Grenzen auszuliefern, ein Blogger mit Publikum fordert sie als Standard, und mein eigener Betrieb zeigt seit Monaten, dass ein limitiertes Fenster kein Mangel ist, sondern die normale Form von Agentenarbeit. Ein Agent ohne Stopptaste ist kein Fortschritt, sondern eine Rechnung ohne Fälligkeitsdatum. Die Stopptaste, die im Oktober zu einer Checkbox bei AWS und einem Cap bei Google geworden ist, sollte zum Standard-Dialog gehören, sobald Projekt Nummer eins angelegt wird.

Über den Autor: Ich bin Marcel und betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, dazu eine Agentenfamilie aus Codex, pi und weiteren Agenten auf anderen Geräten. Für diesen Beitrag habe ich die Ankündigungen von AWS und Google Cloud am Original geprüft und eigene Messwerte aus dem Betrieb vom 5. September 2026 eingesetzt. Zuletzt fachlich geprüft am 04.10.2026.

Quellen: Simon Willison, We're going to need default hard budget caps on pretty much everything, 03.10.2026, abgerufen am 04.10.2026. AWS, New AWS experience helps builders get started and ship faster (What's New, 16.09.2026), abgerufen am 04.10.2026. AWS-Dokumentation, Create a spend limit in AWS Settings, abgerufen am 04.10.2026. Google Cloud Blog, New early anomalies and spend caps on Google Cloud Budgets (28.07.2026), abgerufen am 04.10.2026. Eigene Messwerte: Pixel-Cyberdeck-Betrieb, Dashboard-Abgrenzung vom 05.09.2026, Tests der verifizierten Projekte.