Wie deckelt man, was ein KI-Agent kostet?

Ein Agent, der nachts allein arbeitet, kostet Geld, solange er läuft. Im Februar 2026 stand der Fall auf Hacker News: Jemand ließ vor dem Schlafengehen einen Agenten laufen. Der geriet in eine Schleife, und am Morgen waren 200 Dollar verbraucht.

Acht Wochen später fragte dort jemand anders nach einem Werkzeug, das Modellaufrufe zur Laufzeit anhält. Die meisten der gefundenen Werkzeuge zeigten die Kosten an, nachdem sie entstanden waren.

Wer mehrere Agenten betreibt, braucht eine Zahl, gegen die die Plattform selbst prüft. Dazu eine Folge, die eintritt, ohne dass jemand zusieht.

In covey heißt diese Zahl budget_usd. Sie steht in der Registry neben Modell und Turn-Limit, und ein Mensch mit der passenden Rolle setzt sie über POST /api/v1/agents/{id}/budget. Die Dokumentation führt sie neben max_turns und den Guard-Rails als eine der Grenzen, die außerhalb des Modells liegen und sich nicht wegargumentieren lassen.

Die Zahl entsteht am Ende eines Laufs

Der Daemon in der Sandbox schickt nach jedem Lauf eine cost-Nachricht an die Control Plane. Darin stehen der Betrag in Dollar, die Tokenzahlen und der Modellname. Er schickt sie nur, wenn überhaupt etwas gemessen wurde, also Kosten oder Tokens über null liegen. Die Control Plane bucht den Eintrag und prüft im selben Schritt den Deckel.

Die Eingabeseite zählt covey in drei Teilen: frische Eingabe, Lesen aus dem Prompt-Cache und Schreiben des Caches. Bei einer Laufzeit, die ihren Kontext zwischenspeichert, ist der ungecachte Teil der kleinste der drei. Ein in der Spezifikation vermessener Agent kam auf 5.497 Eingabe-Tokens gegen 1.842.222 Ausgabe-Tokens, während ein einziger seiner Läufe 2,34 Millionen Tokens aus dem Cache las.

Die drei kosten verschieden viel, ein Cache-Treffer etwa ein Zehntel frischer Eingabe. Deshalb liegen sie getrennt und werden erst für die Anzeige addiert.

Was dabei herauskommt, ist ein Listenpreis-Äquivalent, und die Spezifikation nennt es auch so. Auf einem abgerechneten API-Schlüssel ist es der Betrag, der tatsächlich berechnet wurde. Auf einem Abo-Platz ist es der Betrag, den dieselbe Arbeit über die API gekostet hätte, während der Platz ohnehin bezahlt ist.

Die Zahl übertreibt dort, und sie übertreibt in die harmlose Richtung: Agenten sehen teurer aus, als sie sind. Verbindlich bleibt die Abrechnung des Anbieters.

Zwei Stellen setzen den Deckel, die kleinere gewinnt

Den Betrag gibt es an zwei Stellen. Die eine ist das Feld am Agenten, die andere eine Guard-Rail vom Typ budget_limit, die ihren Wert unter params.usd führt und für einen einzelnen Agenten oder für alle gelten kann. Beim Prüfen nimmt die Control Plane den kleineren der beiden Werte. Steht am Agenten nichts, gilt die Guard-Rail allein. Unter mehreren Guard-Rails gewinnt ebenfalls die kleinste.

Gemessen wird gegen die kumulierten Kosten des Agenten. Die Abfrage summiert alle seine Kosteneinträge ohne Zeitfenster, der Deckel ist damit eine Lebenszeit-Obergrenze. Einen Betrag je Lauf oder je Zeitraum gibt es in covey heute nicht.

Wer vorher wissen will, bei welchem Betrag ein Agent angehalten wird, muss beide Stellen ansehen. Der Regeltester wertet die Regeln trocken aus, ohne etwas auszuführen, und nennt die Entscheidung, die auslösende Regel und den kleinsten Deckel aus den Guard-Rails. Das Feld am Agenten geht in diese Antwort nicht ein; angezeigt wird es auf der Seite des Agenten. Fragt man den Tester für einen Agenten, an dem 50 USD stehen, während eine Guard-Rail 200 USD vorgibt, nennt er 200 USD, und die Control Plane pausiert den Agenten trotzdem bei 50 USD.

Beim Erreichen wird pausiert und die Aufgabe kehrt zurück

Ist die Grenze erreicht, schreibt die Control Plane ein Guard-Rail-Ereignis mit der Regel, dem Deckel, dem verbrauchten Betrag und der Folge. Danach legt sie den Kill-Schalter des Agenten um, schickt dem Daemon eine Kill-Nachricht und öffnet die laufende Aufgabe wieder, mit dem Budget als Grund.

Die Aufgabe steht danach offen im Backlog. Der Quelltext unterscheidet diesen Ausgang ausdrücklich von einem Fehlschlag: Ein Budget-Stopp ist keine gescheiterte Erledigung, sondern eine Aufgabe, die auf einen Menschen wartet.

Parallel geht eine Benachrichtigung der Klasse cost hinaus. Im Titel stehen der Name des Agenten, der verbrauchte und der erlaubte Betrag; verlinkt ist /costs.

Zurück ins Arbeiten kommt der Agent durch einen Menschen. POST /api/v1/agents/{id}/resume hebt die Pause auf, und dafür gelten dieselben Rollen wie für den Kill-Schalter. Bleibt der Deckel dabei stehen, pausiert die nächste Kostenbuchung den Agenten sofort wieder.

Der Deckel greift zwischen zwei Läufen

Hier endet die Genauigkeit. Die Kosten eines Laufs erreichen die Control Plane, wenn der Lauf fertig ist. Die Dokumentation schreibt das offen hin: Das Budget deckelt reaktiv, eine ausgeuferte Aufgabe kann es überschreiten, gebremst wird erst die nächste.

Ein Sub-Lauf im Projekt-Checkout bucht seine Kosten über dieselbe Nachricht wie der äußere Lauf und kann den Deckel deshalb nicht umgehen. Innerhalb eines einzelnen Laufs begrenzt das Turn-Limit, --max-turns, in der Vorgabe 30 Schritte.

Ein Budget-Flag für den Lauf selbst führt die Spezifikation auf, und das Feld reist bis in den Daemon. Der Adapter für Claude Code baut die Argumentliste ohne dieses Flag.

Für die Nacht aus dem Beispiel heißt das zweierlei. Der Agent läuft seinen Lauf zu Ende, und was dieser Lauf gekostet hat, steht erst danach fest. Beim nächsten Weckruf steht er still und die Aufgabe liegt offen. Auf der Seite des Agenten, /agents/{id}, steht der verbrauchte Betrag neben dem Deckel, der am Agenten eingetragen ist.