El precio por token no es el coste de tu agente

El coste real de una funcionalidad de IA se calcula por ejecución que termina bien, no por el precio del millón de tokens. Sumas el contexto que reenvías, las llamadas al modelo, las tools, los reintentos, la capa alrededor y el minuto de quien repara, en un tenant concreto. El token es la materia prima y el agente es el proceso.

El precio del millón de tokens baja y, aun así, la factura del agente sube. No es un error de Excel: estás midiendo la materia prima y no el trabajo.

La unidad correcta no es euros por millón de tokens, sino el coste de una ejecución que termina bien: una tarea cerrada, en un tenant concreto, sin que un humano tenga que rehacerla. El token es la línea de la factura del modelo; el agente es el proceso.

McKinsey lo escribió en julio de 2026 sin rodeos: los tokens no son valor, son la cuenta. En su encuesta, el 93% de quienes respondieron se pasaban del presupuesto de IA. El índice de Stanford HAI 2025 documentó que el coste de inferir capacidad tipo GPT-3.5 cayó de 20 USD a 0,07 USD por millón de tokens hasta 2024. En el mismo tramo, el gasto empresarial en LLM (modelos grandes de lenguaje) se triplicó.

Esa tensión también llega al comité. El AI Radar 2026 de BCG, con casi 2.400 ejecutivos, dice que las empresas planean doblar la inversión en IA: del 0,8% al 1,7% de los ingresos. Casi todos los CEOs creen que los agentes darán un retorno medible este año. En The State of AI 2025, el 88% ya usa IA en alguna función, pero solo el 39% atribuye algún impacto al EBIT (beneficio operativo). La mayoría de ese grupo dice que es menos del 5%, y solo el 6% reporta un impacto serio.

Se gasta más y se espera más de los agentes, pero el beneficio no aparece solo. La diferencia suele estar en la unidad que miras. El TCO (coste total de propiedad) lo desglosamos en cuánto cuesta implementar un agente. Aquí nos quedamos con una ejecución: por qué el precio por token no te dice si el caso sale.

Por qué bajan los tokens y sube la factura

El precio de lista del modelo es una tarifa de materia prima. Un chat de un turno consume esa materia una vez; un agente la consume en bucle: relee el contexto, llama tools, se corrige y vuelve a generar.

Ese mismo trabajo enumera por qué la deflación no llega a la factura. El contexto se reenvía en cada paso, porque los modelos no recuerdan solos. Refinar la respuesta (comprobar, reparar y volver a verificar) se come alrededor del 60% del coste de una tarea agéntica, y la misma tarea puede costar 30 veces más según el camino que tome el agente. Se usa razonamiento caro para trabajo fácil, y la orquestación (cómo se parten las tools y los handoffs) multiplica gasto sin mejorar el resultado. El formato de la información también importa: un texto en español se parte en más tokens que el mismo significado en inglés.

Por eso ves titulares de "el token está por el suelo" y un CFO que pregunta por qué este mes se ha triplicado la línea. No se contradicen: miden cosas distintas. La economía es del workflow, no de la tarifa. Si no instrumentas la ejecución, el precio por millón es un consuelo. Hay una guía práctica sobre dónde pagan los agentes si quieres el desglose largo.

¿De qué se compone el coste de una ejecución?

Una ejecución es el viaje completo hasta una tarea aceptable, no "un prompt". En un SaaS suele tener estas piezas.

Contexto. Ticket, historial, documentos, esquema de tools e instrucciones. Se paga de entrada y se vuelve a pagar cada vez que el agente da otro paso.

Llamadas al modelo. Tokens de entrada, de salida, de caché si la hay, y de razonamiento si el modelo "piensa" antes de actuar. Revisa las tarifas públicas de Claude como suelo, no como límite. El precio real sube con ventana larga y con reintentos.

Tool calls. Cada vez que el agente toca tu API, un MCP (protocolo para conectar el agente con herramientas) o un buscador, pagas inferencia de orquestación más la infra de esa llamada. Si la tool devuelve un volcado enorme, ese volcado entra en el siguiente contexto.

Reintentos y refinamiento. Si la tool falla, el JSON no valida o el agente no se fía y se pregunta otra vez, aquí vive buena parte de la factura que nadie presupuestó.

Capa alrededor. Gateway, logs, evaluación y colas. Parte del gasto que más crece ya no es el LLM: es seguridad, orquestación y monitoring que también se cobran por token o por traza.

