Vai al contenuto principale
Un agent di ragionamento che si blocca in un loop di retry, si dirama in mille sotto-task, o semplicemente fugge a metà del piano può spendere denaro reale prima che qualcuno se ne accorga. Il verdetto cap_cost del firewall è l’interruttore di sicurezza per questo: scrivi un tetto in centesimi per esecuzione una volta, e il gateway nega la chiamata a tool successiva nel momento in cui la spesa accumulata di un’esecuzione lo supera — prima che quella chiamata raggiunga il modello o il tool. Questo è controllo del costo degli agent AI applicato al gateway, non avvitato sul tuo loop di agent. Come ogni verdetto del firewall, una regola cap_cost vive in una policy del workspace, si collega a una chiave e ha effetto sulla chiamata successiva senza redeploy.

​
1. L’interruttore di sicurezza per la spesa per esecuzione

cap_cost è un verdetto di regola che scrivi con un campo extra — cap_cost_cents, il tetto di spesa dell’esecuzione in centesimi USD. Quando la regola corrisponde a una chiamata a tool, il motore confronta la spesa accumulata dell’esecuzione dell’agent con quel tetto:
  • Sotto il tetto → la chiamata viene consentita; la valutazione continua.
  • Sopra il tetto → la chiamata viene negata, con una motivazione che nomina il totale dell’esecuzione rispetto al tetto. Quello è l’esito terminale, da interruttore di sicurezza — l’esecuzione non può emettere un’altra chiamata governata fino a un’esecuzione fresca.
Il tetto è legato all’esecuzione dell’agent, non a una singola richiesta. Una lunga esecuzione che ha già bruciato la maggior parte del suo budget viene negata sulla sua prossima chiamata anche quando quell’unica chiamata è economica — l’interruttore scatta sul totale corrente, non sul costo marginale.
Scope sull’esecuzione, con un fallback per richiesta. Quando la richiesta porta un id di esecuzione dell’agent, il tetto si applica alla spesa accumulata dell’esecuzione. Una chiamata senza associazione a un’esecuzione (es. un nudo dispatch MCP senza sessione inoltrata) ricade invece su un confronto per richiesta. In ogni caso, l’interruttore scatta prima che la chiamata fuori budget venga dispatchata.

​
2. Un esempio concreto

Limita qualsiasi esecuzione su una chiave a $5.00 di spesa accumulata. Una singola regola wildcard lo fa — cap_cost_cents è 500 (centesimi): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Scrivila nell’editor delle regole della console su una policy che hai creato (vedi Crea e collega una policy). Scrivere una regola è un’azione Developer+. Collega la policy a una chiave tramite firewall_policy_id, o rendila il default del workspace, e ogni esecuzione che quella chiave guida è ora limitata. Puoi dare scope al tetto più stretto di “ogni tool”. Restringi il glob sul nome del tool così solo una famiglia costosa di chiamate conta verso l’interruttore — es. cap_cost su *.search per limitare il fan-out della ricerca web lasciando non misurati i tool locali economici.
Impila un livello di avviso più economico con le priorità. Una regola audit con tetto più basso a una priorità più alta (numero più basso) ti permette di osservare un’esecuzione avvicinarsi al suo budget nel feed degli eventi prima che la regola cap_cost applicativa scatti. Vince il primo match, quindi ordina l’osservatore per primo.

​
3. Dove scatta — e dove non può

cap_cost ha senso solo prima che una chiamata venga dispatchata — quello è l’unico punto dove fermare la chiamata previene ancora la spesa. Quindi è attivo sulle due superfici pre-dispatch e rifiutato su quelle post-dispatch:
Superficiecap_cost?
inbound (tool pubblicizzati)Applicato.
mcp (dispatch tools/call)Applicato.
response (chiamate emesse dal modello)Rifiutato al salvataggio — non c’è più nulla da fermare.
egress (destinazione in uscita)Rifiutato al salvataggio — non c’è più nulla da fermare.
Una regola cap_cost fissata a response o egress viene rifiutata al momento del salvataggio, così una regola non può mai apparire come attiva pur essendo incapace di negare. Lascia lo stage vuoto per coprire entrambe le superfici pre-dispatch, o fissala a inbound / mcp.
cap_cost_cents è obbligatorio e non negativo per una regola cap_cost. La console e l’API rifiutano una regola cap_cost senza tetto, così un tetto mal configurato non può silenziosamente lasciar passare ogni chiamata.

