English

Pon un límite fijo por trabajo en cada llamada de IA automatizada

Cada llamada de IA automatizada necesita un límite fijo. Un bug debe producir una factura acotada, no una ilimitada. Cuando hay una persona en el proceso, un prompt descontrolado es molesto — lo notas y lo detienes. Cuando la llamada corre en un cron, en un worker de una cola o dentro del bucle de un agente, nadie observa cada ejecución y el medidor sube en silencio toda la noche.

Por qué el gasto recurrente es el peligroso

El gasto interactivo se limita solo: hay alguien ahí sentado. El gasto automatizado no. Los tres modos de falla clásicos multiplican tu factura sin que nadie lo note:

• Un bucle que se reejecuta. Un reintento sin backoff, o un agente que sigue llamándose a sí mismo, convierte un trabajo en miles.
• Un payload que se infla. Ayer la entrada era de 2 KB; hoy alguien pegó un log de 4 MB, y cada llamada posterior se infla con él.
• Una salida que nunca termina. Sin un límite de tokens, un modelo confundido puede generar hasta el tope completo de contexto en cada llamada.

Ninguno de estos lanza un error. Simplemente cuestan dinero hasta que llega la factura.

Limita los tres ejes, luego pon una alarma en la cuenta

Pon un límite fijo en cada eje por el que un trabajo descontrolado pueda crecer, en el punto de la llamada — no en una configuración que nadie lee.

En la Messages API de Anthropic, max_tokens es un parámetro obligatorio — no puedes hacer una llamada sin declarar el tope. En Chat Completions de OpenAI, max_tokens quedó obsoleto en septiembre de 2024 en favor de max_completion_tokens, la única forma que aceptan los modelos de razonamiento de la serie o. Ponlo deliberadamente en lo que la tarea realmente necesita, no en el máximo.

Limitar los tokens acota una llamada. Limitar los elementos acota el fan-out — un trabajo que debería tocar 100 filas debe negarse a tocar 100.000. Limitar el tiempo acota una llamada colgada. Y una alarma de presupuesto es el respaldo para todo lo que olvidaste: vigila el dinero directamente.

El respaldo a nivel de cuenta

Incluso un trabajo perfectamente limitado puede sorprenderte cuando diez de ellos corren a la vez. Pon una alarma de gasto en cualquier cuenta contra la que la automatización pueda facturar. AWS Budgets, por ejemplo, te permite crear un cost budget con un objetivo mensual fijo y recibir avisos tanto del gasto actual (ya acumulado) como del forecasted (proyectado) — un patrón común es una alerta al 80% del presupuesto. Las notificaciones van a correo o a un topic de Amazon SNS. Los presupuestos se actualizan hasta tres veces al día, así que trata la alarma como un piso, no como un interruptor en tiempo real.

Movimientos avanzados

• Falla cerrado, no abierto. Cuando el conteo de elementos o el tiempo transcurrido supere el límite, lanza un error y detén el trabajo — no registres una advertencia y sigas. Una valla que puedes atravesar no es una valla.
• Agrega una action de presupuesto, no solo una notificación. AWS Budgets puede adjuntar una acción en un umbral — por ejemplo, aplicar una política de IAM restrictiva que bloquee nuevo gasto — para que el límite se haga cumplir solo en vez de esperar a que un humano lea el correo.
• Registra el límite, no solo el uso. Guarda el max_tokens, el tope de elementos y el timeout que enviaste en cada llamada. Cuando algo se vea mal, querrás ver la valla que aguantó (o la que quedó demasiado alta).
• Prueba el descontrol. Alimenta el trabajo con un payload deliberadamente enorme en staging y confirma que llega al límite y se detiene. Una valla sin probar es una esperanza.

Recursos

• Anthropic Messages API — max_tokens es obligatorio
• OpenAI — controlar la longitud de la respuesta (max_completion_tokens)
• AWS Budgets — cost budgets y alertas
• AWS Budgets — configurar budget actions