Cloud Intelligence™
Más tokens, menos dinero: por qué contar tokens ordena al revés el costo de tus agentes de IA
Una comparación de un día, en una sola cuenta, entre seis workloads de agentes reveló que el costo de cómputo, y no el volumen de tokens, determinó cuáles eran los más baratos.
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
Las cifras se leyeron directamente de capturas de pantalla del dashboard de una cuenta sandbox de DoiT; no se modelaron a partir de una tabla de precios.
Más tokens, menos dinero: por qué contar tokens ordena al revés el costo de tus agentes de IA
TL;DR: El conteo de tokens y el costo de los agentes de IA pueden apuntar en direcciones opuestas. En un sandbox real de AWS, el 2026-08-15, los tres agentes con más tokens fueron los tres más baratos de ejecutar, y los tres con menos tokens, los tres más caros: una inversión total. La razón es el cómputo, no los tokens: cada agente corre como su propio servicio Fargate de larga ejecución, y Fargate representó entre el 57 y el 80% del costo diario de los tres workloads con desglose completo de recursos, y apenas el 26% en un cuarto workload más liviano. AWS Cost Explorer no puede mostrar el costo por agente; agrupa a todos los agentes en una sola fila a nivel de servicio. Un desglose de recursos por workload es lo que revela el ranking detrás de la factura.
Si ordenas el costo de tus agentes de IA por consumo de tokens, puede que lo estés ordenando exactamente al revés.
El 2026-08-15 UTC, un día ya consolidado en nuestra cuenta doit-apj-attribute-sandbox en
us-east-1, los tres agentes con más tokens de una aplicación fueron también los tres más baratos, y
los tres con menos tokens, los tres más caros. La brecha de tokens entre
esos grupos llega a un factor de dos y medio, y va en sentido contrario al de
los dólares. El redondeo en pantalla ni de lejos alcanza para explicar algo así.
Cada cifra en dólares y tokens que verás a continuación se leyó directamente de cinco capturas de pantalla de esa cuenta sandbox: un reporte en vivo de AWS Cost Explorer y cuatro vistas en vivo de DoiT Attribute. Ninguna se modeló a partir de una tabla de precios. Los porcentajes y las tasas por millón son cálculos propios sobre esas cifras mostradas, señalados como tales donde aparecen, y la nota al pie de "cargos estimados" del propio Cost Explorer aplica a su columna. Una sexta imagen, más adelante en el post, es un diagrama de arquitectura ilustrativo, no una captura de dashboard.
Lo que AWS Cost Explorer no puede decirte sobre el costo de tus agentes de IA
Empecemos con AWS Cost Explorer para ese día: granularidad diaria, agrupado por servicio, costos amortizados.
La columna del 2026-08-15:
Total costs $9.98Elastic Container Service $5.99Claude Haiku 4.5 (Bedrock Edition) $2.24VPC $1.01Claude Opus 5 (Bedrock Edition) $0.70Correcto, e inútil para esta pregunta. Todos los agentes de la aplicación comparten esa
única fila de Fargate de $5.99 y esa única fila de Haiku de $2.24. La factura tiene una dimensión
de servicio y una dimensión de cuenta. No tiene una dimensión de agente, así que no puede ordenar
agentes en absoluto, en ninguna dirección.
Ten en cuenta las notas al pie del propio reporte: las fechas están en UTC y las cifras del período de facturación en curso se marcan como estimadas.
La inversión del costo de los agentes de IA
El mismo día, en Attribute a nivel de workload, filtrado a los workloads
luminara-* de la cuenta sandbox:
El total Cost (1 Day) $8.8 de esa vista es la suma de los siete workloads luminara-*
que se muestran aquí, filtrados a esta única cuenta. No es comparable con el
total de $9.98 de Cost Explorer de arriba, que cubre todos los costos de la cuenta, no
solo el gasto en Fargate y en modelo de estos siete workloads.
Al leer de esa lista los seis workloads luminara-* de orquestación y especialistas:
| Workload | Tokens | Costo | Ranking por tokens | Ranking por costo |
|---|---|---|---|---|
luminara-orchestrator |
125.75K | $1.48 | 4 | 1 |
luminara-chain |
123.73K | $1.48 | 5 | 1 |
luminara-conditional |
115.27K | $1.46 | 6 | 3 |
luminara-route |
315.01K | $1.23 | 1 | 4 |
luminara-sites |
265.49K | $1.16 | 2 | 5 |
luminara-dining |
169.64K | $1.07 | 3 | 6 |
La agrupación es una inversión perfecta. Los tres workloads con menos tokens son los
tres de mayor costo, y los tres workloads con más tokens son los tres
de menor costo. El contraste más marcado es el de luminara-route frente a
luminara-orchestrator: 2.5 veces los tokens y $0.25 menos en el día.
Los tres primeros están a menos de $0.02 entre sí, así que su orden interno no es significativo con la precisión que se muestra en pantalla. La inversión a nivel de grupo es mucho mayor que ese margen.
Si tu dashboard es un contador de tokens, esta aplicación parece dominada
por luminara-route, que en realidad es el más barato de los seis.
Por qué el cómputo, y no los tokens, decide el ranking de costos de los agentes de IA
Cada agente luminara-* corre como su propio servicio ECS Fargate de larga ejecución que
llama a Bedrock para la inferencia. Ese hecho estructural es la razón de que exista una línea de Fargate,
separada de la línea del modelo: Fargate factura por cómputo aprovisionado a lo largo
del tiempo, Bedrock factura por token consumido, y esos son dos ejes de costo independientes.
- El cliente envía una solicitud al servicio ECS Fargate del agente.
- El servicio Fargate ejecuta el bucle del agente y llama a Amazon Bedrock para la inferencia del LLM.
- Bedrock devuelve la respuesta del modelo al servicio Fargate.
- Solo en el caso de
luminara-toolcall, el servicio Fargate llama al Bedrock AgentCore Gateway para invocar herramientas. - El Gateway reparte las llamadas entre tres funciones Lambda detrás de cuatro herramientas.
- Solo en el caso de
luminara-orchestrator, el servicio Fargate escribe eventos de auditoría en la cola SQSluminara-trajectory-audit. - El servicio Fargate devuelve la respuesta final al cliente.
Attribute desglosa cada workload en sus recursos. Los desgloses de los dos extremos explican la inversión.
luminara-orchestrator — Total resources cost: $1.48 (1 - 3 Out of 3)
luminara-poc EC2-ECS $1.18 20%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.30 125.75K Tokens 13%luminara-trajectory-audit AWSQueueService $0.00 --
luminara-route — Total resources cost: $1.23 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.53 315.01K Tokens 24%luminara-route sí gasta más en el modelo: $0.53 frente a $0.30. Aun
así pierde, porque la línea de Fargate del orquestador es de $1.18 frente a
los $0.70 de route.
Los porcentajes de esas dos capturas (20%, 13%, 12%, 24%) corresponden a la
métrica Resource Accountability de Attribute por fila de recurso, no a una participación
del costo del workload; se reproducen tal como se muestran. Las participaciones de Fargate de abajo son
cálculos propios sobre los totales en dólares, un número distinto.
Calculando las participaciones a partir de esas cifras:
| Workload | Fargate | Modelo | Participación de Fargate |
|---|---|---|---|
luminara-orchestrator |
$1.18 | $0.30 | 80% |
luminara-route |
$0.70 | $0.53 | 57% |
El cómputo es la mayor parte del costo diario en ambos casos, y es la variable que decide el ranking. Los tokens son el componente minoritario que un dashboard basado en tokens trata como si fuera el panorama completo.
luminara-dining descarta que se trate de una coincidencia entre dos puntos:
luminara-dining — Total resources cost: $1.07 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.38 169.64K Tokens 17%Muestra la misma línea de Fargate de $0.70 que luminara-route, dos servicios especialistas
de tamaño similar, mientras que el orquestador está en $1.18. Un cuarto workload,
luminara-toolcall, registra $0.24 de Fargate sobre un día de $0.93, es decir 26%, en el
extremo bajo del mismo espectro. El desglose de recursos detrás de esa cifra se
conserva en el conjunto de evidencia, pero no se reproduce en este post.
No estamos presentando el dominio del cómputo como un hallazgo nuevo. Una captura de dashboard
de 30 días, con cierre el 2026-08-21 y conservada como evidencia, ya había medido la participación de EC2-ECS de
luminara-orchestrator en 71%, y la citamos solo para mostrar que el mismo patrón se mantiene en
otra ventana. Lo nuevo aquí es la consecuencia. Como el componente de cómputo
domina y varía según el rol del workload, decide el ranking, y el ranking que
produce es el inverso del ranking por tokens. No hacemos ninguna afirmación sobre arquitecturas
más allá de estos workloads.
El tercer recurso del orquestador, luminara-trajectory-audit, es una fila de
AWSQueueService en $0.00. Attribute incluye el recurso en el inventario incluso cuando ese día no
cuesta nada, y así es como llegas a saber que este agente tiene una
dependencia de cola.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Qué significa esto para el seguimiento del costo de agentes de IA
Los conteos de tokens no son un proxy del costo total de un agente de IA
Son un proxy de costo para la línea del modelo, y en los tres workloads que
desglosamos, la línea del modelo representó entre el 20% y el 43% del costo diario del workload. Cualquier
vista de costo por agente construida únicamente sobre objetos usage ordenará mal la flota siempre
que los perfiles de cómputo difieran, es decir, siempre que los agentes difieran en su rol de
orquestación, como un orquestador central frente a workloads especialistas más acotados.
Ordenar los agentes de IA por costo requirió una vista del cómputo por workload
La contabilidad de tokens del lado del cliente no puede ver Fargate en absoluto. La factura ve Fargate y lo agrupa en una sola fila. El desglose por workload de arriba es el aporte concreto de Attribute en este caso, y es lo que dio vuelta la respuesta.
Nada de eso convierte esto en un ranking de eficiencia. Estos workloads hacen trabajos distintos con volúmenes de solicitudes distintos; lo que se mide aquí es el costo diario por workload, no el costo por solicitud, por objetivo completado ni por unidad de calidad. Más barato por día no es lo mismo que más barato por unidad de trabajo.
Preguntas frecuentes
¿Un mayor consumo de tokens implica un mayor costo del agente de IA? No necesariamente. En este análisis, los tres agentes con más tokens fueron los tres más baratos de ejecutar, y los tres con menos tokens, los tres más caros. El volumen de tokens refleja solo la línea del modelo, no el costo total de ejecutar el agente.
¿Por qué AWS Cost Explorer no puede mostrar el costo por agente de IA? Cost Explorer agrupa por servicio y por cuenta, no por agente. Todos los agentes de una aplicación comparten las mismas líneas de Fargate y de Bedrock, así que no existe en la factura una dimensión para dividir el costo por agente individual.
Si no son los tokens, ¿qué decide el costo de un agente de IA? El cómputo. En los tres workloads con desglose completo de recursos, la línea de cómputo de Fargate representó entre el 57 y el 80% del costo diario, frente al 20 a 43% de la línea del modelo; la participación de Fargate de un cuarto workload más liviano fue de apenas el 26%. El costo varía según el rol de orquestación, no según cuántos tokens consume un workload.
¿Cómo se mide el costo por agente de IA en infraestructura compartida? Desglosando cada workload en sus recursos subyacentes, como cómputo, llamadas al modelo y cualquier otro recurso facturado, como una cola, en lugar de depender de conteos de tokens o de una línea de facturación agrupada. Attribute hace esto a nivel de workload usando datos de ejecución en lugar de tags.
¿Es confiable la estimación de costos basada en tokens para sistemas de IA agénticos? No por sí sola. Los tokens son un proxy solo de la línea del modelo. Una vista basada únicamente en tokens puede ordenar mal los workloads cuando sus costos de cómputo difieren, como ocurrió con los seis workloads medidos aquí.
Medir bien el costo de los agentes de IA requiere una vista del cómputo por workload, no un conteo de tokens.
