Frena el gasto de tu agente de IA antes de que un bucle lo desborde

Antes de que el agente entre en producción, dale un presupuesto que pueda detenerse a sí mismo. Un agente en producción puede agotar el presupuesto de la API antes de que nadie lo note, y la brecha habitual es una clave compartida, un proyecto compartido, un techo compartido y nadie que demuestre que el frenado funciona.

Para un equipo pequeño, el frenado del gasto es poco glamoroso: un proyecto y una clave separados, alertas, un tope duro y un simulacro. Un panel muestra el número; el ritual hace que el número se detenga.

El tope detiene el tráfico; el ritual lo demuestra

El 22 de julio de 2026, OpenAI añadió límites duros de gasto mensual para organizaciones y proyectos. Las alertas de OpenAI dejan el tráfico en marcha, mientras que un tope duro lo detiene. Si el agente está en un bucle, la alerta es una nota y el tope es la mecha.

Un proyecto que supera su tope mensual recibe un HTTP 429 con el código project_spend_limit_exceeded, y una organización que supera su tope recibe organization_spend_limit_exceeded. El rechazo es feo, pero es el comportamiento que protege el presupuesto cuando nadie está mirando.

El ritual controla el gasto; el panel solo lo reporta

Un panel de gasto es útil a posteriori, pero no puede detener un bucle, guiar a la persona de guardia ni demostrar que el tope sigue configurado tras un cambio de proyecto.

Construye el ritual en torno a un plan. El plan debe ser el número que el equipo espera, no el número que el equipo desea. El plan da a las alertas una referencia, al tope un objetivo y al registro una línea base. Sin un plan, los umbrales de alerta y el límite duro no tienen un significado compartido.

La lista de verificación es la prueba que puedes ejecutar en un minuto

Usa esta lista antes de que el agente entre en producción y, de nuevo, tras cualquier cambio en el presupuesto, la clave o el proyecto.

• El agente tiene su propio proyecto y su propia clave.
• Configura alertas al 60, 75 y 90 por ciento del plan, con suficiente antelación para llegar a un humano antes del tope.
• Configura el límite duro del proyecto cerca del 110 por ciento del pico esperado, sabiendo que el total registrado puede superar ligeramente el tope configurado mientras el nuevo estado se propaga.
• Configura el techo de la organización por encima del total del proyecto más una reserva.
• Mantén un registro de política que indique al responsable, el plan, los topes y la fecha del último simulacro.
• Trata los errores 429 de límite de gasto como señales de parada, no como fallos para reintentar.

Una clave compartida expone toda la cuenta. Si el agente se comporta mal, el equipo puede revocar esa clave en lugar de detener cada herramienta que usa la misma cuenta. Un proyecto separado impide que el techo del agente se esconda dentro de un presupuesto compartido, y el techo de la organización necesita margen para el resto de la cuenta.

El simulacro es la prueba que puedes mostrar

Un tope puede cambiarse por accidente, una clave puede copiarse y un proyecto puede fusionarse. El simulacro es la prueba programada que demuestra que el frenado sigue funcionando. Es una reunión con el presupuesto. Detecta un control roto antes de que un bucle real lo aproveche.

Ejecútalo según un calendario, no solo cuando el gasto se vea extraño. El resultado esperado es el fallo de límite de gasto que produce el tope. El responsable registra el resultado, la fecha y la próxima fecha de revisión en el registro de política. Si la respuesta no es el fallo de límite de gasto esperado, el agente se pausa hasta que el control se corrija.

La prueba no necesita gastar mucho dinero real. Puede ser una ejecución en seco contra una clave de staging, o una revisión de la última respuesta que alcanzó el límite. El responsable escribe qué pasó, qué se esperaba y qué cambió. Si el control se modificó sin una nota, trátalo como roto hasta que la nota exista. La fecha y el responsable son la prueba.