FinOps de tokens en agentes: la cuenta que sorprende
Actualizado: 2026-07-07
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. Esta idea de enrutar según la petición es la pieza central del ahorro. 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. Cubro el detalle de qué instrumentar primero en observabilidad de LLM: trazas, costes y calidad.
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 empiezan donde está el 1 % de los clientes que más gastan; por debajo de ese umbral no hay margen que negociar.
Conclusión
El FinOps de agentes es un área madura con palancas claras. Aplicadas en orden (cacheo, routing, control de contexto, batching y telemetría) reducen el coste a la mitad o a un tercio sin impacto en calidad percibida. Este mismo enfoque de instrumentar antes de recortar es el que desarrollo con más detalle en FinOps aplicado a IA: dónde se va el coste de verdad. 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.