​
4. Com’è fatto l’interruttore quando scatta

Una chiamata fuori budget è un normale deny del firewall:
  • Su inbound, il relay restituisce HTTP 400 con codice di errore firewall_blocked. Il block scatta prima della chiamata al modello upstream, quindi non costa token del modello, ed è marcato skip-retry — rieseguire la stessa chiamata farebbe solo scattare di nuovo l’interruttore.
  • Su mcp, torna come un errore di tool così il modello vede il rifiuto e può fermarsi o chiedere all’utente, anziché andare in crash.
La motivazione del deny nomina le cifre, es. cap_cost: estimated run cost $5.40 exceeds cap $5.00, così un operatore che legge il feed degli eventi vede esattamente perché l’interruttore è scattato.
Gli eventi non portano mai un cap_cost letterale. Scrivi il verdetto come cap_cost, ma il motore lo risolve in un concreto allow o deny prima che l’evento sia registrato. Il feed mostra l’allow/deny che l’agent ha effettivamente visto — il tetto di costo dell’esecuzione è la motivazione, non l’etichetta del verdetto. Questo rispecchia come si risolvono i verdetti.

​
5. Fai il rollout in sicurezza

Poiché un interruttore scattato ferma nettamente un’esecuzione, validalo prima di applicarlo. Attiva la shadow mode sulla policy: la regola cap_cost valuta comunque e un would-be deny viene declassato a audit, prefissato [shadow] would …. Osserva il feed degli eventi per confermare che il tetto scatti dove ti aspetti — e solo dove ti aspetti — poi disattiva la shadow mode per iniziare ad applicare. Puoi anche eseguire un dry-run di una policy contro una chiamata di esempio nella scheda Test (una sandbox Developer+) per vedere il verdetto risolto e la regola corrispondente prima che qualcosa ci faccia affidamento.

​
6. Come si inserisce nel resto del firewall

cap_cost è uno tra sei verdetti. Si abbina naturalmente agli altri controlli sulla stessa policy:

Verdetti

L’insieme completo — allow, audit, deny, sanitize, pending_approval, e come cap_cost si risolve.

Blocca i tool pericolosi

Nega del tutto shell distruttiva, delete e altre chiamate ad alto rischio.

Riferimento delle regole

Il linguaggio di matching completo — glob, clausole sugli argomenti, sequenze.

Rilevamento di anomalie

Picchi di costo segnalati rispetto a una baseline ora-della-settimana appresa.
Un tetto di costo dell’esecuzione è un backstop statico e deterministico; il firewall apprende anche la forma normale del costo di ogni workspace e segnala i picchi rispetto a una baseline ora-della-settimana di 14 giorni su un feed delle anomalie leggibile dai Member. Usa cap_cost per lo stop netto, le anomalie per il segnale precoce.
I limiti di quota sulla chiave stessa (credit_limit_usd) limitano la spesa totale su tutte le esecuzioni; cap_cost limita una singola esecuzione. Si compongono — un loop incontrollato fa scattare l’interruttore per esecuzione molto prima di poter esaurire il credito a vita della chiave. Vedi scope: chiavi, policy, workspace.

​
Dove andare dopo

Crea e collega una policy

Crea una policy, scegli un verdetto di default, legala a una chiave.

Shadow mode

Misura un tetto prima che modifichi il traffico.
Per le minacce da agent incontrollato che un tetto di spesa fa da backstop, vedi agenzia eccessiva e chiamate a tool pericolose.