Problema
Los equipos tratan el gasto de modelos como una factura posterior. Ese hábito funciona mientras el uso es pequeño; falla cuando agentes, lotes y reintentos consumen capacidad continuamente y un saldo agotado puede detener un proceso.
Un loop defectuoso puede quemar en una noche el saldo previsto para una semana. A la mañana siguiente, el agente de soporte no falla por calidad del modelo, sino porque experimentación y producción compartían la misma bolsa.
Tesis
Con el prepago, el presupuesto de tokens deja de ser contabilidad y se convierte en disponibilidad. Debe gestionarse como capacidad: forecast, reserva, límites por carga y respuesta ante agotamiento.
Consecuencia: cuando el saldo puede detener un workflow, Finanzas y SRE están mirando el mismo recurso desde dos paneles distintos.
Framework
La documentación de Gemini API distingue Prepay y Postpay, incorpora recarga automática y permite limitar la recarga mensual. El control útil separa cuatro bolsas: producción, experimentación, batch y contingencia.
Cada bolsa necesita tres números: burn rate normal, pico tolerable y horas de cobertura. El coste por token ayuda a estimar; el coste por outcome permite decidir qué cargas merecen sobrevivir.
La degradación debe estar diseñada antes del límite. Un workflow puede reducir contexto, cambiar de modelo, posponer tareas o pedir intervención. Cortar todas las llamadas por igual convierte un mecanismo financiero en incidente indiscriminado.
Señal medible: horas de cobertura de inferencia al ritmo actual antes de alcanzar el umbral mínimo.
Por que importa ahora
Los agentes no consumen una cantidad fija por usuario. Planifican, llaman herramientas, reintentan y expanden contexto. Sin límites por workflow, un fallo lógico puede convertirse en incidente financiero y de disponibilidad.
La recarga automática necesita dos defensas: tope para evitar gasto sin control y alerta temprana para no descubrir el tope al alcanzarlo. Entre ambos vive la capacidad de reacción.
Anti-ejemplo
“Activamos auto-reload y listo.” Sin tope y alertas, automatiza el gasto; con un tope arbitrario, automatiza el corte.
También falla imponer una cuota única por usuario. Un analista y un agente nocturno tienen perfiles distintos; el límite debe seguir al workflow y a su prioridad.
Protocolo (3 pasos)
- Segmenta cargas. Asigna presupuesto y prioridad por caso de uso.
- Define umbrales. Alerta por burn rate, saldo y anomalía.
- Diseña degradación. Reduce contexto, modelo o frecuencia antes de parar.
Prueba el plan agotando una bolsa de staging. Si nadie sabe qué alerta llega, quién decide y cómo se recupera el servicio, todavía tienes un saldo, no capacidad gobernada.
| Bolsa | Prioridad | Acción al límite |
|---|---|---|
| producción | alta | degradación controlada |
| batch | media | posponer |
| experimento | baja | detener |
Relacionado
- Context Budgeting: ahorrar tokens sin cegar al agente
- Token-to-Outcome: el KPI que separa IA usada de IA rentable
Fuentes consultadas
Proximo paso
Calcula el burn rate por workflow y simula qué ocurre si se multiplica por cinco durante un día. Define ahora qué carga se degrada primero.