Saltar al contenido principal
Un agente de razonamiento que se atasca en un bucle de reintento, despliega mil subtareas, o simplemente se descontrola a mitad de plan puede gastar dinero real antes de que alguien lo note. El veredicto cap_cost del firewall es el interruptor de circuito para eso: autoras un techo en centavos por ejecución una vez, y el gateway deniega la siguiente llamada a herramienta en el momento en que el gasto acumulado de una ejecución lo cruza — antes de que esa llamada llegue al modelo o a la herramienta. Esto es control de coste de agentes de IA aplicado en el gateway, no atornillado a tu bucle de agente. Como cada veredicto del firewall, una regla cap_cost vive en una política de espacio de trabajo, se adjunta a una clave, y surte efecto en la siguiente llamada sin redespliegue.

​
1. El interruptor de circuito de gasto por ejecución

cap_cost es un veredicto de regla que autoras con un campo extra — cap_cost_cents, el techo de gasto de la ejecución en centavos de USD. Cuando la regla coincide con una llamada a herramienta, el motor compara el gasto acumulado de la ejecución del agente contra ese tope:
  • Bajo el tope → la llamada se permite; la evaluación continúa.
  • Sobre el tope → la llamada se deniega, con una razón que nombra el total de la ejecución frente al tope. Ese es el resultado terminal, de interruptor de circuito — la ejecución no puede emitir otra llamada gobernada hasta una ejecución nueva.
El tope tiene clave en la ejecución del agente, no en una sola solicitud. Una ejecución larga que ya ha quemado la mayor parte de su presupuesto se deniega en su siguiente llamada incluso cuando esa única llamada es barata — el interruptor se dispara sobre el total acumulado, no sobre el coste marginal.
Alcance de ejecución, con un fallback por solicitud. Cuando la solicitud lleva un id de ejecución de agente, el techo aplica al gasto acumulado de la ejecución. Una llamada sin asociación de ejecución (p. ej. un despacho MCP pelado sin sesión reenviada) cae a una comparación por solicitud en su lugar. De cualquier forma, el interruptor se dispara antes de que la llamada sobre presupuesto se despache.

​
2. Un ejemplo concreto

Limita cualquier ejecución en una clave a $5.00 de gasto acumulado. Una sola regla comodín lo logra — cap_cost_cents es 500 (centavos): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Autórala en el editor de reglas de la consola sobre una política que hayas creado (ver Crear y adjuntar una política). Escribir una regla es una acción Developer+. Adjunta la política a una clave vía firewall_policy_id, o hazla el valor por defecto del espacio de trabajo, y cada ejecución que esa clave conduce queda ahora acotada. Puedes acotar el tope más estrechamente que “cada herramienta”. Estrecha el glob de nombre de herramienta para que solo una familia costosa de llamadas cuente hacia el interruptor — p. ej. cap_cost sobre *.search para acotar el despliegue de búsqueda web mientras dejas las herramientas locales baratas sin medir.
Apila un nivel de advertencia más barato con prioridades. Una regla audit de tope más bajo en una prioridad más alta (número más bajo) te deja observar una ejecución acercarse a su presupuesto en el feed de eventos antes de que la regla cap_cost de aplicación se dispare. Gana la primera coincidencia, así que ordena el observador primero.

​
3. Dónde se dispara — y dónde no puede

cap_cost solo tiene sentido antes de que una llamada se despache — ese es el único punto donde detener la llamada aún previene el gasto. Así que está en vivo en las dos superficies previas al despacho y se rechaza en las posteriores al despacho:
Superficie¿cap_cost?
inbound (herramientas anunciadas)Aplicado.
mcp (despacho tools/call)Aplicado.
response (llamadas emitidas por el modelo)Rechazado al guardar — nada que detener.
egress (destino saliente)Rechazado al guardar — nada que detener.
Una regla cap_cost fijada a response o egress se rechaza en tiempo de guardado, así que una regla nunca puede mostrarse como en vivo y aun así ser incapaz de denegar. Deja la etapa vacía para cubrir ambas superficies previas al despacho, o fíjala a inbound / mcp.
cap_cost_cents es requerido y no negativo para una regla cap_cost. La consola y la API rechazan una regla cap_cost sin tope, así que un techo mal configurado no puede dejar pasar silenciosamente cada llamada.

​
4. Cómo se ve el interruptor cuando se dispara

Una llamada sobre presupuesto es un deny normal del firewall:
  • En inbound, el relay devuelve HTTP 400 con el código de error firewall_blocked. El bloqueo se dispara antes de la llamada al modelo upstream, así que no cuesta tokens de modelo, y se marca como skip-retry — reejecutar la misma llamada simplemente volvería a disparar el interruptor.
  • En mcp, vuelve como un error de herramienta para que el modelo vea el rechazo y pueda detenerse o preguntar al usuario, en vez de fallar.
La razón del deny nombra las cifras, p. ej. cap_cost: estimated run cost $5.40 exceeds cap $5.00, así que un operador leyendo el feed de eventos ve exactamente por qué se disparó el interruptor.
Los eventos nunca llevan un cap_cost literal. Autoras el veredicto como cap_cost, pero el motor lo resuelve a un allow o deny concreto antes de que el evento se registre. El feed muestra el allow/deny que el agente realmente vio — el techo de coste de ejecución es la razón, no la etiqueta de veredicto. Esto refleja cómo se resuelven los veredictos.

​
5. Lánzalo de forma segura

Como un interruptor disparado detiene en seco una ejecución, valídalo antes de aplicar. Activa el modo shadow en la política: la regla cap_cost aún evalúa y un deny potencial se degrada a audit, prefijado con [shadow] would …. Observa el feed de eventos para confirmar que el tope se dispara donde esperas — y solo donde esperas — luego apaga el modo shadow para empezar a aplicar. También puedes ejecutar en seco una política contra una llamada de muestra en la pestaña Test (un sandbox Developer+) para ver el veredicto resuelto y la regla coincidente antes de que algo dependa de ella.

​
6. Cómo encaja en el resto del firewall

cap_cost es un veredicto entre seis. Se combina naturalmente con los otros controles en la misma política:

Veredictos

El conjunto completo — allow, audit, deny, sanitize, pending_approval, y cómo se resuelve cap_cost.

Bloquear herramientas peligrosas

Deniega shell destructivo, borrados y otras llamadas de alto riesgo de plano.

Referencia de reglas

El lenguaje de coincidencia completo — globs, cláusulas de argumentos, secuencias.

Detección de anomalías

Picos de coste marcados contra una línea base de hora-de-la-semana aprendida.
Un techo de coste de ejecución es un respaldo estático y determinista; el firewall también aprende la forma de coste normal de cada espacio de trabajo y marca picos contra una línea base de hora-de-la-semana de 14 días en un feed de anomalías legible por Member. Usa cap_cost para la parada dura, las anomalías para la señal temprana.
Los límites de cuota en la propia clave (credit_limit_usd) acotan el gasto total a lo largo de todas las ejecuciones; cap_cost acota una sola ejecución. Se componen — un bucle descontrolado dispara el interruptor por ejecución mucho antes de que pueda agotar el crédito de por vida de la clave. Ver alcance: claves, políticas, espacios de trabajo.

​
Dónde ir a continuación

Crear y adjuntar una política

Crea una política, elige un veredicto por defecto, vincúlala a una clave.

Modo shadow

Mide un tope antes de que cambie el tráfico.
Para las amenazas de agente descontrolado que un techo de gasto respalda, ver agencia excesiva y llamadas a herramienta peligrosas.