KI-Agenten-Kosten: Wie Fallbacks das Budget leeren

KI-Agenten-Kosten: Der dokumentierte Ausfall

Teuer war hier nicht ein ungewöhnlich großer Modellaufruf. Auslöser war eine blockierte Dateiübergabe, durch die ein kostenpflichtiger Fallback standardmäßig Aufgaben übernahm, für die er nie als Standard vorgesehen war.

Im Zeitraum 2026-09-18 → 09-19 arbeiteten zwei autonome Publishing-Agenten nach demselben Grundmuster: Ein Writer in einer Sandbox erstellte einen Artikel, anschließend veröffentlichte eine Website den Beitrag. Einer der Agenten war auf einem neuen Server neu gestartet worden. Er veröffentlichte innerhalb von zwölf Stunden 18 Artikel – und alle 18 Payloads enthielten Bildbeschreibungen, aber keine einzige Bilddatei.

Die Website interpretierte diese Beschreibungen als Generierungsaufträge. Über ein kostenpflichtiges Bildmodell entstanden 18 Cover und etwa 26 Abbildungen, was ungefähr $0.45 pro Artikel kostete. Beide Publikationen griffen auf dasselbe Guthaben des verbrauchsabhängig abgerechneten Gateways zu. Um 01:15 UTC war es von $8.30 auf $0 gefallen.

Die Zahl der Bilder und die Kosten pro Artikel sind Näherungswerte und müssen deshalb auch als solche stehen bleiben. Eine exakte Rekonstruktion des gemeinsamen Guthabens lässt sich daraus nicht ableiten. Auch die beiden Angaben zu fehlenden Ausgaben sind voneinander getrennte Beobachtungen. Sie ergeben keine gemeinsame Zahl eindeutig betroffener Artikel.

Die Belege führen zur Upload-Grenze

Payloads, Journale und Guthaben weisen auf dieselbe Bruchstelle: Der Writer konnte ein Bild beschreiben, aber die Bilddatei nicht übergeben.

• Alle 18 Payloads enthielten Szenenbeschreibungen und keine einzige Bilddatei. Das ist kein kleiner Qualitätsmangel beim Rendering. Das Artefakt hat die Publishing-Grenze schlicht nie überschritten.
• Ein Journal erwähnt das Bild-Tool 10-mal, das andere 0-mal. Beide Agenten nutzten dieselbe CLI-Version, verfügten über dasselbe Tool und arbeiteten mit denselben Flags. Die Fähigkeit war also vorhanden, lag aber außerhalb des erreichbaren Pfads des zweiten Writers.
• Das gemeinsame Guthaben sank um 01:15 UTC von $8.30 auf $0, während die Website aus Beschreibungen kostenpflichtige Bilder erzeugte. Als der Zahlungsweg ausfiel, fehlten über beide Publikationen hinweg Cover und Embeddings.

Deshalb ist der Vorfall weit über das Publishing hinaus relevant. Bei Agentenkosten geht es meist um Modellwahl, Tokenverbrauch oder die Zahl der Wiederholungsversuche. Hier setzte der Kosteneffekt eine Ebene früher ein: an der Sicherheitsgrenze zwischen dem Prozess, der eine Datei erzeugte, und den Zugangsdaten, die für ihren Upload nötig waren.

Wie eine sichere Sandbox den bezahlten Weg zum einzigen Weg machte

Den Website-Schlüssel aus einem Writer in einer Sandbox herauszuhalten, war die richtige Sicherheitsentscheidung. Der Architekturfehler bestand darin, einen zwingenden, schlüsselabhängigen Upload-Schritt trotzdem im Ablauf dieses Writers zu belassen.

Eine Sandbox begrenzt, worauf ein Agent zugreifen und was er verändern kann. In diesem Fall durfte die Shell des Writers den Website-Schlüssel nicht erhalten. Der Bild-Upload benötigte genau diesen Schlüssel. Damit war der direkte Weg von der gerenderten Datei zur gespeicherten Datei innerhalb der Sandbox nicht erreichbar.

Der Payload akzeptierte weiterhin eine Cover-Szene und Beschreibungen für Inline-Abbildungen. Ein Fallback ist der Ausweichweg, wenn der bevorzugte Pfad nicht zum Ziel kommt. Da der Payload mit Beschreibungen, aber ohne Dateien eintraf, erzeugte die Website die Bilder über ein verbrauchsabhängig abgerechnetes Gateway. So war der Ausweichweg unbemerkt zum einzigen Weg geworden.

