Costes de agentes de IA: medir el consumo de tokens y poner un techo

Su agente de atención al cliente lleva seis semanas funcionando, el equipo está contento y los tiempos de respuesta se han acortado. Y entonces llega la factura del proveedor del modelo: en lugar de los 90 euros calculados, el recibo marca 1.400 euros. Ninguna caída, ningún error en el registro, ninguna alerta en rojo. El agente simplemente ha trabajado más de lo previsto, en puntos que nadie vigilaba.

Ahí está precisamente el problema. Con una ventana de chat usted conoce los costes, porque un clic es una petición. Con un agente, una operación no es una llamada, sino un bucle de llamadas, herramientas y decisiones nuevas. Los costes nacen donde nadie mira.

En este artículo verá por qué los costes de los agentes funcionan de manera distinta a los de un chat, qué cuesta de verdad una operación repartida en cuatro bloques de gasto, cómo hacer medible el coste por operación y con qué cuatro palancas puede poner en una semana un techo que también aguante en producción.

---

Índice de contenidos

1. Por qué los costes de los agentes se descontrolan
2. Lo que realmente cuesta un agente
3. Cómo hacer visibles los costes por operación
4. Cuatro palancas que limitan los costes
5. Un techo de costes en una semana
6. Conclusión

---

Por qué los costes de los agentes se descontrolan

La diferencia entre una ventana de chat y un agente no es un detalle, sino el núcleo del problema de costes. En un chat, la entrada es tan grande como su pregunta y la salida tan grande como la respuesta. En un agente, el propio sistema decide cuántos pasos necesita: lee datos, llama a herramientas, evalúa resultados intermedios, se corrige y de vez en cuando vuelve a empezar. Cada uno de esos pasos es una llamada propia al modelo con su consumo de tokens. Anthropic cuantificó públicamente este efecto en junio de 2025: los agentes consumen de forma típica unas cuatro veces más tokens que una interacción de chat, y los sistemas multiagente unas quince veces más. Esa cantidad cuatro veces mayor no es una anomalía, es la norma, y no aparece en ninguna estadística que solo cuente peticiones.

Por eso, la causa más frecuente de unos costes desbocados tampoco es un modelo caro, sino un bucle sin fin. Hay tres patrones que encontramos en casi todos los proyectos que asumimos. Primero, el reintento: una herramienta devuelve un mensaje de error, el agente lo intenta otra vez, luego una tercera, y los tres intentos fallidos cuestan más que el encargo original. Segundo, el contexto que crece: cada nivel vuelve a recibir todo el historial anterior, por lo que el consumo de tokens de entrada crece de forma desproporcionada con cada paso. Tercero, la elección de modelo sin diferenciación: el mismo modelo grande decide si un campo de formulario está vacío, redacta la respuesta al cliente y revisa la factura al mismo tiempo.

Que este tema gane relevancia justo ahora lo muestra una noticia de heise online del 21 de septiembre de 2026. En su conferencia propia .conf en Denver, Splunk describió cuatro desarrollos que marcan hoy la operación de los sistemas de IA: la inferencia ha sustituido al entrenamiento como carga de trabajo dominante, los agentes se convierten en aplicaciones autónomas y empleados digitales, los tokens tienen ya, según la empresa, el carácter de una moneda, y el control se convierte en el verdadero foso defensivo. Como respuesta, Splunk lleva al mercado funciones de Agent Observability, con las que no solo se puede observar el comportamiento de un agente en tiempo de ejecución y a posteriori, sino también expresar los costes en euros a través de una economía de tokens (tokenomics). La herramienta debe además proponer modelos equivalentes pero más baratos. Cuando un proveedor de monitorización de este tamaño convierte el control de costes en una función central, la pregunta ya no es si debería medir los costes de sus agentes, sino solo cómo empezar esta semana.

Merece atención un segundo punto de esa misma noticia: Splunk señala que una parte de estas funciones de seguridad solo demuestra su valor a posteriori. Un patrón de daño a menudo se reconoce únicamente después del incidente. Con los costes ocurre lo mismo. El mes más caro es aquel en el que nadie tomó notas, y después ya no se puede reconstruir qué operación consumió qué cantidad. No necesita una plataforma enterprise para evitarlo. Necesita una cifra por operación, y esa cifra se puede obtener con medios caseros.

Lo que realmente cuesta un agente

Quien habla de costes de agentes casi siempre piensa en la factura del modelo. Es la parte más pequeña. En la práctica, el esfuerzo se compone de cuatro bloques que conviene medir por separado, porque se comportan de forma distinta.

