Cuando desplegamos el primer agente para un cliente de industria pesada — tarea: automatizar la elaboración de informes semanales desde cinco sistemas — el token cost total del primer mes quintuplicó la estimación inicial. No porque el agente hiciera algo mal. Sino porque no habíamos pensado bien en cuántos tokens consume cada paso del bucle cuando el historial crece, cuando una llamada a una herramienta se reintenta repetidamente, y cuando toda la conversación se añade al contexto en cada llamada. Lo que en el prototipo costaba céntimos por consulta, en producción con decenas de usuarios y miles de tareas diarias costaba un orden de magnitud más.
Este artículo no trata de precios hipotéticos. Trata de dónde fluye el dinero realmente al desplegar un agente, por qué las estimaciones habituales quedan tan lejos de la realidad, y qué conjunto de optimizaciones funciona en la práctica — desde contextos más cortos hasta routing hacia modelos más baratos y prompt caching.
Dónde nace el token cost de un agente
Los agentes son más caros que las llamadas LLM simples por una razón concreta: cada paso del bucle es una nueva llamada a la API, y en el contexto entra un historial que no deja de crecer. Compáralo con el RAG clásico: una consulta, una llamada, una respuesta. Un agente con diez pasos hace diez llamadas — y cada una lleva todo el contexto anterior.
La topología concreta de costes es la siguiente:
- System prompt — se repite en cada llamada. Si tienes un system prompt de 2 000 tokens y el agente da 8 pasos, pagas ese mismo texto ocho veces.
- Historial de conversación — cada ciclo Reason-Act-Observe añade más tokens al contexto. En tareas largas, los input tokens crecen de forma cuadrática.
- Salidas de herramientas — las respuestas de las herramientas (resultados de base de datos, respuestas de API, documentos) se insertan en el contexto y aumentan su tamaño. Un RAG retrieval amplio antes de cada paso puede duplicar los input tokens.
- Bucles de retry — si una llamada a una herramienta falla, el agente lo vuelve a intentar. Una retry rate del 10–15 % es habitual en sistemas de producción. Cada retry es otra llamada con el contexto completo.
- Output tokens — el razonamiento de los agentes (chain-of-thought, step-by-step) genera respuestas largas. Los output tokens suelen costar 3–5× más que los input.
Resultado: un agente real en producción consume entre 5 y 50× más tokens por tarea de lo que estimarías a partir del prototipo.
Ejemplos de orden de magnitud — qué significa en euros
Los precios de los modelos cambian cada 1–3 meses, por lo que ofrezco ejemplos orientativos válidos en el momento de escribir este artículo. Verifica siempre el precio actualizado directamente con el proveedor.
Los modelos frontier se mueven actualmente en un rango de ~$0,10 a ~$5 por millón de input tokens y de ~$5 a ~$30 por millón de output tokens — es decir, una diferencia de 50× entre el tier más barato y el más caro. Este es el número clave: la elección del modelo es la palanca de coste más potente, más que cualquier otra optimización.
Imagina un agente que procesa 100 tareas al día:
- Tier económico (equivalente Flash/Haiku, $0,10–0,30/1M input tokens): incluso con 50 000 tokens por tarea te mueves en órdenes de pocos euros al día. Mensualmente, unos cientos de euros.
- Tier intermedio (equivalente Sonnet, ~$3–5/1M input tokens): la misma carga puede salir a 1 000–3 000 euros al mes.
- Tier premium (equivalente Opus, ~$15+/1M input tokens): la misma carga puede ser 5–10× más cara que el tier intermedio.
Si además el sistema funciona con una retry rate del 12 %, en la práctica pagas 1,12× por cada tarea — lo que a gran volumen suma rápido.
La escalación humana es otro coste oculto: si el agente falla en el 5 % de las tareas y cada escalación a un operario humano cuesta 2–10 euros (tiempo), ese coste puede superar al token cost en sí.
Cuatro lugares donde se pueden recortar costes eficazmente
1. Acorta el contexto — de forma sistemática, no al azar
El mayor ahorro no es un modelo más barato, sino menos tokens por llamada. Pasos concretos:
- Comprime el system prompt. Cada línea superflua en el system prompt se paga cien veces al día. Audita regularmente qué es realmente necesario.
- Resume el historial de conversación. En lugar de insertar todo el historial en el contexto, deja que el agente genere un resumen tras N pasos.
LangGraphtiene un nodo de resumen integrado para esto. Se pierde algo de granularidad, pero en la mayoría de tareas no importa. - Filtra las salidas de herramientas. Si el RAG retrieval devuelve cinco documentos pero el agente solo necesita uno, pagas innecesariamente por cuatro. Configura reranking y un límite de fragmentos insertados en el contexto.
- Limita la longitud de salida. El flujo de razonamiento no siempre tiene que ser ilimitado. Para pasos estándar basta una respuesta corta; reserva el chain-of-thought detallado solo para los puntos de decisión realmente complejos.
2. Enruta hacia el modelo más barato para los pasos sencillos
No todos los pasos de un agente necesitan un modelo frontier. Distribución típica:
- Pasos de orquestación (qué hacer a continuación, qué herramienta llamar): normalmente los gestiona un modelo más barato
- Retrieval y filtrado de datos: modelo económico o incluso lógica determinista
- Síntesis final de la respuesta para el usuario: aquí vale la pena un modelo más potente
- Verificación y self-consistency check: modelo económico en bucle
LLM routing — la selección dinámica de modelo según la complejidad del paso — es una optimización sobre la que escribimos en detalle en el artículo sobre routing y cascading de LLM. En el contexto agéntico funciona el mismo principio: tienes un dispatcher que clasifica cada paso y lo envía al modelo más barato capaz de resolverlo.
3. Prompt caching — paga el system prompt una sola vez
El prompt caching es una tecnología que Anthropic, OpenAI y Google ofrecen en sus APIs. El principio: si el inicio del contexto (típicamente el system prompt o un documento estático largo) se repite entre llamadas, el proveedor lo cachea en el lado del servidor y lo factura a una fracción del precio estándar — del orden de –90 % sobre la parte cacheada.
Para un agente con un system prompt largo que corre en decenas de sesiones simultáneas, el caching es uno de los ahorros más rápidos de implementar. Lo analizamos con más detalle en el artículo sobre prompt caching y costes.
Condición: el caching funciona bien para las partes estables del prompt. Si cada llamada contiene contenido dinámico diferente al principio, la cache hit rate será baja y el ahorro mínimo.
4. Configura límites — antes del despliegue, no tras el incidente
Este es el punto que la literatura técnica menciona como nota a pie de página, pero que en la práctica es una ley: un agente sin hard limits es un riesgo financiero.
max_steps(o equivalente): número máximo de pasos del bucle antes de detenermax_tokens_per_run: presupuesto total de tokens por tareatimeout: tiempo tras el cual el agente se detiene y devuelve un resultado parcialcost_budget_per_day: a nivel de todo el sistema, monitorizado con alertas
Un agente sin límite de max_steps puede, ante una entrada inesperada o una dependencia de herramienta, quedar atrapado en un bucle y generar miles de llamadas durante la noche — con una factura de miles de euros. No es hipotético. Lo vemos en sistemas de producción y siempre es prevenible.
Agentic RAG: donde los costes escalan de forma silenciosa
El Agentic RAG — es decir, RAG donde el agente decide por sí mismo cuántas veces y qué recuperar — es entre 5 y 10× más caro que el RAG clásico. No porque sea malo, sino porque hace más trabajo.
Secuencia típica de Agentic RAG para una pregunta:
- 1.Decisión sobre qué estrategia de retrieval usar (1 llamada LLM)
- 2.Primera búsqueda (retrieval + reranking)
- 3.Evaluación de si los resultados son suficientes (1 llamada LLM)
- 4.Posible búsqueda adicional con consulta refinada (retrieval + reranking)
- 5.Síntesis de la respuesta (1 llamada LLM con todo el contexto recopilado)
Cada paso tiene un coste. Si además usas un modelo potente en cada una de estas llamadas, los costes crecen rápido.
Optimización: usa un modelo económico para los pasos de decisión (1, 3) y un modelo potente solo para la síntesis final (5). Y establece un límite de iteraciones de retrieval — la mayoría de preguntas se resuelven en 1–2 rondas, no en cinco.
Más sobre la arquitectura de Agentic RAG en el artículo Agentic RAG — cómo funciona en la práctica.
Batch API: cuando no necesitas el resultado de inmediato
Si tienes tareas que no requieren respuesta en tiempo real — procesamiento offline de documentos, ejecuciones analíticas nocturnas, datos de entrenamiento — la Batch API es un ahorro significativo. Anthropic (y otros proveedores) ofrece –50 % en llamadas batch frente al precio síncrono, a cambio de un procesamiento con varias horas de retraso.
Arquitectura: el sistema front-end acumula tareas en una cola, el batch job corre por la noche o cuando la carga es baja, los resultados se escriben en la base de datos y están disponibles por la mañana. Para muchas aplicaciones industriales — resumen de informes, categorización de documentación, extracción de datos de PDF — este enfoque es financieramente mucho más ventajoso.
Medición de costes: qué monitorizar en producción
El token cost sin observabilidad es una caja negra. Recomendamos monitorizar al menos estas métricas:
- Cost per task type — los distintos tipos de tareas tienen perfiles de coste diferentes. Sin esta distinción no sabes dónde optimizar.
- Retry rate por herramienta — ¿qué herramienta provoca más retries? ¿Es un fallo de la herramienta o una tool description deficiente?
- Average steps per run — si la media es 8 pasos cuando esperabas 4, hay que revisar la arquitectura.
- Cache hit rate — si tienes prompt caching, ¿qué porcentaje de llamadas realmente hace cache? Por debajo del 60 % el caching está mal configurado.
- Human escalation rate — ¿qué porcentaje de tareas termina en escalación? Si sube, probablemente el agente está fallando en escenarios para los que no fue diseñado.
Herramientas como Langfuse (auto-hostable, framework-agnostic) o LangSmith (integración profunda con LangGraph) capturan estas métricas a nivel de cada nodo y llamada. Sin observabilidad estás a ciegas — más sobre esto en el artículo sobre observabilidad de agentes de IA.
Modelos open-weight como alternativa de coste
Para los equipos que priorizan el aspecto económico, los modelos open-weight actuales son una alternativa real. Familias como Qwen 3.x, DeepSeek o Llama 4 alcanzan en muchos benchmarks agénticos resultados comparables a los modelos frontier closed-source — con coste de API nulo o mínimo si corren on-premises.
Pagas un servidor GPU en lugar de la API. Para grandes volúmenes de tareas (decenas de miles de llamadas diarias) el punto de equilibrio suele estar en el horizonte de meses. Para entornos regulados donde los datos no pueden salir de la empresa, el on-prem es además un requisito de compliance, no solo una cuestión de coste.
Compromiso: el on-prem requiere capacidad de ingeniería para gestionar la infraestructura, el serving stack (vLLM, SGLang), el monitoreo y las actualizaciones de modelos. No todos los equipos disponen de ello.
Preguntas frecuentes
¿Por qué mi agente es mucho más caro de lo que estimé inicialmente?
La causa habitual es una combinación de tres factores: el historial en el contexto que crece con cada paso del bucle, las llamadas de retry cuando fallan las herramientas, y los system prompts largos que se repiten en cada llamada. El prototipo suele probar 1–2 pasos con entradas estáticas. La producción significa entradas reales, errores reales de herramientas y usuarios que llevan al agente a estados inesperados. Recomendamos perfilar el cost per run desglosado por componentes (system prompt, historial, salidas de herramientas, output) antes de empezar a optimizar.
¿Vale la pena implementar prompt caching?
Si tienes un system prompt de más de 1 000 tokens y el agente corre en decenas o cientos de sesiones al día, sí — casi siempre vale la pena. La implementación es mayormente sencilla (un parámetro en la llamada a la API), el ahorro sobre la parte cacheada es del orden de –90 % en Anthropic. La condición es la estabilidad del inicio del contexto — si el system prompt cambia en cada llamada, la cache hit rate será baja.
¿Cuándo conviene pasar de la API a un modelo on-prem?
Depende del volumen y los requisitos de compliance. Como regla orientativa: si la factura mensual de API supera el coste de un servidor GPU dedicado (incluyendo gestión y amortización del hardware) — típicamente en el orden de varios miles de euros al mes — tiene sentido hacer el análisis. Para sectores regulados (sanidad, derecho, finanzas) el on-prem es además una condición de cumplimiento GDPR, no solo una cuestión de coste.
¿Cómo fijar un límite razonable de max_steps?
Empieza por perfilar — ¿cuántos pasos necesita realmente tu tarea típica? Si la mediana es 4 pasos y el percentil 95 es 8, fija el límite en 12–15 con margen de seguridad. El límite debe ser lo suficientemente alto como para no interrumpir tareas largas legítimas, pero lo suficientemente bajo como para capturar bucles infinitos. La combinación de max_steps + timeout + alerta de monitorización para runs con > 80 % del límite es robusta en la práctica.
¿Qué pesa más — los tokens o la escalación humana?
Depende de la tasa de escalación. Si el agente escala el 1–2 % de las tareas y el tiempo humano cuesta 5 euros por incidente, con 1 000 tareas al día son 50–100 euros/día en escalaciones — lo que puede superar el token cost de un modelo más barato. Para sistemas con alto volumen de tareas y una tasa de escalación no despreciable, reducir la escalación (mejor entrenamiento del agente, guardrails más claros) es una mejor inversión que ahorrar en tokens.
*Los costes de un agente en producción son medibles y controlables — pero solo si los medimos realmente. En MP Industrial Solutions ayudamos a las empresas a diseñar sistemas agénticos con un perfil de coste claro desde el principio, en lugar de optimizar retrospectivamente cuando la primera factura mensual llega por sorpresa. Si estás pensando en desplegar un agente y quieres construir un modelo de costes realista antes de la implementación, con gusto lo hablamos.*