Der andere Agent folgte einem tatsächlich erreichbaren Pfad. Sein Writer griff auf ein im Abonnement enthaltenes Bild-Tool zu, renderte die Dateien und lud sie selbst hoch. „Im Abonnement enthalten“ bedeutet nicht, dass das Abonnement kostenlos war. Es bedeutet lediglich, dass bei diesem Lauf nicht jedes fehlende Bild den hier beschriebenen separaten, kostenpflichtigen Fallback durchlief.

Die Konsequenz lautet nicht, die Sandbox zu schwächen. Arbeit mit Zugangsdaten gehört auf die vertrauenswürdige Seite der Grenze. Die Wahl zwischen Code-Sandboxes für KI-Agenten ist wichtig. Doch kein Sandbox-Produkt kann einen Workflow reparieren, der dem Writer einen für ihn unerreichbaren Schritt mit Zugangsdaten zuweist.

Warum done der falsche Status war

Der Zahlungsfehler hätte den Ausgang des Jobs verändern müssen. Stattdessen behandelte das System 402 als Soft Failure: Der Fehler wurde registriert oder toleriert, der Job aber nicht gestoppt.

Damit fielen Aufgabenerledigung und vollständige Ausgabe auseinander. Weil sich der Artikeltext veröffentlichen ließ, meldete der Job done – selbst wenn ein erforderliches Cover oder Embedding fehlte.

Ein Embedding ist eine gespeicherte Repräsentation von Inhalten, mit der dieses System verwandtes Material für interne Verlinkung und Suche findet. Ein fehlendes Cover fällt auf der Seite sofort auf. Ein fehlendes Embedding bleibt leichter verborgen: Der Artikel existiert, taucht aber nicht in den Systemen auf, die ihn finden und mit anderen Inhalten verbinden. So konnten fünf Artikel ohne Embeddings veröffentlicht werden, ohne dass der abschließende Status den Mangel erkennen ließ.

Der richtige Vertrag für den Abschluss ist simpel: Ein Job ist erst erledigt, wenn alle vom Workflow als erforderlich definierten Ausgaben vorhanden sind. Ist ein Cover Pflicht, muss das Cover bestätigt werden. Ist ein Embedding Pflicht, muss das Embedding bestätigt werden. Eine Textzeile in einer Datenbank beweist noch nicht, dass der Publishing-Job abgeschlossen ist.

Was der Vorfall für Entwickler, Betreiber und Käufer bedeutet

Derselbe Vorfall verändert drei unterschiedliche Entscheidungen.

Entwickler: Die Übergabe entwerfen, nicht nur die Sandbox

Entwickler sollten die Grenze für Zugangsdaten einzeichnen und jeden Schritt, der sie überschreitet, einem Verantwortlichen zuweisen. „Der Writer darf keinen Schlüssel erhalten“ ist eine Sicherheitsregel. Daneben kann nicht zugleich „Der Writer lädt mit diesem Schlüssel hoch“ als Workflow-Anforderung bestehen bleiben.

Jedes Agentensystem stößt irgendwann an die Grenze zwischen erzeugter Absicht und externer Wirkung. Eine Beschreibung zu schreiben, formuliert eine Absicht. Ein Bild zu speichern, einen kostenpflichtigen Anbieter zu belasten und einen Artikel zu veröffentlichen, sind externe Wirkungen. Für jede davon braucht es eine klar benannte vertrauenswürdige Instanz, ein beobachtbares Ergebnis und einen Fehlerstatus, der bis zum übergeordneten Job durchgereicht wird.

Betreiber: Gemeinsame Abhängigkeiten gemeinsam überwachen

Ein geteiltes, verbrauchsabhängig abgerechnetes Guthaben ist gemeinsame Infrastruktur und keine beiläufige Anbietereinstellung. In diesem Vorfall hingen Cover, Abbildungen und Embeddings für zwei Publikationen von demselben Guthaben ab. Das Fallback-Verhalten eines Writers beeinflusste damit die Zuverlässigkeit einer anderen Publikation.

API-Budgetkontrollen für KI-Agenten können die Ausgaben begrenzen. Ein Limit allein korrigiert aber noch keinen fehlerhaften Artefaktpfad. Die gemeinsame Sicherung braucht eine klare Bezeichnung und Zustandsüberwachung; ein aufgebrauchtes Guthaben muss für jeden abhängigen Workflow sichtbar sein. Der Quelldatensatz enthält weder einen Alarmschwellenwert noch Messwerte nach der Behebung – beides darf daher nicht erfunden werden.

