El patrón de inferencia descontrolada que la gestión de gastos realmente detiene
Hemos implementado agentes que consumieron un presupuesto de inferencia de $200 al día y se dispararon a $8,000 durante la noche. No porque el modelo cambió o el tráfico se triplicó, sino porque un bucle de llamadas de herramientas se quedó atrapado reincrustando vectores, o una tormenta de reintentos golpeó cuando una API externa se degradó, o un pipeline RAG comenzó a obtener los mismos documentos ocho veces por sesión. Los tiempos de espera por solicitud y los límites de velocidad no lo detectan. Una alerta suave al 80% de gasto no lo detiene. Para cuando te despiertas al buscapersonas, ya estás sangrando.
La gestión de gastos de Vercel en planes Enterprise Flexible Commitment es la primera parada estricta a nivel de infraestructura. No es una advertencia. Es un cortacircuitos. Cuando tu proyecto alcanza el límite, Vercel dispara un webhook, y tu inferencia se detiene hasta que lo manejes. Esto fuerza una decisión de diseño que hemos estado tomando ad-hoc en el código de la aplicación: ¿diseñas alrededor del límite, o construyes agentes que se degraden correctamente cuando se dispara?
Dos caminos: diseñar alrededor del límite, o degradarse bajo él
Camino A: Limitación preventiva. Posees un contador de presupuesto en el código de la aplicación: rastrear tokens por sesión, semáforo de llamadas de herramientas, rechazar inferencia si el presupuesto de tokens para este usuario cae por debajo de un umbral. Duplicas el estado que la plataforma ya posee. Distribuyes esta lógica en cada implementación, cada región, cada trabajador de cola. Cuando la lógica del límite cambia, redeploy.
Camino B: Dejar que la plataforma lo aplique, capturar el webhook, degradarse. Vercel aplica el límite estricto. Tu controlador de webhook escribe una bandera de característica (agent_mode=degraded) en Redis o Postgres. Tu middleware de agente verifica esa bandera en cada llamada LLM e invocación de herramienta. Cuando está degradado, el agente devuelve respuestas en caché, usa modelos más baratos, o omite herramientas no críticas. Reanudas cuando el webhook te dice que el presupuesto se ha restablecido.
El camino A es la analogía del límite salarial de la liga deportiva mal aplicada: restringir la alineación para evitar alcanzar el límite completamente. El camino B es el correcto: un límite de alineación estricto fuerza una estrategia de sustitución, no evitar la alineación. El camino B también se envía más rápido. Un controlador de webhook y una bandera de característica vence a un contador de presupuesto distribuido en toda tu pila. Estás a 1 implementación de activarlo; el camino A son 5.
El patrón webhook-a-pausa, concretamente
El webhook de gasto de Vercel lleva el ID del proyecto, el porcentaje de umbral y una marca de tiempo. Tu controlador escribe una bandera en Redis con un latido TTL de 60 segundos. Esa bandera se convierte en parte de tu middleware de agente.
En cada llamada LLM e invocación de herramienta, verifica la bandera. Si está degradado, devuelve un 503 con Retry-After en lugar de llamar al modelo, o devuelve una respuesta en caché si tienes una. Usa claves de idempotencia para que las llamadas de herramientas en vuelo no se carguen dos veces al reanudar. Cualquier solicitud que llegue durante la ventana de pausa va a una cola de letras muertas; cuando se dispara el webhook de reanudación (o reanudas manualmente), reproduce esas solicitudes en orden.
El patrón se ve así en pseudocódigo:
if redis.get("agent_mode") == "degraded" { return cached_response_or_503_with_retry_after() } else { call_model_and_tools() }
Eso es todo. El trabajo real es decidir qué significa "degradado" para tu agente.
El enrutamiento de respaldo cambia cuando el límite es real
Los respaldos basados en latencia se enrutan por velocidad. Los respaldos basados en límites de presupuesto se enrutan por costo y valor. Clasifica tu grupo de modelos: GPT-class primario, Haiku o Qwen para degradado, modo solo en caché si estás en emergencia, rechazo estricto si todo lo demás falla.
Más importante aún, enruta por valor de solicitud, no por orden de solicitud. Los flujos de clientes pagadores mantienen presupuesto. El enriquecimiento de fondo, la reordenación y las llamadas de herramientas especulativas se descartan primero. La recuperación RAG se mantiene; la reordenación se descarta. Bucle de agente limitado a 2 iteraciones en lugar de 5. Usa las reglas de enrutamiento de Vercel AI Gateway como la superficie de aplicación para tu nivel degradado: es más barato que la lógica en tu controlador y auditable en un lugar.
La decisión real: ¿qué herramientas sobreviven? Costo por acción exitosa, no costo por token, decide qué herramientas obtienen presupuesto. Una herramienta que cuesta $0.50 por llamada pero tiene éxito el 40% de las veces es $1.25 por acción exitosa. Una herramienta que cuesta $0.10 por llamada pero tiene éxito el 90% de las veces es $0.11. En modo degradado, la segunda herramienta sobrevive primero.
Lo que el límite expone que no estabas midiendo
El límite es una función forzada para la observabilidad. Ahora necesitas atribución de costo por agente, por inquilino, por herramienta antes de que se dispare el límite. Correlaciona el ID de correlación de Vercel Connect con el delta de gasto por traza. El análisis posterior "qué agente quemó el presupuesto" requiere granularidad de caché-razón-registro, no solo si hubo un acierto de caché, sino por qué falló.
Construye paneles antes de activar el límite en prod: tokens p95 por sesión, fan-out de llamadas de herramientas por turno, costo por acción exitosa por agente. Estos son tus indicadores principales. Cuando alcances el 75% del límite, verás qué agente o inquilino lo está quemando, y sabrás si degradar o escalar el presupuesto.
Un despliegue de 90 minutos que realmente enviaríamos
Paso 1: Establece el límite 20% por encima de tu gasto diario p99 actual. Apunta el webhook a un punto final de ensayo primero. No estás intentando dispararlo aún; estás probando la ruta del controlador.
Paso 2: Implementa la bandera de modo degradado en Redis con un latido TTL de 60 segundos. Escribe un controlador simple que capture el webhook, cambie la bandera a "degraded", y registre el umbral y la marca de tiempo.
Paso 3: Conecta dos niveles de enrutamiento en AI Gateway: primario (modelos completos) y degradado (modelos más baratos). Prueba que tu middleware de agente se enruta correctamente según la bandera de Redis.
Paso 4: Prueba de caos cambiando manualmente la bandera durante la carga. Ejecuta tus agentes y mira cómo se degradan. Verifica que las claves de idempotencia funcionen, verifica que la cola de letras muertas se llene, verifica que puedas reanudar sin cargos duplicados.
Paso 5: Define criterios de reanudación. Basado en tiempo (60 segundos después del webhook) es lo más simple. El siguiente período de facturación es más seguro. Registra lo que necesitas para que el próximo incidente sea un triaje de 10 minutos, no una sala de guerra a las 2am.
Activa el límite en ensayo este sprint, envía el controlador de webhook antes de ajustar el número, y si quieres un segundo par de ojos en el enrutamiento de modo degradado, consulta nuestra guía sobre registros de razón de caché para los patrones de observabilidad que realmente exponen la atribución de costo, luego contáctanos en /contact us.