Humano. Revisión, corrección y escalado. Si el agente propone y una persona envía, ese minuto entra en el coste de la ejecución. Si el agente se equivoca, entra el minuto y el retrabajo.

Suma eso y deja de preguntar "¿cuánto cuesta el millón de tokens?". La pregunta útil es "¿cuánto cuesta que este ticket, en este tenant, quede bien?".

Costes ocultos

El promedio miente, porque el coste se comporta como una distribución y no como un precio unitario fijo. El 5% de ejecuciones que se van de madre (contexto largo, ocho tools, un bucle) puede comerse la mitad de la factura del mes.

El tenant gordo también se esconde. Un cliente con historial eterno y documentos mal cortados no cuesta "un poco más": cuesta otra especie de ejecución. Si lo promedias con el tenant limpio, el que destruye margen no se ve.

La persona que supervisa y corrige el error de un agente no sale en la factura del modelo. Un fallo te cobra céntimos de API y minutos de alguien que tiene que reescribir el resultado.

También hay un coste de no haber definido reglas de parada ni un tope de reintentos. Sin límite de gasto por hilo y por tenant, un agente puede repetir tools hasta que un céntimo se convierte en la factura de una noche. No hace falta un incidente famoso: basta un agente sin regla de parada. Lo hemos visto más veces de las que nos gusta admitir.

Y hay un coste de idioma. Si tu producto habla español, no copies un presupuesto pensado en inglés: el mismo significado tokeniza peor. El método no cambia, el número sí.

Métricas útiles

Tres números bastan para decidir; el resto es ruido de dashboard.

Coste por tarea correcta. Modelo + tools + reintentos + humano de esa ejecución, solo cuando el resultado se acepta. Si no mides el fallido aparte, estás promediando teatro.

Tasa de éxito sin reparación. Qué porcentaje sale bien sin que alguien reescriba. Es la palanca que decide si puedes quitar al humano o no.

p95 por tenant. El percentil 95, no la media: qué cuesta una ejecución fea en el cliente gordo. El margen se rompe en la cola, no en el caso feliz de la demo.

A esas tres métricas conviene sumar dos de estrés, las que Alberto adelantaba en el vídeo sobre inferencia: qué pasa si el modelo sube un 30%, y qué pasa si la inferencia real (cuando el precio de lista deje de estar tan fino) es el doble. Si el caso solo sale con la tarifa de hoy, no tienes un caso, tienes una promoción.

Lo que no sirve es usar €/1M tokens como KPI (indicador) de producto. Sirve para negociar con el proveedor, no para aprobar un agente en un SaaS.

Ejemplo de cálculo paso a paso

Este es un ejemplo ilustrativo, no un cliente: una cuenta que puedes repetir con tus tarifas.

Imagina un agente de soporte que propone el borrador de respuesta de un ticket y no lo envía al cliente. Como tarifa de ejemplo, en septiembre de 2026, un modelo de gama media en las tablas públicas ronda los 2 USD por millón de tokens de entrada y 12 USD por millón de salida. El precio exacto cambia cada trimestre; el método de la cuenta no.

1. Contexto inicial. Ticket más tres artículos de ayuda: 8.000 tokens de entrada. 8.000 / 1.000.000 x 2 = 0,016 USD.

2. Dos tool calls. Buscar en la documentación y leer el pedido. El agente reenvía contexto. Otros 12.000 tokens de entrada y 600 de salida. Entrada: 0,024 USD. Salida: 0,007 USD.

3. Reintento. La tool de docs devuelve demasiado. El agente vuelve a pedir con más contexto: 15.000 tokens de entrada y 400 de salida. Entrada: 0,030 USD. Salida: 0,005 USD.

4. Borrador final. 500 tokens de salida. 0,006 USD.

Tokens de esta ejecución: unos 0,09 USD. Parece barato, y es justo el número que enseña la slide del vendor.

5. Evaluación. Uno de cada 20 tickets pasa por un juez automático (unos 0,02 USD). Amortizado: 0,001 USD.

6. Humano. Revisa 90 segundos. Si el minuto cargado de esa persona vale 0,80 EUR (unos 48 EUR/hora), son 1,20 EUR.