Käufer: Fragen, was nach dem Happy Path passiert

Käufer sollten wissen wollen, ob ein Fallback kostenpflichtig ist, welche Produkte sein Budget teilen und welchen Status ein Job meldet, wenn der Fallback nicht mehr bezahlt werden kann. Eine Demo, die einmal erfolgreich durchläuft, beantwortet keine dieser Fragen.

Ein brauchbarer Vertrag benennt die erforderlichen Ausgaben, die Partei mit den Zugangsdaten, den bezahlten Fallback und den Status für den Fall, dass eine Ausgabe fehlt. Bei Wiederholungsversuchen, die Geld kosten oder unvollständige Arbeit veröffentlichen können, ist die menschliche Freigabe von Wiederholungsversuchen bei KI-Agenten eine weitere Kontrollmöglichkeit. Sie ergänzt den Artefaktvertrag, ersetzt ihn aber nicht.

Sofort handeln, abwarten oder den Pfad unverändert lassen

Sofortiger Handlungsbedarf besteht, wenn ein Writer in einer Sandbox Beschreibungen einreichen, aber die dadurch ersetzten Dateien nicht bereitstellen kann, wenn mehrere Produkte dieselbe kostenpflichtige Abhängigkeit teilen oder wenn ein fehlgeschlagener Fallback trotzdem mit done endet. Ein Redesign kann nur warten, wenn die aktuellen Logs belegen, dass gespeicherte Dateien die Grenze passieren und fehlende Pflichtausgaben den Erfolg bereits verhindern. Von genau diesem Ausfall eines gemeinsamen Guthabens bleibt ein Workflow nur dann unberührt, wenn seine zwingenden Publishing-Ausgaben weder direkt noch durch eine Fallback-Generierung von diesem Guthaben abhängen.

Überschätzt: Mehr Fallbacks bedeuten nicht mehr Resilienz

Ein Fallback schafft nicht allein deshalb Resilienz, weil er den Job am Laufen hält. Belastbar ist er erst, wenn Kosten, Abhängigkeiten, Ausgabequalität und Fehlerstatus verstanden sind.

Solange das Guthaben reichte, erledigte der Fallback nützliche Arbeit. Zugleich verdeckte er, dass der primäre Upload-Pfad unerreichbar war. Genau diese Kombination ist gefährlich: Scheinbare Verfügbarkeit kann das Signal hinauszögern, das die defekte Grenze sichtbar gemacht hätte.

Ein weiterer Anbieter würde das Grundproblem nicht lösen. Er könnte eine weitere Rechnung und einen weiteren Soft Failure hinzufügen, während done weiterhin nichts über die erforderlichen Artefakte aussagt. Das technische Ziel ist nicht eine möglichst große Sammlung alternativer Pfade. Es ist ein primärer Pfad, den der Agent tatsächlich erreichen kann – ergänzt um einen Fallback, dessen Kosten sichtbar sind und der unübersehbar scheitern darf.

Technische Regeln, die KI-Agenten-Kosten sichtbar halten

Die Lösung beginnt bei der Verantwortung und macht anschließend Kosten und Abschlussbedingungen ausdrücklich sichtbar.

Zugangsdaten gehören in den vertrauenswürdigen Prozess

Der Writer in der Sandbox sollte den Artikel, den Payload und alle Bilddateien erzeugen, die er rendern kann. Ein vertrauenswürdiger Prozess außerhalb der Sandbox übernimmt den Upload, der eine Autorisierung erfordert. So bleibt die Sicherheitsgrenze bestehen, statt ein schlüsselförmiges Loch hineinzuschlagen.

Dateien und Beschreibungen als verschiedene Eingabeklassen behandeln

Eine Datei ist ein fertiges Artefakt. Eine Beschreibung ist ein Rezept, um ein Artefakt zu erzeugen. Wer beides gleichbehandelt, verschleiert Kosten und Fehlerverhalten.

Der Publishing-Vertrag sollte bereitgestellte Dateien bevorzugen. Beschreibungen bleiben als Provenienz- und Reparaturdaten erhalten. Ruft das System sie für eine Fallback-Generierung auf, muss dieser Zweig als kostenpflichtig benannt und auch entsprechend gemeldet werden.

done an die erforderlichen Ausgaben binden

Der übergeordnete Job muss auf die versprochenen Artefakte warten. Ein weicher Zahlungsfehler darf nicht in done enden, wenn der Vertrag für Cover oder Embedding unerfüllt bleibt. Pflichtausgaben müssen vor dem abschließenden Erfolgsstatus geprüft werden – nicht in einem späteren Bericht, der den Schaden nur noch beschreiben kann.