Bloque 1: tokens del modelo. El consumo de todas las llamadas de una operación, es decir, el prompt, los pasos intermedios, las descripciones de herramientas y la respuesta final. Es el único bloque que varía cuando un modelo falla y el agente entra en un bucle.

Bloque 2: herramientas e infraestructura. La instancia de n8n o el servidor donde corre el flujo, una base de datos vectorial o un almacén de conocimiento, interfaces de terceros de pago, por ejemplo para validación de direcciones, datos de envío o datos de pago. Estas partidas son en gran medida fijas y por eso rara vez se convierten en coste por operación.

Bloque 3: operación y monitorización. El tiempo dedicado a registros, revisiones, actualizaciones y evaluación de la medición de calidad. También suele ser un bloque fijo, pero uno que muchos proyectos subestiman, porque nunca aparece en una propuesta.

Bloque 4: retrabajo humano. Cada operación escalada cuesta tiempo de trabajo. Es el bloque que menos aparece en las conversaciones y el que más pesa en la factura.

Un ejemplo de cálculo con supuestos abiertos deja clara la diferencia. Se asumen 40 operaciones al día, 60.000 tokens de entrada y 6.000 tokens de salida por operación, incluido el bucle del agente, y precios de 1,50 euros por millón de tokens de entrada y 6,00 euros por millón de tokens de salida para un modelo de gama media.

• Entrada: 40 operaciones por 60.000 tokens, es decir 2,4 millones de tokens al día, dan 3,60 euros.
• Salida: 40 operaciones por 6.000 tokens, es decir 240.000 tokens al día, dan 1,44 euros.
• Coste del modelo en total: 5,04 euros al día, y con 21 días laborables unos 105,84 euros al mes.

Esas mismas 40 operaciones como simples peticiones de chat (factor 4, según el valor citado de Anthropic) cuestan unos 1,26 euros al día, es decir 26,46 euros al mes. Como sistema multiagente con subagentes en paralelo (factor 15) son 75,60 euros al día y unos 1.587,60 euros al mes. Solo estas tres cifras explican por qué el tema merece atención: la arquitectura, no el modelo, decide el factor 15.

Ahora llega el bloque que da la vuelta a la cuenta. Suponga una tasa de escalación del 8 por ciento, un retrabajo de seis minutos por caso y un coste completo de 45 euros por hora de trabajo. Son 3,2 escalaciones al día, es decir 14,40 euros de retrabajo diarios. El retrabajo es así casi tres veces más caro que toda la factura del modelo. Quien solo optimiza el coste del modelo trabaja sobre la palanca más pequeña.

Para comparar, la situación de partida: esas mismas 40 operaciones hechas a mano, ocho minutos por operación, cuestan 240 euros al día. El agente se queda con modelo y retrabajo juntos en 19,44 euros, y el ahorro ronda los 220,56 euros al día o unos 4.632 euros al mes. El agente es, por tanto, rentable, pero solo mientras la tasa de escalación no se dé la vuelta. Si sube del 8 al 20 por ciento, solo el retrabajo crece hasta 36 euros al día y el ahorro se reduce de forma notable. El agente es, por tanto, menos un proyecto tecnológico que una cuestión de tasas.

Consejo práctico: No calcule sus agentes en tokens, sino en coste por operación completada con éxito. Esa única cifra hace comparables las caídas, los cambios de modelo y los proyectos de ampliación, y es el único indicador que un empresario entiende sin explicaciones.

Cómo hacer visibles los costes por operación

Sin medición no hay techo. La buena noticia: casi todos los datos que necesita ya se generan en la operación, simplemente no se registran. Para cada operación deberían ir ocho valores en una línea: número de operación, finalidad, modelo utilizado, tokens de entrada, tokens de salida, número de llamadas a herramientas, resultado (correcto o escalado) y coste en euros. Además conviene añadir una marca de tiempo, para poder detectar las variaciones diarias y semanales.

Las cifras de tokens las entregan la mayoría de los proveedores de modelos directamente con la respuesta; en n8n las encontrará en el objeto de respuesta, en el campo de consumo. El número de llamadas a herramientas y el número de niveles del bucle aparecen en el registro de ejecución, en n8n en la vista de ejecuciones. Los costes no los escriba en la base de datos, calcúlelos siempre a partir de los tokens y del precio configurado en ese momento. Un importe en euros escrito a mano queda obsoleto en el siguiente cambio de modelo; una fórmula, no.

De esos datos en bruto salen cuatro análisis que sostienen la operación:

