Zum Hauptinhalt springen
Ein Reasoning-Agent, der in einer Retry-Schleife steckenbleibt, tausend Sub-Tasks auffächert oder einfach mitten im Plan davonläuft, kann echtes Geld ausgeben, bevor es jemand bemerkt. Das cap_cost-Firewall-Verdikt ist der Schutzschalter dafür: Sie verfassen einmal eine Pro-Run-Cent-Obergrenze, und das Gateway verweigert den nächsten Tool-Call in dem Moment, in dem die akkumulierten Ausgaben eines Runs sie überschreiten — bevor dieser Aufruf das Modell oder das Tool erreicht. Dies ist KI-Agenten-Kostenkontrolle, durchgesetzt am Gateway, nicht an Ihre Agentenschleife geschraubt. Wie jedes Firewall-Verdikt lebt eine cap_cost-Regel in einer Workspace-Policy, hängt sich an einen Key und wird beim nächsten Aufruf ohne Redeploy wirksam.

​
1. Der Pro-Run-Ausgaben-Schutzschalter

cap_cost ist ein Regel-Verdikt, das Sie mit einem zusätzlichen Feld verfassen — cap_cost_cents, der Ausgaben-Obergrenze des Runs in USD-Cent. Wenn die Regel einen Tool-Call matcht, vergleicht die Engine die akkumulierten Ausgaben des Agentenlaufs gegen diese Obergrenze:
  • Unter der Obergrenze → der Aufruf wird erlaubt; die Auswertung läuft weiter.
  • Über der Obergrenze → der Aufruf wird verweigert, mit einem Grund, der die Gesamtsumme des Runs gegen die Obergrenze benennt. Das ist das terminale, Schutzschalter-Ergebnis — der Run kann keinen weiteren gesteuerten Aufruf ausstellen, bis ein frischer Run beginnt.
Die Obergrenze ist auf den Agentenlauf geschlüsselt, nicht auf einen einzelnen Request. Ein langer Run, der bereits den Großteil seines Budgets verbrannt hat, wird bei seinem nächsten Aufruf verweigert, selbst wenn dieser eine Aufruf günstig ist — der Schutzschalter löst auf der laufenden Summe aus, nicht auf den Grenzkosten.
Run-Scope, mit einem Pro-Request-Fallback. Wenn der Request eine Agent-Run-ID trägt, gilt die Obergrenze für die akkumulierten Ausgaben des Runs. Ein Aufruf ohne Run-Zuordnung (z. B. ein bloßer MCP-Dispatch ohne weitergeleitete Session) fällt stattdessen auf einen Pro-Request-Vergleich zurück. So oder so löst der Schutzschalter aus, bevor der über-budgetierte Aufruf dispatcht wird.

​
2. Ein konkretes Beispiel

Begrenzen Sie jeden Run auf einem Key auf 5,00 $ akkumulierter Ausgaben. Eine einzelne Wildcard-Regel erledigt das — cap_cost_cents ist 500 (Cent): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Verfassen Sie sie im Konsolen-Regeleditor auf einer Policy, die Sie erstellt haben (siehe Policy erstellen & anhängen). Eine Regel zu schreiben ist eine Developer+-Aktion. Hängen Sie die Policy via firewall_policy_id an einen Key, oder machen Sie sie zum Workspace-Default, und jeder Run, den dieser Key treibt, ist nun begrenzt. Sie können die Obergrenze enger scopen als „jedes Tool”. Engen Sie das Tool-Namen-Glob ein, sodass nur eine teure Aufruffamilie zum Schutzschalter zählt — z. B. cap_cost auf *.search, um Web-Search-Fan-out zu begrenzen, während günstige lokale Tools ungemessen bleiben.
Stapeln Sie eine günstigere Warnstufe mit Prioritäten. Eine audit-Regel mit niedrigerer Obergrenze auf einer höheren Priorität (niedrigere Zahl) lässt Sie einen Run im Events-Feed sein Budget beobachten sehen, bevor die durchsetzende cap_cost-Regel auslöst. Erster Treffer gewinnt, ordnen Sie also den Beobachter zuerst.

​
3. Wo es feuert — und wo es nicht kann

cap_cost macht nur vor dem Dispatchen eines Aufrufs Sinn — das ist der eine Punkt, an dem das Stoppen des Aufrufs die Ausgabe noch verhindert. Daher ist es auf den zwei Pre-Dispatch-Surfaces aktiv und auf den Post-Dispatch-Surfaces abgewiesen:
Surfacecap_cost?
inbound (angebotene Tools)Durchgesetzt.
mcp (tools/call-Dispatch)Durchgesetzt.
response (modellausgegebene Aufrufe)Beim Speichern abgewiesen — nichts mehr zu stoppen.
egress (ausgehendes Ziel)Beim Speichern abgewiesen — nichts mehr zu stoppen.
Eine cap_cost-Regel, die auf response oder egress gepinnt ist, wird zur Speicherzeit abgelehnt, sodass eine Regel nie als aktiv erscheinen und doch nie verweigern kann. Lassen Sie die Stage leer, um beide Pre-Dispatch-Surfaces abzudecken, oder pinnen Sie sie auf inbound / mcp.
cap_cost_cents ist für eine cap_cost-Regel erforderlich und nicht-negativ. Konsole und API lehnen eine cap_cost-Regel ohne Obergrenze ab, sodass eine fehlkonfigurierte Obergrenze nicht stillschweigend jeden Aufruf durchlassen kann.

