Cuánto cuesta realmente un sistema de agentes IA en producción

La primera vez que medí el coste real de uno de mis sistemas de agentes en producción, el número me sorprendió por razones distintas a las que esperaba. No era caro. Era completamente opaco. Tenía miles de llamadas a la API, tokens de entrada, tokens de salida, tokens cacheados, modelos mezclados, y una factura que no me decía absolutamente nada útil. No sabía si estaba gastando bien o mal. No sabía qué parte del coste correspondía a qué tarea. No sabía si optimizar o escalar. — Jorge Valero, Director de Tecnología e IA.

El problema no era el precio por token. Era que estaba midiendo la unidad equivocada.

Este artículo trata de cómo entender el coste real de un sistema de agentes en producción: qué factores lo determinan, qué métricas son útiles, y qué decisiones de arquitectura marcan la diferencia entre un sistema económicamente sostenible y uno que se convierte en una partida imposible de justificar.

El marco correcto: coste por resultado, no por llamada

La métrica que no sirve para nada es «número de llamadas a la API» o «tokens consumidos este mes». Son números que no tienen contexto. Un sistema que hace 50.000 llamadas mensuales puede ser extraordinariamente eficiente o un desastre de diseño, dependiendo de qué produce con esas llamadas.

La métrica que sí sirve es el coste por caso. «Generar este informe trimestral de análisis de proveedores cuesta €0,85.» Eso es información accionable. Puedes compararlo con el coste de hacerlo manualmente. Puedes proyectarlo al volumen mensual. Puedes decidir si merece optimización o si el margen es amplio.

Cuando cambié la forma de medir en los sistemas que opero, la claridad fue inmediata. Algunos flujos que parecían caros resultaron ser económicamente sólidos cuando los medí por resultado. Otros que parecían baratos resultaron ser ineficientes porque hacían demasiado trabajo por output.

El primer paso para gestionar el coste de un sistema de agentes es instrumentarlo por tarea o por caso de negocio, no por llamada a la API.

El coste por token y por qué hay tres órdenes de magnitud entre modelos

En 2026, los precios aproximados de los modelos principales de Anthropic son:

• Claude Opus: ~$15 por millón de tokens de entrada
• Claude Sonnet: ~$3 por millón de tokens de entrada
• Claude Haiku: ~$0,25 por millón de tokens de entrada

Eso es una diferencia de 60x entre Opus y Haiku. Entre Opus y Sonnet, 5x. Entre Sonnet y Haiku, 12x.

El error más frecuente que veo en equipos que empiezan con agentes es usar Opus para todo. Tiene lógica intuitiva: si el modelo más potente resuelve el problema mejor, ¿por qué usar uno menos capaz? El problema es que no todas las tareas requieren la misma capacidad de razonamiento. Y pagar 60 veces más por formatear un JSON o extraer una fecha de un texto es difícilmente justificable.

La pregunta correcta no es «¿cuál es el mejor modelo?». Es «¿cuál es el modelo mínimo suficiente para esta tarea específica?».

El efecto de la estratificación de modelos

En uno de los sistemas que tengo en producción —un sistema de 28 agentes para desarrollo de software— la arquitectura inicial usaba Opus en todos los agentes. Era el diseño más simple de implementar y el más intuitivo de razonar. También era el más caro por un factor de 5.

La arquitectura actual tiene tres niveles:

• 1 agente Opus: el orquestador principal, que recibe la tarea de alto nivel, la descompone en subtareas y coordina el flujo global.
• 25 agentes Sonnet: especialistas que ejecutan cada subtarea con razonamiento real —análisis, diseño, codificación, revisión—.
• 2 agentes Haiku: generadores de output estructurado. Su trabajo es tomar el razonamiento producido por Sonnet y emitirlo en el formato exacto que espera el siguiente paso del pipeline.

El resultado medido: 80% de reducción de coste frente a la arquitectura todo-Opus, con output de calidad equivalente o superior en la mayoría de las tareas.

El 80% no es una estimación teórica. Es la diferencia entre dos versiones del mismo sistema procesando el mismo tipo de tareas durante un período comparable. El coste cae porque la mayor parte del trabajo del sistema —los 25 agentes Sonnet— ya no usa el modelo más caro. El orquestador sí lo necesita: toma decisiones de nivel alto que requieren razonamiento complejo. Los agentes de output estructurado claramente no lo necesitan.

