FinOps de tokens en agentes: la cuenta que sorprende
Actualizado: 2026-05-03
El patrón es predecible. Un equipo despliega el primer agente a producción, la factura del primer mes aparece y es el doble o el triple de lo estimado. La reacción suele ser pánico seguido de optimización agresiva, a veces sacrificando calidad. Existe una tercera vía: FinOps disciplinado aplicado a agentes, con las palancas ordenadas por ratio coste/riesgo.
Puntos clave
- El cacheo de prompts corta el coste de tokens de entrada un 50-90 % con cero impacto en calidad.
- Un router de modelos ahorra entre el 30 y el 70 % asignando cada tarea al modelo adecuado.
- El control de contexto evita el crecimiento cuadrático del coste por turno.
- El batching para tareas no interactivas ofrece descuentos del 50 % en Anthropic y OpenAI.
- Sin telemetría por tenant y tarea, ninguna de las otras palancas se puede calibrar.
Primera palanca: cacheo agresivo
La victoria más fácil y con cero impacto en calidad es el cacheo. Claude prompt caching[1], OpenAI prompt caching[2] y equivalentes reducen el coste de tokens de entrada un 50-90 % cuando hay repetición estructural. El patrón que más aplica: system prompts largos con instrucciones, few-shots o contexto de herramientas estables entre llamadas.
Implementación típica: todo lo que no cambia entre turnos se marca como cacheable; lo que cambia (la consulta del usuario, estado dinámico) queda fuera. El ahorro es inmediato y no requiere cambios en la lógica del agente.
Segunda palanca: router de modelos por dificultad
No toda tarea necesita el modelo más caro. Un router que clasifica la consulta y la envía al modelo adecuado ahorra entre el 30 % y el 70 % del gasto según la distribución de tareas. La clasificación puede ser:
- Simple: reglas por palabra clave.
- Sofisticada: modelo pequeño como clasificador (Haiku 4.5 como router).
El stack habitual combina Haiku 4.5 o Gemini Flash para tareas ligeras, Sonnet 4.6 para la mayoría del tráfico, y Opus 4.7 solo para las consultas que el router marca como complejas. La clave es medir la precisión del router: si clasifica mal y manda al modelo caro cuando no hace falta, el ahorro se evapora.
Tercera palanca: control de contexto
Los agentes tienden a acumular contexto. Sin control, una conversación de cinco turnos pasa a doce mil tokens; diez turnos, veinticinco mil. El coste por turno crece cuadráticamente porque se factura la acumulación en cada llamada.
Las técnicas que funcionan:
- Resumen periódico: cada N turnos, el historial se comprime a un resumen.
- Ventana deslizante: solo los últimos K turnos completos.
- Selección retrieval: al inicio de cada turno, recuperar solo los fragmentos relevantes.
Combinadas, bajan el gasto por conversación un 40-60 % sin degradar la percepción del usuario si están bien calibradas.
Cuarta palanca: batching cuando se puede
Las tareas no interactivas (procesamiento nocturno, resumen de reportes, clasificación masiva) aceptan batching. Anthropic Batch API[3] y OpenAI Batch API[4] ofrecen descuentos del 50 % a cambio de latencia tolerable (horas en lugar de segundos). Para flujos donde la respuesta inmediata no es necesaria, no usar batch es dejar dinero sobre la mesa.
Quinta palanca: telemetría que revela el gasto real
La condición necesaria para optimizar es ver dónde se va el dinero. El mínimo son métricas por:
- Tenant y tarea.
- Modelo y tipo de llamada (cacheable o no).
- Tokens de entrada y salida.
Con ese nivel se identifican fácilmente los tenants que consumen 10× la media, las tareas mal acotadas y los flujos rotos que hacen llamadas en bucle. Herramientas que incluyen esta telemetría: Helicone[5], Langfuse[6], Portkey[7], además de los dashboards nativos de los proveedores.
Lo que no funciona
Tres antipatrones frecuentes:
- Cambiar de proveedor por diferencias del 10 % de precio sin cambiar nada más: el tiempo de ingeniería supera el ahorro.
- Bajar el modelo sin evaluar: cae la calidad, los clientes reportan, se vuelve atrás con pérdida neta.
- “Negociar con el proveedor” sin volumen real: los descuentos por volumen empiezan donde está el 1 % de los clientes; debajo no hay palanca.
Conclusión
El FinOps de agentes es un área madura con palancas claras. Aplicadas en orden — cacheo, routing, control de contexto, batching, telemetría — reducen el coste a la mitad o a un tercio sin impacto en calidad percibida. Lo que no funciona es reaccionar a la factura con pánico y recortar en cosas visibles; lo que funciona es invertir unos días en instrumentación y decisiones de arquitectura que se amortizan el primer mes.
