Passer au contenu principal
Un agent de raisonnement qui se coince dans une boucle de retry, déploie un millier de sous-tâches, ou s’emballe simplement en milieu de plan peut dépenser de l’argent réel avant que quiconque ne le remarque. Le verdict firewall cap_cost est le disjoncteur pour cela : vous rédigez un plafond en centimes par exécution une fois, et la passerelle refuse le prochain appel d’outil au moment où la dépense accumulée d’une exécution le franchit — avant que cet appel n’atteigne le modèle ou l’outil. C’est du contrôle de coût des agents IA appliqué à la passerelle, pas greffé sur votre boucle d’agent. Comme chaque verdict firewall, une règle cap_cost vit dans une politique d’espace de travail, s’attache à une clé, et prend effet dès le prochain appel sans redéploiement.

​
1. Le disjoncteur de dépense par exécution

cap_cost est un verdict de règle que vous rédigez avec un champ supplémentaire — cap_cost_cents, le plafond de dépense de l’exécution en centimes USD. Quand la règle correspond à un appel d’outil, le moteur compare la dépense accumulée de l’exécution d’agent à ce plafond :
  • Sous le plafond → l’appel est autorisé ; l’évaluation continue.
  • Au-dessus du plafond → l’appel est refusé, avec une raison nommant le total de l’exécution par rapport au plafond. C’est le résultat terminal de disjoncteur — l’exécution ne peut pas émettre un autre appel gouverné jusqu’à une nouvelle exécution.
Le plafond est keyé à l’exécution d’agent, pas à une seule requête. Une longue exécution qui a déjà brûlé la plus grande partie de son budget est refusée sur son prochain appel même quand cet unique appel est bon marché — le disjoncteur se déclenche sur le total courant, pas sur le coût marginal.
Portée d’exécution, avec un fallback par requête. Quand la requête porte un id d’exécution d’agent, le plafond s’applique à la dépense accumulée de l’exécution. Un appel sans association d’exécution (par ex. un dispatch MCP nu sans session transmise) retombe sur une comparaison par requête à la place. Dans les deux cas, le disjoncteur se déclenche avant que l’appel hors-budget ne soit dispatché.

​
2. Un exemple concret

Plafonnez toute exécution sur une clé à 5,00 $ de dépense accumulée. Une seule règle wildcard fait l’affaire — cap_cost_cents est 500 (centimes) : 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Rédigez-la dans l’éditeur de règles de la console sur une politique que vous avez créée (voir Créer et attacher une politique). Écrire une règle est une action Developer+. Attachez la politique à une clé via firewall_policy_id, ou faites-en le défaut de l’espace de travail, et chaque exécution que cette clé pilote est désormais bornée. Vous pouvez scoper le plafond plus serré que « chaque outil ». Restreignez le glob de nom d’outil de sorte que seule une famille coûteuse d’appels compte vers le disjoncteur — par ex. cap_cost sur *.search pour borner le déploiement de recherche web tout en laissant les outils locaux bon marché non comptabilisés.
Empilez un palier d’avertissement moins cher avec les priorités. Une règle audit à plafond plus bas et de priorité plus haute (numéro plus bas) vous laisse observer une exécution approcher de son budget dans le flux d’événements avant que la règle cap_cost appliquante ne se déclenche. La première correspondance gagne, donc ordonnez l’observateur en premier.

​
3. Où elle se déclenche — et où elle ne peut pas

cap_cost n’a de sens qu’avant qu’un appel ne soit dispatché — c’est l’unique point où arrêter l’appel empêche encore la dépense. Donc elle est active sur les deux surfaces de pré-dispatch et rejetée sur celles de post-dispatch :
Surfacecap_cost ?
inbound (outils annoncés)Appliquée.
mcp (dispatch tools/call)Appliquée.
response (appels émis par le modèle)Rejetée à l’enregistrement — plus rien à arrêter.
egress (destination sortante)Rejetée à l’enregistrement — plus rien à arrêter.
Une règle cap_cost épinglée à response ou egress est refusée à l’enregistrement, de sorte qu’une règle ne peut jamais s’afficher comme active tout en étant incapable de jamais refuser. Laissez le stage vide pour couvrir les deux surfaces de pré-dispatch, ou épinglez-le à inbound / mcp.
cap_cost_cents est requis et non négatif pour une règle cap_cost. La console et l’API rejettent une règle cap_cost sans plafond, de sorte qu’un plafond mal configuré ne peut pas laisser passer silencieusement chaque appel.