Tabla comparativa: tres arquitecturas, mismo sistema

Arquitectura	Composición de modelos	Coste relativo	Notas
Todo-Opus	28 agentes Opus	100% (base)	Diseño inicial. Máxima capacidad, máximo coste.
Estratificada	1 Opus + 25 Sonnet + 2 Haiku	~20% del base	80% de reducción. Output equivalente en casi todas las tareas.
Critics-first, sin Opus	27 Sonnet + critics Sonnet + 2 Haiku	~10-12% del base	40-60% adicional sobre estratificada. Elimina Opus completamente.

La tercera arquitectura merece una explicación. En otro sistema de producción —distinto del de 28 agentes— tomamos la decisión de eliminar Opus completamente y trasladar la calidad de razonamiento a una arquitectura critics-first: en lugar de un orquestador más potente que compense la menor capacidad de los agentes, el diseño pone critics Sonnet en cada etapa del flujo. El orquestador es Sonnet, pero cada subtarea pasa por un critic independiente que valida el razonamiento antes de avanzar.

El resultado fue una reducción adicional del 40-60% sobre la arquitectura estratificada. El dato real de ese sistema: el coste por caso cayó a menos de la mitad, con una tasa de error que se mantuvo equivalente gracias a la red de critics. No es para todos los sistemas ni para todas las tareas. Pero demuestra que la arquitectura importa más que el precio del modelo.

El impacto del contexto: la variable más ignorada

El coste por token es visible. El coste por contexto acumulado no lo es, y es donde se esconden las ineficiencias más difíciles de detectar.

Cada llamada a la API incluye un contexto: el historial de la conversación, las instrucciones del sistema, los artefactos intermedios, los resultados de herramientas anteriores. En un sistema sin gestión de contexto, ese overhead puede superar los 3.000 tokens por sesión —tokens que se pagan en cada llamada, que no aportan nuevo razonamiento, y que se acumulan exponencialmente en flujos largos.

En el sistema de 28 agentes, implementamos un sistema de contexto de cuatro capas: contexto global del proyecto, contexto de fase, contexto de tarea específica, y contexto de herramienta. Cada agente recibe solo el contexto relevante para su función, no el historial completo del flujo.

El resultado medido: de ~3.000+ tokens de overhead por sesión a ~978 tokens. Una reducción del 70% en el coste de contexto. En un sistema que procesa cientos de sesiones al mes, esa diferencia no es marginal.

El principio operativo: cada agente debe recibir exactamente el contexto que necesita para su tarea. Ni más ni menos. La tentación de pasar el historial completo «por si acaso» es costosa y, en la mayoría de los casos, innecesaria.

Prompt caching: el 90% de ahorro en contenido estable

Para bloques de contenido que no cambian entre sesiones —system prompts elaborados, templates de documentos, contextos de proyecto grandes, instrucciones extensas de dominio— Anthropic ofrece caché de prompts. El contenido cacheado se cobra a una fracción del precio normal: aproximadamente un 90% menos en el contenido que se sirve desde caché.

El TTL del caché es de 5 minutos por defecto (Claude Code usa este mecanismo de forma sistemática). Para sistemas con alta frecuencia de uso, el ahorro es directo. Para sistemas con baja frecuencia, hay que calcular si el volumen justifica el trabajo de estructurar el contenido para que sea cacheado de forma efectiva.

La regla práctica: cualquier bloque de texto de más de 1.000 tokens que se repite en múltiples llamadas es candidato a caché. Los candidatos más comunes son el system prompt del agente orquestador, las instrucciones de dominio (guías de estilo, criterios de validación, definiciones de negocio) y los documentos de referencia que los agentes consultan frecuentemente.

El coste de los agentes que se llaman a sí mismos

Hay una fuente de coste que no aparece en los análisis estáticos y que puede multiplicar la factura real: los agentes que entran en bucles.

Un agente mal delimitado —uno que no tiene criterios de parada claros, o que recibe objetivos demasiado vagos para resolverlos en un paso razonable— puede llamar a herramientas y sub-agentes de forma recursiva hasta que alguien lo detiene manualmente o hasta que llega al límite de contexto. He visto flujos que deberían resolver en 15-20 llamadas acabar en 200+ porque el objetivo estaba mal especificado.