​
4. Wie der Schutzschalter aussieht, wenn er auslöst

Ein über-budgetierter Aufruf ist ein normales Firewall-deny:
  • Auf inbound gibt das Relay HTTP 400 mit dem Fehlercode firewall_blocked zurück. Der Block feuert vor dem Upstream-Modellaufruf, sodass er keine Modell-Tokens kostet, und er ist als skip-retry markiert — das erneute Ausführen desselben Aufrufs würde einfach den Schutzschalter wieder auslösen.
  • Auf mcp kommt er als Tool-Fehler zurück, sodass das Modell die Ablehnung sieht und anhalten oder den Nutzer fragen kann, statt abzustürzen.
Der Deny-Grund benennt die Zahlen, z. B. cap_cost: estimated run cost $5.40 exceeds cap $5.00, sodass ein Operator, der den Events-Feed liest, genau sieht, warum der Schutzschalter ausgelöst hat.
Events tragen nie ein literales cap_cost. Sie verfassen das Verdikt als cap_cost, aber die Engine löst es zu einem konkreten allow oder deny auf, bevor das Event aufgezeichnet wird. Der Feed zeigt das allow/deny, das der Agent tatsächlich gesehen hat — die Run-Kosten-Obergrenze ist der Grund, nicht das Verdikt-Label. Dies spiegelt wider, wie Verdikte auflösen.

​
5. Sicher ausrollen

Weil ein ausgelöster Schutzschalter einen Run hart stoppt, validieren Sie ihn, bevor Sie durchsetzen. Schalten Sie Shadow-Mode auf der Policy ein: die cap_cost-Regel wertet weiterhin aus und ein Möchtegern-Deny wird auf audit herabgestuft, mit Präfix [shadow] would …. Beobachten Sie den Events-Feed, um zu bestätigen, dass die Obergrenze dort auslöst, wo Sie es erwarten — und nur dort —, dann schalten Sie den Shadow-Mode aus, um mit dem Durchsetzen zu beginnen. Sie können auch eine Policy gegen einen Beispielaufruf im Test-Tab dry-runnen (eine Developer+-Sandbox), um das aufgelöste Verdikt und die gematchte Regel zu sehen, bevor irgendetwas davon abhängt.

​
6. Wie es zum Rest der Firewall passt

cap_cost ist eines von sechs Verdikten. Es paart sich natürlich mit den anderen Kontrollen auf derselben Policy:

Verdikte

Der vollständige Satz — allow, audit, deny, sanitize, pending_approval und wie cap_cost auflöst.

Gefährliche Tools blockieren

Destruktive Shell, Deletes und andere hochriskante Aufrufe pauschal verweigern.

Regel-Referenz

Die vollständige Matching-Sprache — Globs, Argument-Klauseln, Sequenzen.

Anomalieerkennung

Kosten-Spikes geflaggt gegen eine gelernte Hour-of-week-Baseline.
Eine Run-Kosten-Obergrenze ist ein statischer, deterministischer Backstop; die Firewall lernt außerdem die normale Kostenform jedes Workspaces und flaggt Spikes gegen eine 14-Tage-Hour-of-week-Baseline auf einem für Member lesbaren Anomalie-Feed. Verwenden Sie cap_cost für den harten Stopp, Anomalien für das Frühsignal.
Kontingentlimits auf dem Key selbst (credit_limit_usd) begrenzen die Gesamtausgaben über alle Runs hinweg; cap_cost begrenzt einen einzelnen Run. Sie komponieren — eine außer Kontrolle geratene Schleife löst den Pro-Run-Schutzschalter aus, lange bevor sie das Lebenszeit-Guthaben des Keys erschöpfen kann. Siehe Scope: Keys, Policies, Workspaces.

​
Wohin als Nächstes

Policy erstellen & anhängen

Eine Policy anlegen, ein Default-Verdikt wählen, sie an einen Key binden.

Shadow-Mode

Messen Sie eine Obergrenze, bevor sie den Traffic ändert.
Für die Davonlauf-Agent-Bedrohungen, die eine Ausgaben-Obergrenze backstoppt, siehe übermäßige Handlungsmacht und gefährliche Tool-Calls.