Stell dir das Horizon-Dashboard an einem Montag um 07:42 vor. Ein Job zeigt seit Freitagabend 15.000 Versuche an, und er ist nie so gescheitert, dass es jemandem aufgefallen wäre. Noch bevor der Kaffee durchgelaufen ist, wird jemand angepiept, ein Timeout landet in der Job-Klasse, und das Postmortem ist eine einzige Zeile im Team-Channel. Warum zucken dann so viele von uns nur mit den Schultern, wenn ein KI-Coding-Agent genau das mit unserem Abo macht?

Die Zahl ist übrigens echt. Ende August hat OpenAI die Codex-Kontingente zahlender Nutzer zurückgesetzt, nachdem das Team einen Haufen Beschwerden auf clientseitige Bugs zurückgeführt hatte, die still und leise Tokens verbrannten. Der Reset ist längst Geschichte, und ob dein Kontingent an jenem Wochenende aufgefüllt wurde, interessiert heute niemanden mehr. Die Bugliste dagegen schon, denn sie liest sich wie ein Rundgang durch unseren eigenen Incident-Tracker. In einem Thread prüfte ein Memory-Task im Hintergrund mehr als 15.000 Mal, ob er aufhören darf. Manche /goal-Läufe beendeten sich nach getaner Arbeit nicht oder wiederholten kaputte Tool-Calls immer wieder, und das kostete die größten Pechvögel zwischen 15 und 70 Prozent ihres Wochenkontingents. Eine History-Funktion fasste Aktivitäten erneut zusammen, die sie längst zusammengefasst hatte, und fraß bei manchen ein Fünftel der Woche. Einige MCP-Tool-Ergebnisse wurden doppelt kodiert. Laut Team brachte die Behebung all dessen den Nutzern je nach Arbeitsweise etwa 10 bis 50 Prozent mehr nutzbares Kontingent.

Nimm das KI-Branding weg, und übrig bleiben vier Bugs, die jeder PHP-Entwickler mindestens einmal ausgeliefert hat: die Retry-Schleife ohne Obergrenze, der Worker, der sich nie beendet, der Job, der bereits erledigte Arbeit noch einmal macht, und json_encode auf einem String, der schon JSON war. In unseren eigenen Systemen fangen wir so etwas ab, weil wir gelernt haben, meistens um drei Uhr nachts, alles, was ohne menschliche Aufsicht läuft, mit einem Timeout, einem Max-Tries-Wert und einer Logzeile zu versehen. Ein Agent, der eine lange Aufgabe abarbeitet, ist genau so ein Ding. Er ist ein Hintergrundprozess, der in deinem Namen Geld ausgibt.

Fairerweise muss man sagen: Der Anbieter hat das verstanden. Das Codex-Team erklärte, es habe automatische Alerts für diese Art von Verschwendung eingebaut, und versprach den Nutzern eine Aufschlüsselung, wohin ihre Tokens gehen. Wenn du das hier liest, ist diese Ansicht vielleicht schon live, und der Anbieter sieht Dinge, die du nie sehen wirst, etwa was Client und Modell tatsächlich miteinander austauschen. Wenn es schon ein Dashboard gibt, wirkt ein eigenes überflüssig, und diesen Einwand nehme ich ernst.

Ich will trotzdem mein eigenes Kassenbuch. Eine Aufschlüsselung des Anbieters sagt dir, welche Funktion im Tool die Tokens verbraucht hat. Sie kann dir nicht sagen, dass das Refactoring zu Ticket 4127 dreimal so viel gekostet hat, wie die Änderung wert war, oder dass die Automatisierung eines Kollegen alle zehn Minuten feuert, obwohl sie stündlich laufen sollte. Und der Zähler gehört derselben Firma, die auch die Rechnung schickt. Das ist kein Vorwurf. Es ist derselbe Grund, aus dem niemand den Export des Payment-Providers als einzige Buchhaltungsgrundlage nimmt, egal wie sehr man ihm vertraut.

In der Praxis bedeutet das weniger, als es klingt. Behandle jede Agent-Session wie einen Cron-Eintrag: Sie braucht eine namentlich verantwortliche Person und ein hartes Zeitlimit. Logge die Token-Zahlen pro Branch oder Ticket, an derselben Stelle, an der deine anderen Job-Metriken ohnehin landen. Und dann wirf einmal pro Woche einen kurzen Blick auf die Summen, so wie du die Slow-Query-Logs überfliegst. Unsere Go-schreibenden Nachbarn werden anmerken, dass context.WithTimeout die Hälfte davon in einer Zeile erledigt, und ärgerlicherweise haben sie mit dieser Hälfte recht. Die andere Hälfte ist schlicht Aufmerksamkeit. Und Aufmerksamkeit kostet nichts.

Mich interessiert also, wie dein Team das tatsächlich handhabt. Wenn ein Agent die Hälfte eures Wochenbudgets für eine Aufgabe verbrennt, um die niemand gebeten hat, woher erfährst du es zuerst: aus deinen eigenen Logs oder aus dem Dashboard des Anbieters, wenn der Schaden schon angerichtet ist?