La especificación del alcance de cada agente no es solo una decisión de arquitectura. Es una decisión de coste. Un agente bien delimitado sabe cuándo ha terminado. Un agente con objetivo difuso no.

Las skills de scaffolding y bootstrap: coste cero en configuración

Una optimización menos obvia: las operaciones de scaffolding y bootstrap —crear estructura de proyecto, generar archivos de configuración, inicializar entornos— no requieren inferencia del modelo cuando están bien diseñadas. En Claude Code, las skills que gestionan estas operaciones operan a coste $0 de modelo porque ejecutan plantillas deterministas sin llamar a la API de inferencia.

En sistemas bien diseñados, esto representa un ahorro del 5-10% sobre el coste total de proyectos complejos. No es el mayor factor, pero es coste eliminable por diseño. La lección más general: antes de enviar cualquier operación al modelo, preguntarse si realmente requiere razonamiento o si puede resolverse con lógica determinista.

El desglose mensual real: cuánto cuesta un sistema en producción

Con todo esto como contexto, el rango de costes mensuales de un sistema de 28 agentes en uso moderado —equipos de 5-10 personas, flujos de trabajo recurrentes pero no de alta frecuencia— es de €400-800 al mes en costes de API.

En uso intensivo —volumen alto, flujos complejos, varios equipos usando el sistema simultáneamente— el rango sube a €1.200-2.000 al mes.

Para contextualizar: un equipo de desarrollo que usa el sistema para generar, revisar y desplegar software de forma sistemática puede procesar cientos de tickets, pull requests y releases en ese período. El coste por unidad de trabajo es, en la mayoría de los casos, una fracción de lo que costaría procesarlo manualmente.

Pero ese cálculo solo tiene sentido si se mide por resultado. Si se mide por llamada a la API, el número no dice nada.

Qué hace que un sistema de agentes sea caro de verdad

Los factores que más consistentemente inflan el coste de un sistema de agentes en producción:

Arquitectura todo-Opus sin justificación por tarea. Ya lo hemos cubierto. Pagar por capacidad de razonamiento que la tarea no requiere es el error más frecuente y el más caro.

Sin gestión de contexto. El contexto que crece sin control en flujos largos es coste directo y creciente. Un sistema que no trunca, comprime o segmenta el contexto activamente se vuelve más caro con cada sesión.

Sin caché para contenido estable. System prompts largos y documentos de referencia que se reenvían en cada llamada cuando podrían estar cacheados son un gasto evitable.

Agentes con alcance mal definido que generan bucles innecesarios. Los bucles no solo consumen tokens. Consumen tiempo, añaden latencia al flujo y generan ruido en los logs que dificulta el diagnóstico.

No instrumentar por resultado. Sin métricas por caso, es imposible saber qué optimizar. El sistema se opera a ciegas.

La pregunta que importa

La dicotomía «barato vs caro» es el marco equivocado para evaluar el coste de un sistema de agentes. El marco correcto es: ¿cuánto cuesta producir este resultado específico, y es ese coste sostenible dado el valor que genera?

Un sistema de agentes que cuesta €1.500 al mes y elimina 400 horas de trabajo manual mensual en un equipo de análisis es barato. Un sistema que cuesta €200 al mes y produce output que nadie usa es caro a cualquier precio.

El trabajo real de gestionar el coste de un sistema de agentes no está en negociar precio por token con el proveedor. Está en diseñar bien la arquitectura desde el principio, instrumentar por resultado desde el primer día, y optimizar sistemáticamente los factores que sí son controlables: qué modelo hace cada tarea, cuánto contexto se arrastra, qué contenido se cachea, y qué agentes tienen alcance bien definido.

Si quieres entender cómo los agentes especializados impactan tanto en coste como en calidad, el artículo sobre agentes especialistas en inteligencia artificial es el siguiente paso. Y si lo que necesitas es construir el caso de negocio para justificar la inversión internamente, el artículo sobre ROI de inteligencia artificial en empresas tiene los números que necesitas.

Preguntas frecuentes