Kosten verwalten

Diese Anleitung zeigt dir, was Agentenläufe kosten und wie du einen autonomen Lauf begrenzst.

Wie Kosten erfasst werden

Jeder Agentenlauf schreibt ein Laufprotokoll mit seinen Eingabe-Token, Ausgabe-Token, Reasoning-Token, Token für Cache-Lesen und Cache-Schreiben, einer geschätzten Kostenangabe in Cent und den Kosten aller Subagenten, die er gestartet hat.

Die Preise kommen aus dem Katalog models.dev. Der reichert die Modellliste nur mit Preis und Kontextfenster an — nie als Quelle für Modell-IDs. Ein Modell, das der Katalog nicht bepreisen kann, wird mit 0 $ erfasst, und Läufe ohne Kosten fehlen in der Zusammenfassung Nutzung & Kosten. Ein lokales Ollama-Modell zeigt deshalb gar keine Ausgaben, seine Tokenzahlen werden aber trotzdem erfasst. Ein Pauschaltarif (kimi-code, ein Claude-Abo) verhält sich genauso, aber nur wenn der Katalog für das ausgelieferte Modell keinen Preis hat; hat er einen, wird der Lauf trotzdem zu diesen Sätzen geschätzt. Bei einer Fallback-Kette wird der Lauf nach dem Modell bepreist, das ihn tatsächlich bedient hat, nicht nach dem angeforderten.

Was du ausgibst

Observability → Übersicht

Du erreichst sie über die Fußzeile der Seitenleiste → Observability. Der Tab Nutzung öffnet zuerst (Token-Summen über die gesamte Lebensdauer); wechsle zu Übersicht — dem zweiten Tab — für die eigentliche Kostenansicht:

Eine Zeitraumauswahl: Letzte 24 Stunden, Letzte 7 Tage, Letzte 30 Tage oder Gesamte Zeit
Facettenfilter über Agent, Modell, Status und Rolle, als Chips, die du wieder wegnehmen kannst
Eine KPI-Leiste: Läufe gesamt, Gesamtkosten, Fehlerrate, Cache-Rate, Token / s, Ø Latenz und Zeit bis zum ersten Token, jeweils mit der Veränderung gegenüber dem vorherigen Zeitraum (ausgeblendet bei „Gesamte Zeit“)
Diagramme für Aktivität und Kosten im Zeitverlauf, dazu die Aufschlüsselung Kosten nach Rolle, die die Ausgaben auf Hauptagent, Subagenten und Berater verteilt
Eine Tabelle je Agent, nach Kosten sortiert, die ersten zehn mit einem Schalter, der alle anzeigt. Ein Tipp auf eine Zeile filtert jede andere Ansicht auf diesen Agenten
Das feine Laufprotokoll, das für einen ausgewählten Lauf eine Schublade mit dem Transkript andockt

Einstellungen → Server → Modellanbieter

Die Karte Nutzung & Kosten auf dieser Seite zeigt die beobachteten Ausgaben der letzten sieben Tage als eine einzige Dollarzahl, mit einer Aufschlüsselung je Anbieter und, sofern ein Anbieter sie veröffentlicht, der Zeit bis zum nächsten Zurücksetzen des Kontingentfensters.

Die Läufe eines einzelnen Agenten

Einstellungen → Arbeitsbereich → Agenten → einen Agenten auswählen → Protokolle listet seine Läufe mit Status, Dauer, Start- und Endzeit, PID und Adapter. Dieser Tab zeigt keine Kosten — dafür nimmst du die Tabelle je Agent unter Observability → Übersicht.

Einen autonomen Lauf begrenzen

Zwei Slash-Befehle, im Composer eines Bereichs getippt, sind die einzigen Läufe mit einer Kostenobergrenze:

/goal ship the auth refactor --budget 20
/loop keep the flaky tests green

