Saltar para o conteúdo principal
Um agente de raciocínio que fica preso num loop de retry, se ramifica em mil subtarefas, ou simplesmente foge no meio de um plano pode gastar dinheiro real antes que alguém perceba. O veredito de firewall cap_cost é o disjuntor para isso: você cria um teto em centavos por run uma vez, e o gateway nega a próxima chamada de ferramenta no momento em que o gasto acumulado de uma run o cruza — antes de essa chamada chegar ao modelo ou à ferramenta. Este é controle de custo de agente de IA aplicado no gateway, não parafusado no seu loop de agente. Como cada veredito de firewall, uma regra cap_cost vive numa política de workspace, vincula-se a uma chave, e entra em vigor na próxima chamada sem redeploy.

​
1. O disjuntor de gasto por run

cap_cost é um veredito de regra que você cria com um campo extra — cap_cost_cents, o teto de gasto da run em centavos de USD. Quando a regra corresponde a uma chamada de ferramenta, o motor compara o gasto acumulado da run de agente contra esse limite:
  • Abaixo do limite → a chamada é permitida; a avaliação continua.
  • Acima do limite → a chamada é negada, com um motivo nomeando o total da run versus o limite. Esse é o resultado terminal de disjuntor — a run não pode emitir outra chamada governada até uma run nova.
O limite é chaveado à run de agente, não a uma única requisição. Uma run longa que já queimou a maior parte de seu orçamento é negada em sua próxima chamada mesmo quando essa única chamada é barata — o disjuntor dispara no total em andamento, não no custo marginal.
Escopo de run, com um fallback por requisição. Quando a requisição carrega um id de run de agente, o teto se aplica ao gasto acumulado da run. Uma chamada sem associação de run (ex.: um dispatch MCP puro sem sessão encaminhada) cai para uma comparação por requisição em vez disso. De qualquer forma, o disjuntor dispara antes de a chamada acima do orçamento ser despachada.

​
2. Um exemplo concreto

Limite qualquer run numa chave a $5,00 de gasto acumulado. Uma única regra wildcard faz isso — cap_cost_cents é 500 (centavos): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Crie-a no editor de regras do console numa política que você criou (veja Criar e vincular uma política). Escrever uma regra é uma ação Developer+. Vincule a política a uma chave via firewall_policy_id, ou torne-a o padrão do workspace, e cada run que essa chave conduz agora está limitada. Você pode dar escopo ao limite mais apertado que “cada ferramenta”. Estreite o glob de nome de ferramenta para que apenas uma família cara de chamadas conte para o disjuntor — ex.: cap_cost em *.search para limitar a ramificação de busca na web enquanto deixa ferramentas locais baratas sem medição.
Empilhe um nível de aviso mais barato com prioridades. Uma regra audit de limite menor numa prioridade maior (número menor) deixa você observar uma run se aproximar de seu orçamento no feed de events antes que a regra cap_cost de enforcement dispare. A primeira correspondência vence, então ordene o observador primeiro.

​
3. Onde dispara — e onde não pode

cap_cost só faz sentido antes de uma chamada ser despachada — esse é o único ponto onde parar a chamada ainda previne o gasto. Então ele está ativo nas duas superfícies pré-dispatch e rejeitado nas pós-dispatch:
Superfíciecap_cost?
inbound (ferramentas anunciadas)Aplicado.
mcp (dispatch de tools/call)Aplicado.
response (chamadas emitidas pelo modelo)Rejeitado ao salvar — nada mais a parar.
egress (destino outbound)Rejeitado ao salvar — nada mais a parar.
Uma regra cap_cost fixada a response ou egress é recusada no momento de salvar, então uma regra nunca pode aparecer como ativa e ainda assim ser incapaz de negar. Deixe o stage vazio para cobrir ambas as superfícies pré-dispatch, ou fixe-a em inbound / mcp.
cap_cost_cents é obrigatório e não-negativo para uma regra cap_cost. O console e a API rejeitam uma regra cap_cost sem limite, então um teto mal configurado não pode silenciosamente deixar cada chamada passar.

​
4. Como é o disjuntor quando dispara

Uma chamada acima do orçamento é um deny de firewall normal:
  • No inbound, o relay retorna HTTP 400 com o código de erro firewall_blocked. O block dispara antes da chamada ao modelo upstream, então não custa tokens de modelo, e é marcado como skip-retry — reexecutar a mesma chamada apenas dispararia o disjuntor de novo.
  • No mcp, ela volta como um erro de ferramenta para que o modelo veja a rejeição e possa parar ou perguntar ao usuário, em vez de quebrar.
O motivo do deny nomeia os valores, ex.: cap_cost: estimated run cost $5.40 exceeds cap $5.00, então um operador lendo o feed de events vê exatamente por que o disjuntor disparou.
Os events nunca carregam um cap_cost literal. Você cria o veredito como cap_cost, mas o motor o resolve para um allow ou deny concreto antes de o evento ser registrado. O feed mostra o allow/deny que o agente de fato viu — o teto de custo de run é o motivo, não o label do veredito. Isso espelha como os vereditos resolvem.

​
5. Faça o rollout com segurança

Porque um disjuntor disparado para uma run rigidamente, valide-o antes de aplicar. Ligue o shadow mode na política: a regra cap_cost ainda avalia e um deny potencial é rebaixado para audit, prefixado [shadow] would …. Observe o feed de events para confirmar que o limite dispara onde você espera — e apenas onde você espera — depois desligue o shadow mode para começar a aplicar. Você também pode fazer dry-run de uma política contra uma chamada de amostra na aba Test (um sandbox Developer+) para ver o veredito resolvido e a regra correspondente antes que qualquer coisa dependa dela.

​
6. Como se encaixa no resto do firewall

cap_cost é um veredito entre seis. Ele se combina naturalmente com os outros controles na mesma política:

Vereditos

O conjunto completo — allow, audit, deny, sanitize, pending_approval, e como o cap_cost resolve.

Bloquear ferramentas perigosas

Negue shell destrutivo, deletes e outras chamadas de alto risco totalmente.

Referência de regras

A linguagem de correspondência completa — globs, cláusulas de argumento, sequências.

Detecção de anomalias

Picos de custo sinalizados contra um baseline de hora-da-semana aprendido.
Um teto de custo de run é um backstop estático e determinístico; o firewall também aprende a forma normal de custo de cada workspace e sinaliza picos contra um baseline de hora-da-semana de 14 dias num feed de anomalias legível por Member. Use cap_cost para a parada rígida, anomalias para o sinal antecipado.
Limites de cota na própria chave (credit_limit_usd) limitam o gasto total através de todas as runs; cap_cost limita uma única run. Eles se compõem — um loop descontrolado dispara o disjuntor por run muito antes de poder esgotar o crédito vitalício da chave. Veja escopo: chaves, políticas, workspaces.

​
Para onde ir a seguir

Criar e vincular uma política

Crie uma política, escolha um veredito padrão, vincule-a a uma chave.

Shadow mode

Meça um limite antes de ele mudar o tráfego.
Para as ameaças de agente descontrolado que um teto de gasto faz de backstop, veja agência excessiva e chamadas de ferramenta perigosas.