​
4. À quoi ressemble le disjoncteur quand il se déclenche

Un appel hors-budget est un deny firewall normal :
  • Sur inbound, le relais renvoie HTTP 400 avec le code d’erreur firewall_blocked. Le block se déclenche avant l’appel au modèle amont, donc il ne coûte aucun token de modèle, et il est marqué skip-retry — ré-exécuter le même appel ne ferait que déclencher à nouveau le disjoncteur.
  • Sur mcp, il revient comme une erreur d’outil de sorte que le modèle voit le rejet et peut s’arrêter ou demander à l’utilisateur, plutôt que de planter.
La raison du deny nomme les chiffres, par ex. cap_cost: estimated run cost $5.40 exceeds cap $5.00, de sorte qu’un opérateur lisant le flux d’événements voit exactement pourquoi le disjoncteur s’est déclenché.
Les événements ne portent jamais un cap_cost littéral. Vous rédigez le verdict comme cap_cost, mais le moteur le résout en un allow ou deny concret avant que l’événement ne soit enregistré. Le flux montre l’allow/deny que l’agent a réellement vu — le plafond de coût d’exécution est la raison, pas le label du verdict. Cela reflète la façon dont les verdicts se résolvent.

​
5. Le déployer en toute sécurité

Parce qu’un disjoncteur déclenché arrête durement une exécution, validez-le avant d’appliquer. Activez le mode shadow sur la politique : la règle cap_cost évalue quand même et un deny potentiel est rétrogradé en audit, préfixé [shadow] would …. Surveillez le flux d’événements pour confirmer que le plafond se déclenche là où vous attendez — et seulement là où vous attendez — puis désactivez le mode shadow pour commencer à appliquer. Vous pouvez aussi exécuter une politique en dry-run contre un appel d’échantillon dans l’onglet Test (un sandbox Developer+) pour voir le verdict résolu et la règle correspondante avant que quoi que ce soit n’en dépende.

​
6. Comment elle s’intègre au reste du firewall

cap_cost est un verdict parmi six. Il s’associe naturellement aux autres contrôles de la même politique :

Verdicts

L’ensemble complet — allow, audit, deny, sanitize, pending_approval, et comment cap_cost se résout.

Bloquer les outils dangereux

Refuser le shell destructeur, les suppressions et autres appels à haut risque purement et simplement.

Référence des règles

Le langage de correspondance complet — globs, clauses d’arguments, séquences.

Détection d'anomalies

Pics de coût signalés contre une baseline heure-de-la-semaine apprise.
Un plafond de coût d’exécution est un filet de sécurité statique et déterministe ; le firewall apprend aussi la forme normale de coût de chaque espace de travail et signale les pics contre une baseline heure-de-la-semaine sur 14 jours sur un flux d’anomalies lisible par un Member. Utilisez cap_cost pour l’arrêt dur, les anomalies pour le signal précoce.
Les limites de quota sur la clé elle-même (credit_limit_usd) bornent la dépense totale à travers toutes les exécutions ; cap_cost borne une seule exécution. Elles se composent — une boucle emballée déclenche le disjoncteur par exécution bien avant de pouvoir épuiser le crédit à vie de la clé. Voir portée : clés, politiques, espaces de travail.

​
Où aller ensuite

Créer et attacher une politique

Créez une politique, choisissez un verdict par défaut, liez-la à une clé.

Mode shadow

Mesurez un plafond avant qu’il ne change le trafic.
Pour les menaces d’agent emballé qu’un plafond de dépense couvre, voir agence excessive et appels d’outils dangereux.