Un token es barato. Una tarea de negocio terminada, construida a partir de cientos de llamadas de tokens, no siempre es barata, y su precio está oculto. El precio por token de la API parece el coste de operar un agente, pero en un flujo de trabajo agéntico el modelo se llama muchas veces por tarea: planifica, llama a una herramienta, lee el resultado, recupera documentos, falla y reintenta. El número que importa a finanzas es el coste por tarea completada, no el coste por token, y la brecha entre ambos es donde los presupuestos se rompen en silencio.
¿Por qué el precio por token oculta el coste real?
Para un único prompt y una única respuesta, el coste por token y el coste por tarea son casi lo mismo. Una llamada de entrada, una respuesta de salida, una factura. Los flujos de trabajo agénticos rompieron esa equivalencia, y la rompieron en silencio porque la API de facturación sigue informando de la misma tarifa plana por token.
Un agente no termina un trabajo en una sola llamada al modelo. Hace un plan, llama a una herramienta (una búsqueda, una consulta a base de datos, una API), incorpora de nuevo el resultado de la herramienta al contexto, decide que el resultado está incompleto, recupera más documentos, vuelve a llamar al modelo y a veces entra en bucle. Ahora hay varios factores de coste distintos entre “tarea iniciada” y “tarea hecha”, y cada uno infla el gasto en tokens sin aparecer en una vista ingenua por llamada:
- Reintentos. Una llamada a herramienta fallida, una salida JSON mal formada o un tiempo de espera agotado desencadenan otro intento. El reintento consume tokens y no produce nada vendible. La documentación de uso de herramientas de Anthropic señala que cada llamada a herramienta añade también una sobrecarga de prompt de sistema (por ejemplo, aproximadamente de 290 a 500 tokens solo para habilitar el uso de herramientas), y esa sobrecarga se paga de nuevo en cada reintento.
- Llamadas a herramientas. Cada invocación de herramienta normalmente obliga al modelo a leer el resultado y razonar sobre él. Una tarea con cinco herramientas puede suponer seis o siete ciclos de ida y vuelta al modelo, y el contexto, que crece, se reenvía en cada salto.
- Planes de varios pasos. Los patrones planificador-ejecutor gastan tokens en el plan, luego en cada paso y, a menudo, en una pasada de verificación.
- Recuperación. Meter los documentos recuperados en el prompt es con frecuencia la partida individual más grande. Una pregunta de 2.000 tokens puede arrastrar 18.000 tokens de contexto, y si el agente vuelve a leer ese contexto a lo largo de varios ciclos de ida y vuelta, lo pagas repetidamente.
El resultado: dos flujos de trabajo pueden registrar tarifas por token idénticas y costes por tarea terminada radicalmente distintos. El que tiene una tasa de reintentos del 30 por ciento y una recuperación descuidada puede costar varias veces más por ticket resuelto mientras se ve idéntico en un panel de tokens. El coste por token mide el contador. El coste por tarea completada mide la factura.
¿Cuánto cuesta realmente una tarea agéntica?
Para concretarlo, estos son los precios de lista reales y actuales que sirven de ancla al ejemplo trabajado más abajo. Todas las cifras son por millón de tokens (MTok) y proceden de las propias páginas de precios de los proveedores.
| Clase de modelo | Entrada | Salida | Entrada en caché (lectura) |
|---|---|---|---|
| Grande (Claude Sonnet 4.6) | 3,00 $ | 15,00 $ | 0,30 $ (0,1x entrada) |
| Pequeño (Claude Haiku 4.5) | 1,00 $ | 5,00 $ | 0,10 $ (0,1x entrada) |
| Grande (OpenAI GPT-4o) | 2,50 $ | 10,00 $ | 1,25 $ (0,5x entrada) |
| Pequeño (OpenAI GPT-4o mini) | 0,15 $ | 0,60 $ | 0,075 $ (0,5x entrada) |
Fuentes: precios de Anthropic y precios de la API de OpenAI, ambos vigentes a mediados de 2026. Los tokens de salida cuestan aproximadamente cinco veces más que los de entrada en los modelos de Claude y cuatro veces más en los de OpenAI, razón por la cual un agente locuaz y con muchos reintentos es mucho más caro de lo que sugiere su huella de entrada. Dos cosas destacan para el control de costes: la salida es el lado caro del balance, y una lectura de caché cuesta una fracción de la entrada nueva (una décima parte en Claude, la mitad en OpenAI), lo que constituye la base documentada de la palanca de caché que se expone más abajo.
Anthropic publica su propia cifra ilustrativa: procesar 10.000 conversaciones de tickets de soporte a aproximadamente 3.700 tokens cada una en Haiku 4.5 cuesta alrededor de 37 $ en tokens. Eso es el suelo, una única llamada limpia por ticket. La cifra de más abajo muestra qué le ocurre a ese suelo una vez que añades los planes de varios pasos, las llamadas a herramientas, la recuperación y los reintentos de un agente real, y luego qué consigue un AgentOps disciplinado para volver a bajarlo.
Un ejemplo trabajado: coste por ticket de soporte resuelto
Las cifras de más abajo son ilustrativas, no un benchmark de ningún cliente concreto. La forma es una que vemos repetidamente, y se muestra la aritmética para que puedas contrastarla con tu propio tráfico.
Un agente de clasificación de soporte gestiona 10.000 intentos de ticket al mes. La versión 1 enruta cada ticket al modelo grande, recupera quince pasajes de la base de conocimiento por ticket y reenvía ese contexto a lo largo de varios ciclos de ida y vuelta a herramientas, y tiene una tasa de fallo del 30 por ciento: tickets que se escalan a una persona después de que el agente se rinda, habiendo quemado ya tokens. La versión 2 aplica tres palancas: un clasificador enruta el 80 por ciento fácil de los tickets al modelo pequeño y mantiene el 20 por ciento difícil en el grande; un reranker reduce la recuperación de quince pasajes a tres; la caché de prompts sirve el prefijo de sistema repetido y la base de conocimiento a la tarifa de caché; y un límite de pasos más un esquema de salida estricto reducen la tasa de fallo del 30 por ciento al 8 por ciento.
| v1 (antes) | v2 (después de las palancas) | |
|---|---|---|
| Modelo | Solo grande | Enrutado: 80% pequeño / 20% grande |
| Tokens por intento (aprox.) | ~24.500 | ~7.000 |
| Coste por intento | 0,100 $ | 0,015 $ |
| Tasa de fallo | 30% | 8% |
| Tickets completados / mes | 7.000 | 9.200 |
| Gasto mensual total en tokens | 1.000 $ | 150 $ |
| Coste por ticket resuelto | 0,143 $ | 0,016 $ |
Compara las dos columnas entre sí y las palancas se hacen visibles. El coste por intento cayó porque un clasificador envió el 80 por ciento rutinario a un modelo pequeño (una tarifa por token de 3 a 5 veces más barata), el reranking redujo la recuperación de quince pasajes a tres, y el prefijo de sistema repetido y la base de conocimiento se sirvieron desde caché a una décima parte del precio de entrada. El recuento de tickets resueltos subió porque un límite de pasos y un esquema de salida redujeron la tasa de fallo del 30 por ciento al 8 por ciento, de modo que menos intentos quemaron tokens sin producir un resultado utilizable. El numerador se aligeró y el denominador creció al mismo tiempo. El efecto combinado es una caída del 89 por ciento en el coste por ticket resuelto.
Fíjate en lo que no cambió: el precio de lista por token. El modelo grande sigue costando lo que cuesta en el 20 por ciento difícil. Lo que se movió fue la mezcla, el desperdicio y el peso del prompt. Ese es el punto. Optimizas el flujo de trabajo, no el token. Un equipo que mirara solo la tarifa por token habría concluido que no había nada que hacer, porque la tarifa nunca se movió.
Por qué esto es además una cuestión de gobernanza y de concentración
Para los equipos regulados, el problema del coste oculto no es solo un problema de finanzas. La misma opacidad que oculta el coste también oculta el riesgo.
Un flujo de trabajo que reintenta en silencio contra la API de un único proveedor ata tanto tu gasto como tu continuidad a la hoja de ruta de ese proveedor. Las políticas de los proveedores cambian, los precios cambian y los modelos quedan obsoletos según el calendario del proveedor, no el tuyo. La propia documentación de Anthropic mantiene una lista de obsolescencias de modelos, y un modelo del que dependa tu lógica de reintentos puede pasar a estado retirado. Si no puedes ver cuántos de tus tokens son reintentos contra un mismo modelo, tampoco puedes ver cuán expuesto estás cuando los términos o la disponibilidad de ese modelo cambien. La visibilidad de costes y la visibilidad de la cadena de suministro son la misma visibilidad.
Por eso defendemos ejecutar los agentes dentro de tu propio perímetro, con versiones de modelo fijadas, tus propias evaluaciones y un rastro de auditoría completo. Cuando el contador, las trazas y las decisiones de modelo viven todos en tu entorno, un cambio de precio o una obsolescencia se convierten en una decisión de enrutamiento que tú tomas, no en una emergencia que te entrega el proveedor. La palanca de coste y la palanca de control son la misma palanca.
Cómo una torre de control hace visible el coste oculto
No puedes gestionar el coste por tarea completada si cada llamada al modelo cae en un mismo cubo indiferenciado. La solución es estructural, y reside en el gateway.
Enruta cada llamada al modelo a través de un único AI gateway, de modo que ningún equipo llame directamente a las API de los proveedores. El gateway es el único punto de política de la arquitectura, así que también es el lugar natural para medir. Etiqueta cada solicitud con un ID de flujo de trabajo, el rol o paso dentro del flujo (planificador, recuperador, redactor, verificador), el equipo propietario y un ID de correlación que vincule cada llamada de una tarea a una sola traza. Ese ID de correlación es lo que convierte las llamadas dispersas, incluidos los reintentos, en una sola unidad que puedes valorar.
Las trazas aterrizan en un almacén de trazas dentro de tu propio entorno, escrito conforme a convenciones de OpenTelemetry para que tu análisis de costes no quede rehén del formato de exportación de un único proveedor. Una traza reúne cada llamada al modelo, cada llamada a herramienta, cada recuperación y cada reintento de un intento de tarea bajo un mismo identificador. Suma el coste en tokens a lo largo de la traza, divide entre las tareas que de verdad se completaron correctamente, y tienes el coste por tarea completada por flujo de trabajo. La torre de control es lo que hace que los reintentos, los callejones sin salida y la recuperación pesada aparezcan como partidas en lugar de desaparecer en una media plana por token.
Regla práctica: si no puedes señalar la traza que produjo una cifra de coste, la cifra es una estimación, no una medición. Y una estimación es exactamente donde vive el coste oculto.
A partir de ahí, la optimización consiste sencillamente en leer las trazas y actuar: qué flujos de trabajo tienen una cola de reintentos, cuáles arrastran demasiado contexto de recuperación, cuáles envían trabajo fácil a un modelo caro. Eso alimenta las mismas analíticas de flujo de trabajo que leen finanzas y operaciones (coste por flujo de trabajo, tasa de éxito, motivos de escalado), y es la misma base de evidencia descrita en coste por tarea completada. La torre de control convierte una factura oculta por token en una visible por flujo de trabajo que realmente puedes reducir.
Preguntas frecuentes
¿Es el coste por token alguna vez la métrica correcta?
Para una única llamada de un solo paso (una clasificación, un resumen corto), el coste por token y el coste por tarea están lo bastante cerca como para tratarlos como el mismo número. La métrica se rompe precisamente cuando una tarea abarca varias llamadas al modelo, ciclos de ida y vuelta a herramientas, recuperación o reintentos, que es la definición de un flujo de trabajo agéntico. Para los agentes, mide el coste por tarea completada y conserva las tarifas por token solo como entrada de ese cálculo.
¿Realmente añaden los reintentos tanto coste?
Añaden más de lo que sugiere el recuento bruto de tokens. Un reintento reenvía el contexto, que crece (incluidos los documentos recuperados), vuelve a pagar la sobrecarga de prompt de sistema del uso de herramientas y no produce nada si también falla. Un flujo de trabajo con una tasa de fallo del 30 por ciento está pagando el coste completo en tokens por tres de cada diez intentos que el negocio descarta, lo que infla el coste por tarea exitosa incluso cuando cada llamada individual parece barata. Reducir la tasa de fallo suele ser la palanca individual más grande sobre el coste por tarea completada.
¿Puedo obtener esta visibilidad sin enviar datos a un proveedor de observabilidad de terceros?
Sí, y para cargas de trabajo reguladas deberías. La medición, las trazas y las analíticas pueden ejecutarse íntegramente dentro de tu propia nube, VPC o entorno on-prem, escritas conforme a convenciones de OpenTelemetry para que sigan siendo portables. Eso mantiene el contenido sensible de prompts y resultados de herramientas dentro de tu perímetro y, aun así, da a finanzas e ingeniería las cifras de coste por tarea completada que necesitan. Consulta nuestra postura de seguridad y la visión general de la plataforma para ver cómo se configura esto. Más sobre el patrón general en nuestros insights.