1. Coste por operación completada con éxito. El denominador cuenta solo los casos cerrados sin intervención humana. Esta cifra sube cuando baja la calidad y baja cuando una palanca entra en acción. Es su indicador principal.
2. Proporción de escalaciones. Conecta coste y calidad, porque cada operación escalada cuesta tiempo de trabajo. Una medición de la calidad de las respuestas la describimos en el artículo sobre los fallos silenciosos en producción, y justo ahí encaja el valor de coste como segunda cifra.
3. Tokens por operación como distribución, no como media. La media esconde los valores atípicos. Las cinco operaciones más caras de una semana casi siempre muestran la causa: un bucle infinito, un documento de 200 páginas, una herramienta que devuelve errores una y otra vez.
4. Coste por tipo de operación. Reclamación, consulta nueva, estado del pedido: los tipos de operación se diferencian mucho. Algunos merecen la pena, otros deberían funcionar sin ningún modelo.

Para guardarlo basta con una tabla en una base de datos o una hoja de cálculo. En un agente que se ocupa de la atención al cliente encontrará patrones adecuados en nuestra guía de automatización del servicio de atención con n8n, incluida la pregunta de qué operaciones deberían automatizarse siquiera. Y si quiere comparar entre varias automatizaciones, en las siete automatizaciones de IA para pymes encontrará candidatos suficientes para una comparación limpia del coste por operación.

Cuatro palancas que limitan los costes

Medir por sí solo no reduce ningún coste. Solo lo hace visible. Lo que de verdad mantiene pequeña la factura son cuatro palancas que debería configurar en cualquier agente, sea cual sea la plataforma.

Palanca 1: límite de bucle. Defina un máximo duro de pasos, por ejemplo ocho llamadas a herramientas por operación. Al alcanzarlo no se sigue intentando, se escala. Eso evita justo el patrón que hace saltar las facturas: un agente que choca tres veces contra el mismo mensaje de error. Un límite de bucle es el seguro más barato que existe en la operación de agentes.

Palanca 2: modelo por paso. No todos los pasos necesitan el modelo más grande. La clasificación, la extracción de campos y la validación de formato las resuelve un modelo pequeño y rápido por una fracción del coste. El modelo grande solo se usa donde hay que redactar o sopesar. Splunk ofrece con su Agent Observability justo eso, propuestas de modelos equivalentes pero más económicos, lo que demuestra cuánto potencial de ahorro hay solo en la asignación de cada tarea al modelo adecuado.

Palanca 3: techo de contexto. No envíe todo el historial de la conversación, solo los últimos mensajes y los fragmentos realmente relevantes del almacén de conocimiento. Dos técnicas ayudan de inmediato: escribir los resultados intermedios en archivos o campos de base de datos en lugar de en el historial, y resumir los historiales largos en vez de ir añadiéndolos. Quien deja crecer el historial sin límite paga la misma tarifa varias veces, una más con cada paso.

Palanca 4: presupuesto, permisos e identidad. Fije un presupuesto diario y un presupuesto mensual, con un aviso al 80 por ciento del consumo. Asigne roles en lugar de acceso total: el agente debe leer lo que necesita y escribir aquello para lo que está autorizado. Y dé a cada agente una identidad propia en lugar de las credenciales de un empleado. Que este último punto no es un detalle lo demuestra un caso del 20 de septiembre de 2026 que recogió heise online. Amazon ha expulsado de su tienda al agente personal de IA Muse, de Meta, y ha mostrado a los usuarios una ventana en la que se indicaba que un acceso adicional por parte de un agente de IA no autorizado infringe las condiciones de uso. Amazon justifica la medida diciendo que el agente no se identifica al navegar y que captura credenciales de acceso, algo que Meta niega. Al margen de quién tenga razón en esta disputa, la lección para cualquier empresa es la misma: un agente que no se identifica y no tiene permisos definidos pierde el acceso. Las redes de pago están trabajando ahora en estándares para la identificación de agentes, y ese mismo criterio se aplicará pronto también a los sistemas internos.

A eso se añade una dimensión de seguridad de la que informó heise online el 21 de septiembre de 2026: los atacantes pueden obtener acceso a través de una vulnerabilidad crítica en varios agentes de programación y herramientas de línea de comandos muy extendidos. Cada agente es una puerta de entrada a sus sistemas, y un agente con acceso total a todas las herramientas es, en caso de duda, la vía más cómoda para entrar. Un alcance de herramientas limitado protege por tanto el coste y también la superficie de ataque.

Un componente compacto para la palanca de presupuesto, listo para usar como nodo de código en n8n:

// Nodo de código de n8n: cancelar la operación cuando se alcanza el límite de coste o de pasos
const item = $input.first().json;