Den Zustand der Abhängigkeit getrennt von den Task-Logs erfassen

Der Unterschied zwischen den Journalen war aufschlussreich: Er zeigte, dass ein Agent das Bild-Tool nutzte und der andere nicht. Dieses Signal sollte erhalten bleiben. Zusätzlich muss der Zustand der gemeinsamen kostenpflichtigen Abhängigkeit für jede Publikation sichtbar sein, die darauf angewiesen ist. Ein Job-Log zeigt, was ein einzelner Worker versucht hat. Die Telemetrie der Abhängigkeit zeigt, ob der gemeinsame Pfad überhaupt noch jemanden bedienen kann.

Der folgende Code ist ein veranschaulichendes Muster und kein Produktionscode. Er beschreibt lediglich Zuständigkeiten und Statusfluss; das Quellenmaterial enthält weder Implementierungsdetails noch ein gemessenes Ergebnis nach der Behebung.

// Illustrative only. This is not production source.
const handoff = {
  payload: writerOutput.payload,
  pictureFiles: writerOutput.pictureFiles,
  pictureDescriptions: writerOutput.pictureDescriptions,
};

const stagedFiles = await trustedProcess.stage(
  handoff.pictureFiles,
  "presigned PUT",
);

const fallbackRender = stagedFiles.complete
  ? null
  : await paidFallback(handoff.pictureDescriptions);

if (fallbackRender?.status === 402) {
  failJob("Paid fallback unavailable");
}

const publishableArtifacts = mergeArtifacts(
  stagedFiles,
  fallbackRender,
);

const rewrittenPayload = rewritePictureReferences(
  handoff.payload,
  publishableArtifacts,
);

rewrittenPayload.pictureDescriptions = handoff.pictureDescriptions;

assertRequiredArtifacts(rewrittenPayload);
markDone();

Entscheidend ist die Reihenfolge: Der Writer gibt Dateien aus, ohne den Website-Schlüssel zu erhalten. Der vertrauenswürdige Prozess stellt sie bereit, der Payload verweist auf die gespeicherten Artefakte und erst ein verifizierter Abschluss darf zu done werden.

Die Übergabe, die das Budgetleck schließt

Die nachhaltige Lösung besteht aus einer zweigeteilten Übergabe: Der Writer rendert, die vertrauenswürdige Instanz stellt bereit.

Der Writer legt die Bilddateien neben dem Payload in jener Ausgabe ab, die er ohnehin erzeugen darf. Der vertrauenswürdige Prozess außerhalb der Sandbox übernimmt diese Dateien und sendet sie per presigned PUT, also über einen für genau diese Übergabe autorisierten Upload. Der vorliegende Datensatz macht keine Angaben zu Ablaufzeit oder Berechtigungen; diese Details bleiben deshalb Implementierungsentscheidungen und werden hier nicht als Tatsachen dargestellt.

Nach der Bereitstellung schreibt der vertrauenswürdige Prozess den Payload so um, dass seine Bildverweise auf die gespeicherten Dateien zeigen. Die Website erhält Artefakte statt Anweisungen, sie zu erzeugen. Der Writer bekommt den Website-Schlüssel nie, und der Publishing-Pfad hängt nicht länger von der Fiktion ab, er hätte ihn erhalten.

Die Beschreibungen bleiben im Payload. Sie dienen als Reparaturprotokoll und als bezahlter Fallback, wenn der Writer ein Bild nicht rendern kann. Der Fallback kann also weiterhin Geld kosten. Die Reparatur beseitigt ihn nicht und behauptet auch keine gemessene Einsparung. Sie macht die Dateibereitstellung wieder zum erreichbaren primären Pfad und die kostenpflichtige Generierung erneut zur Ausnahme.

Die Aufgabe für Montag

Jeder zwingende Schritt, der Zugangsdaten benötigt, muss nachverfolgt werden. Kann der Writer diese Daten nicht besitzen, gehört die Aktion in einen vertrauenswürdigen Prozess – ergänzt um eine klar definierte Artefaktübergabe. Anschließend muss der abschließende Jobstatus vom erforderlichen Cover, Embedding und den Verweisen auf gespeicherte Dateien abhängen. Beschreibungen bleiben neben diesen Dateien erhalten, doch der von ihnen ausgelöste Weg braucht ein unmissverständliches Etikett: bezahlter Fallback.

FAQ

Die nächste Analyse aus dem Produktionsbetrieb gibt es im Newsletter.