Jedes Segment eines Laufs /goal oder /loop stoppt, wenn die bepreisten Ausgaben 500 Cent (5,00 $) erreichen. Bei 80 % davon steuert die Schleife das Modell zuerst an, abzuschließen und eine saubere Übergabe zu hinterlassen, damit es nicht mitten in der Aufgabe abbricht.
Ein ganzes dauerhaftes Ziel ist auf 5.000 Cent (50,00 $) begrenzt, sofern du nicht --budget <dollars> angibst. Der Supervisor reicht das verbleibende Budget des Ziels in jedes Segment, sodass ein ausdrückliches Budget nie um ein ganzes Segment überschritten wird.
--days N setzt eine Frist nach der Wanduhr und --max N eine Obergrenze für die Anzahl der Läufe. Beides setzt du ausdrücklich; ohne sie ist das Ziel nur durch die Kosten begrenzt.
Ein Ziel, das an seine Obergrenze stößt, stoppt bei budgetExhausted und lässt sich nur fortsetzen, indem du das Budget anhebst.

Weil die Obergrenze über den Preis läuft, erreicht ein Modell, das der Katalog nicht bepreisen kann, sie nie. So ein Lauf ist stattdessen durch den Schutz vor Endlosschleifen, das Aufgeben des Supervisors nach drei Fehlern hintereinander und durch dich begrenzt.

Eine Nachricht in einem Bereich, eine @-Erwähnung oder ein Pipeline-Schritt hat keine Kostenobergrenze. Der Lauf endet, wenn das Modell stoppt, wenn du ihn stoppst oder wenn der Schutz vor Endlosschleifen ihn umlenkt.

Tokenverbrauch senken

Eine lange Unterhaltung verdichten

Tippe /compact im Composer des Bereichs. Der Befehl wird auf dem Client abgefangen und landet nie im Transkript; der Server faltet älteren Verlauf in eine verankerte Zusammenfassung, und die Unterhaltung läuft auf dem verdichteten Kontext weiter.

Verdichtet wird nicht, solange ein Agent mitten im Turn ist, und auch dann nicht, wenn nichts alt genug zum Falten ist. Der eingebaute Harness verdichtet außerdem von selbst, sobald der Verlauf sich dem Kontextfenster des Modells nähert.

Den Aufwand bewusst wählen

Der Reasoning-Aufwand eines Agenten (Einstellungen → Arbeitsbereich → Agenten) bietet die Stufen, die das gewählte Modell veröffentlicht. Höhere Stufen verbrauchen mehr Reasoning-Token. Die obersten hebst du dir für Arbeit auf, die sie braucht.

Das Modell je Agent wählen

Das Modell ist ein Feld je Agent, deshalb kann ein Formatierungs- oder Triage-Agent auf einem günstigen Modell laufen, während ein Architektur-Agent auf einem teuren läuft. Filter die Tabelle je Agent unter Observability → Übersicht nach Modell, um zu sehen, welche Paarung dich wirklich etwas kostet.

Nach Läufen mit auffällig hohen Tokenzahlen suchen

Öffne das Laufprotokoll in der Übersicht (die 50 neuesten gefilterten Läufe) und die Schublade mit dem Transkript bei allem Ungewöhnlichen. Die üblichen Ursachen sind ein überlanger System-Prompt oder eine überlange Persona, Kontext, der verdichtet gehört hätte, und eine Aufgabe, die aus mehreren kleineren hätte bestehen sollen.

Was passiert, wenn ein Budget direkt in die Zeile geschrieben wird

Der Vollständigkeit halber, wenn monthlyBudgetCents oder eine Budgetrichtlinie direkt in eine Agentenzeile geschrieben wird:

Budgets werden nach dem Abschluss eines Laufs ausgewertet, nicht vor dem Dispatch. Ein Listener beim Laufabschluss vergleicht die Ausgaben des Agenten seit Monatsbeginn mit seiner Obergrenze.
Beim Überschreiten der weichen Schwelle (standardmäßig 80 %) entsteht ein Warnvorfall, und es wird ein Ereignis BudgetThresholdCrossed ausgelöst, an das du einen Pipeline-Trigger hängen kannst.
Ist das Budget aufgebraucht, entsteht ein harter Vorfall, dasselbe Ereignis wird ausgelöst, und der Lebenszyklusstatus des Agenten wechselt auf paused.
Die Sperre vor dem Dispatch gibt es, konsultiert wird sie aber nur vom Reaper für verwaiste Läufe und vom Reconciler für gestrandete Tickets, wenn sie die Wiederherstellung einplanen — ein normaler Dispatch erreicht sie nie, und auf dem Dispatch-Pfad prüft nichts den Status paused. Das einzige sichtbare Signal ist das Lebenszyklus-Badge im Organigramm.