// Precios por 1 millón de tokens, manténgalos en un solo sitio y no en el prompt
const PRICE_IN = 1.5;
const PRICE_OUT = 6.0;

const MAX_STEPS = 8;
const MAX_COST_PER_RUN = 0.35;
const DAILY_BUDGET = 12.0;

const steps = Number(item.steps || 1);
const tokensIn = Number(item.usage?.input_tokens || 0);
const tokensOut = Number(item.usage?.output_tokens || 0);

const cost =
  (tokensIn / 1000000) * PRICE_IN + (tokensOut / 1000000) * PRICE_OUT;

const todayCost = Number(item.budget?.spentToday || 0) + cost;

const reasons = [];
if (steps > MAX_STEPS) reasons.push("Schleifenlimit erreicht (" + steps + ")");
if (cost > MAX_COST_PER_RUN) reasons.push("Kosten je Vorgang ueberschritten");
if (todayCost > DAILY_BUDGET) reasons.push("Tagesbudget ausgeschoepft");

const escalate = reasons.length > 0;

// En caso de escalación: entregar la operación a una persona, no dejarla seguir
return [
  {
    json: {
      ...item,
      cost: Number(cost.toFixed(4)),
      spentToday: Number(todayCost.toFixed(4)),
      escalate,
      escalateReason: reasons.join("; "),
    },
  },
];

Consejo práctico: Configure el alcance de herramientas más estrecho de lo que le parezca correcto. Un agente que no llega a la nómina tampoco puede generar costes allí ni perder datos. Ampliar un permiso lleva cinco minutos; un incidente lleva semanas.

Un techo de costes en una semana

No necesita una plataforma ni un presupuesto para esto. Cinco pasos repartidos en una semana laboral llevan a un agente del vuelo a ciegas a cifras sólidas.

Paso 1: registrar el coste por operación durante siete días. Tome el agente con mayor consumo. Anote para cada operación las cifras de tokens de la respuesta, el número de llamadas a herramientas y el resultado en una tabla. Nada más. Esa única semana da la base para todo lo demás.

Paso 2: buscar valores atípicos, no medias. Abra las cinco operaciones más caras. En casi todos los casos encontrará ahí un bucle, un documento sobredimensionado o una herramienta con errores. Corrija primero esa causa. Según nuestra experiencia, ahí está el mayor efecto individual sobre la factura mensual.

Paso 3: configurar dos palancas. Empiece por el límite de bucle y el modelo por paso. Estas dos no cambian nada en la calidad de las operaciones normales, pero recortan los valores atípicos al alza. Compruebe a los tres días el coste por operación completada con éxito y la tasa de escalación.

Paso 4: un techo con alarma. Fije un presupuesto diario y haga que le avisen al 80 por ciento del consumo, no cuando se supere. Una alarma que llega antes del límite permite decidir. Una alarma posterior solo ofrece una explicación.

Paso 5: una cifra en el informe semanal. Incorpore el coste por operación completada con éxito y la tasa de escalación a su informe actual. En cuanto esa cifra sea visible, cualquier discusión sobre cambios de modelo, ajustes de prompt o ampliaciones será una discusión sobre efectos y no sobre sensaciones.

Conclusión

La factura del modelo es, en los agentes de IA, el bloque de coste más pequeño, no el mayor. Las partidas decisivas nacen en el bucle, en el retrabajo y en las llamadas a herramientas que nadie cuenta. Al mismo tiempo, la idea de que un agente quema tokens sin control se apoya en una causa evitable: la falta de palancas. Límite de bucle, modelo por paso, techo de contexto y un presupuesto con permisos e identidad se instalan juntos en un día.

El beneficio de este trabajo no es solo la factura más baja. Quien conoce el coste por operación puede justificar en cualquier momento por qué un agente es rentable, y reaccionar cuando sube la tasa de escalación antes de que el ahorro se dé la vuelta. Justo esa prueba es lo que distingue en una pyme un proyecto de automatización que se queda de uno que se abandona tras el primer mes caro.

El mercado señala la misma dirección. Observadores como Splunk declaran el control como el foso defensivo, las redes de pago trabajan en estándares para la identificación de agentes y las plataformas deciden qué agentes obtienen acceso. La visibilidad y la limitación se convierten en condición para poder participar siquiera. ¿Cuántas de sus operaciones automatizadas podría cuantificar hoy en euros?

Sobre MadeByBrain: Construimos automatización con IA para pymes: agentes de IA propios, flujos de n8n y estrategias GEO, en uso real. Desde la primera idea hasta la automatización productiva.

Solicita una consultoría gratuita →