Coste de la ejecución aceptada: unos 0,09 USD de modelo más 1,20 EUR de humano. El token es una fracción. A 10.000 tickets al mes, el modelo son unos 900 USD y el humano, si revisa todos, se va de 12.000 EUR. Por eso el precio por token no decide el margen: lo decide cuántas ejecuciones salen bien sin reparación.

Si el 5% entra en un bucle (ocho tools, contexto de 40.000 tokens, un modelo de razonamiento), ese 5% puede igualar o superar el gasto del otro 95%. Presupuesta la cola, no solo el caso feliz.

Ahora el estrés: multiplica la inferencia por dos. Si el caso sigue saliendo, tienes margen. Si el margen desaparece, ese flujo aún no debería ser autónomo. Encaja con lo que ya vimos en producción: una demo no es un agente.

Qué optimizar primero

No empieces por el modelo más barato: empieza por lo que multiplica tokens.

Corta tools y contexto. Cada documento "por si acaso" se paga en cada paso, y cada tool extra es una oportunidad de volcar basura y reintentar. El agente más barato es el que hace una cosa.

Pon una regla de parada. Límite de coste por hilo, por tenant y por día, un máximo de tool calls y un kill switch. Sin eso, el p95 no tiene límite.

Enruta. El modelo grande es para el 10% de turnos difíciles, no para saludar ni para clasificar. La gente se va al modelo más caro por defecto; el ahorro real está en reservar el razonamiento caro para cuando cambia el resultado.

Mide para poder bajar. Sin evaluación no te atreves a cambiar de modelo, así que pagas el premium para siempre o bajas a ciegas y lo pagas en retrabajo.

Quita humano donde el riesgo lo permite. El minuto de revisión es, en muchos flujos, la partida grande. Dejarlo en el envío al cliente y quitarlo de un resumen interno no es "menos calidad": es unit economics. BCG lo resume en el Radar 2026: hay que rastrear resultados tangibles. El ROI (retorno de la inversión) no es una proyección de tokens.

Cuándo un modelo barato sale caro

Un modelo barato sale caro cuando el fallo es más caro que el token que te ahorraste.

Si la tasa de acierto cae y el humano reescribe, has cambiado 0,04 USD por dos euros de alguien que no era el plan. Si el modelo llama mal a las tools y vuelca 20.000 tokens de ruido, el "ahorro" se lo come el siguiente paso. Sin evaluación no sabes cuál de las dos cosas te está pasando.

También sale caro el modelo caro usado para todo. Clasificar un ticket con un frontier es lujo; el razonamiento extendido se paga solo en las tareas difíciles.

La pregunta no es "¿cuál es el modelo más barato?", sino "¿cuál es el más barato que mantiene la tasa de éxito y el p95 que tu margen aguanta?". Si no puedes contestar eso esta semana, no tienes un problema de proveedor: tienes un problema de medición.

Hay casos donde el agente no compensa: volumen bajo, valor por tarea pequeño, reparación humana alta, o un flujo sin fuente de verdad. Ahí no hace falta un modelo más barato, sino otra automatización, o esperar. El framework de Alberto es este: si sale por mucho, ejecuta; si sale por poco, optimiza; si no sale ni con inferencia estresada, a la nevera.

Checklist: el coste por ejecución, no el precio del token

Antes de aprobar el agente (o de pelear la tarifa del vendor), el equipo debería poder responder sí a esto.

¿Sabes el coste de una ejecución correcta esta semana, no el total de la factura?

¿Separas modelo, tools, reintentos y minutos humanos?

¿Miras el p95 y el tenant gordo, no solo la media?

¿Hay límite de coste por hilo y por tenant, con dueño?

¿El caso aguanta una subida del 30% en el modelo, o el doble de inferencia?

¿Tienes evaluación suficiente para bajar de modelo sin adivinar?

Si faltan dos o más, negociar el precio por millón no cambia el margen: cambia el relato.

Cuando tengas esas líneas, el resto es aritmética. En Devic esa cuenta se opera en el harness: observabilidad y control de coste por ejecución, con planes para medir volumen antes de comprometer el margen. No es un precio universal: es la forma de ver cómo escalan los costes antes de encender el agente en todos los tenants.

El precio de lista del token puede seguir bajando o no. Hoy OpenAI, Anthropic y Google pueden estar cobrando por debajo del coste real de inferir, y eso no es un suelo sobre el que construir margen. Lo que no baja por sí solo es la factura del agente, salvo que midas cada ejecución y te protejas con un tope y con una prueba de estrés.