Cloud Intelligence™
Mais tokens, menos dinheiro: por que a contagem de tokens ranqueia o custo dos agentes de IA ao contrário
Uma comparação de um dia, em uma única conta, entre seis workloads de agentes mostrou que foi o custo de compute, e não o volume de tokens, que definiu quais eram os mais baratos.
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
Os valores foram lidos de capturas de tela do dashboard ao vivo de uma conta sandbox da DoiT, não modelados a partir de uma tabela de preços.
Mais tokens, menos dinheiro: por que a contagem de tokens ranqueia o custo dos agentes de IA ao contrário
TL;DR: Contagem de tokens e custo de agentes de IA podem apontar em direções opostas. Em um sandbox real da AWS, em 15/08/2026, os três agentes com mais tokens eram os três mais baratos de rodar, e os três com menos tokens eram os três mais caros: uma inversão completa. O motivo é o compute, não os tokens: cada agente roda como seu próprio serviço Fargate de longa duração, e o Fargate representou de 57% a 80% do custo diário nos três workloads com detalhamento completo de recursos — e apenas 26% em um quarto workload, mais leve. O AWS Cost Explorer simplesmente não consegue mostrar o custo por agente: ele agrupa todos os agentes em uma única linha no nível de serviço. É o detalhamento de recursos por workload que revela o ranking por trás da fatura.
Se você ranqueia o custo de agentes de IA pelo consumo de tokens, pode estar ordenando tudo exatamente ao contrário.
Em 15/08/2026 (UTC), um dia já consolidado na nossa conta doit-apj-attribute-sandbox em
us-east-1, os três agentes com maior volume de tokens de uma aplicação eram também os três mais baratos, e
os três com menor volume de tokens eram os três mais caros. A diferença de tokens entre
esses grupos chega a um fator de duas vezes e meia — e aponta na direção oposta
à dos dólares. O arredondamento dos valores exibidos não chega nem perto de
explicar essa diferença.
Cada valor em dólares e cada contagem de tokens abaixo foi lido diretamente de cinco capturas de tela dessa conta sandbox: um relatório ao vivo do AWS Cost Explorer e quatro visualizações ao vivo do DoiT Attribute. Nenhum deles foi modelado a partir de tabela de preços. Os percentuais e as taxas por milhão são cálculos nossos sobre os valores exibidos, sinalizados como tal onde aparecem, e a nota de rodapé de "estimated charges" (cobranças estimadas) do próprio Cost Explorer se aplica à sua coluna. Uma sexta imagem, mais adiante no post, é um diagrama de arquitetura ilustrativo, não uma captura de dashboard.
O que o AWS Cost Explorer não consegue te dizer sobre o custo de agentes de IA
Comece pelo AWS Cost Explorer daquele dia: granularidade diária, agrupado por serviço, custos amortizados.
A coluna de 15/08/2026:
Total costs $9.98Elastic Container Service $5.99Claude Haiku 4.5 (Bedrock Edition) $2.24VPC $1.01Claude Opus 5 (Bedrock Edition) $0.70Correto — e inútil para essa pergunta. Todos os agentes da aplicação dividem aquela
única linha de $5.99 do Fargate e aquela única linha de $2.24 do Haiku. A fatura tem uma dimensão
de serviço e uma dimensão de conta. Ela não tem dimensão de agente, então não consegue ranquear
agentes de jeito nenhum, em nenhuma direção.
Repare nas notas de rodapé do próprio relatório: as datas estão em UTC, e os valores do período de faturamento atual aparecem sinalizados como estimados.
A inversão no custo dos agentes de IA
No mesmo dia, no Attribute na granularidade de workload, filtrado para os workloads
luminara-* da conta sandbox:
O total Cost (1 Day) $8.8 dessa própria visualização é a soma dos sete workloads luminara-*
mostrados aqui, filtrados para essa única conta. Ele não é comparável ao total de
$9.98 do Cost Explorer acima, que cobre todos os custos da conta, e não
apenas o gasto de Fargate e de modelo desses sete workloads.
Lendo os seis workloads luminara-* de orquestração e especialistas dessa lista:
| Workload | Tokens | Custo | Ranking de tokens | Ranking de custo |
|---|---|---|---|---|
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 |
O agrupamento é uma inversão perfeita. Os três workloads com menos tokens são os
três de maior custo, e os três com mais tokens são os três de
menor custo. O par mais gritante é luminara-route contra
luminara-orchestrator: 2,5 vezes mais tokens e $0.25 a menos no dia.
Os três primeiros estão a até $0.02 uns dos outros, então a ordem interna deles não é significativa nessa precisão de exibição. A inversão no nível de grupo é muito maior que essa margem.
Se o seu dashboard é um contador de tokens, essa aplicação parece dominada
pelo luminara-route — que, na verdade, é o mais barato dos seis.
Por que o compute, e não os tokens, decide o ranking de custo dos agentes de IA
Cada agente luminara-* roda como seu próprio serviço ECS Fargate de longa duração, que
chama o Bedrock para inferência. Esse fato estrutural é o motivo de existir uma linha de Fargate,
separada da linha do modelo: o Fargate cobra pelo compute provisionado ao longo do
tempo, o Bedrock cobra por token consumido, e esses são dois eixos de custo independentes.
- O cliente envia uma requisição ao serviço ECS Fargate do agente.
- O serviço Fargate executa o loop do agente e chama o Amazon Bedrock para a inferência do LLM.
- O Bedrock retorna a resposta do modelo ao serviço Fargate.
- Apenas no caso do
luminara-toolcall, o serviço Fargate chama o Bedrock AgentCore Gateway para invocar ferramentas. - O Gateway distribui a chamada para três funções Lambda por trás de quatro ferramentas.
- Apenas no caso do
luminara-orchestrator, o serviço Fargate grava eventos de auditoria na fila SQSluminara-trajectory-audit. - O serviço Fargate retorna a resposta final ao cliente.
O Attribute divide cada workload em seus recursos. Os detalhamentos dos dois extremos explicam a inversão.
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%O luminara-route realmente gasta mais com o modelo: $0.53 contra $0.30. Mesmo
assim, ele perde, porque a linha de Fargate do orchestrator é de $1.18 contra
$0.70 do route.
Os percentuais nessas duas capturas (20%, 13%, 12%, 24%) são a
métrica Resource Accountability do próprio Attribute por linha de recurso, não uma participação
no custo do workload; eles estão reproduzidos exatamente como exibidos. As participações de Fargate abaixo são
cálculo nosso sobre os totais em dólares — um número diferente.
Calculando as participações a partir desses valores:
| Workload | Fargate | Modelo | Participação do Fargate |
|---|---|---|---|
luminara-orchestrator |
$1.18 | $0.30 | 80% |
luminara-route |
$0.70 | $0.53 | 57% |
O compute é a maior parte do custo diário nos dois casos, e é a variável que decide o ranking. Os tokens são o termo minoritário que um dashboard baseado em tokens trata como se fosse a história inteira.
O luminara-dining descarta a hipótese de coincidência entre dois pontos:
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%Ele mostra a mesma linha de Fargate de $0.70 do luminara-route — dois serviços especialistas
dimensionados de forma parecida — enquanto o orchestrator fica em $1.18. Um quarto workload, o
luminara-toolcall, fica em $0.24 de Fargate em um dia de $0.93, ou 26%, no
extremo inferior do mesmo espectro. O detalhamento de recursos por trás desse valor está
preservado no conjunto de evidências, mas não é reproduzido neste post.
Não estamos apresentando a dominância do compute como uma descoberta nova. Uma captura de dashboard de
30 dias preservada, encerrada em 21/08/2026, já havia medido a participação de EC2-ECS do
luminara-orchestrator em 71%, e nós a citamos apenas para mostrar o mesmo padrão se mantendo em uma
janela diferente. O que é novo aqui é a consequência. Como o termo de compute
domina e varia conforme o papel do workload, ele decide o ranking — e o ranking que ele
produz é o inverso do ranking de tokens. Não fazemos nenhuma afirmação sobre arquiteturas
além desses workloads.
O terceiro recurso do orchestrator, o luminara-trajectory-audit, é uma linha de
AWSQueueService em $0.00. O Attribute mantém o recurso no inventário mesmo quando ele
não custa nada naquele dia — e é justamente assim que você descobre que esse agente tem uma dependência
de fila.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
O que isso significa para acompanhar o custo de agentes de IA
Contagem de tokens não é proxy do custo total de agentes de IA
Ela é um proxy de custo para a linha do modelo — e, nos três workloads que detalhamos,
a linha do modelo ficou entre 20% e 43% do custo diário do workload. Qualquer
visão de custo por agente construída puramente sobre objetos usage vai errar o ranking da frota sempre
que os footprints de compute forem diferentes, ou seja, sempre que os agentes diferirem no papel de orquestração,
como um orchestrator central contra workloads especialistas de escopo mais restrito.
Ranquear agentes de IA por custo exigiu uma visão de compute por workload
A contabilização de tokens do lado do cliente não enxerga o Fargate de jeito nenhum. A fatura enxerga o Fargate e o agrupa em uma única linha. A divisão por workload acima é a contribuição específica do Attribute aqui — e foi ela que inverteu a resposta.
Nada disso transforma esta análise em um ranking de eficiência. Esses workloads fazem trabalhos diferentes com volumes de requisições diferentes; o que está medido aqui é o custo diário por workload, não o custo por requisição, por objetivo concluído ou por unidade de qualidade. Mais barato por dia não é o mesmo que mais barato por unidade de trabalho.
FAQ
Consumir mais tokens significa um custo maior por agente de IA? Não necessariamente. Nesta análise, os três agentes com mais tokens foram os três mais baratos de rodar, e os três com menos tokens foram os três mais caros. O volume de tokens acompanha apenas a linha do modelo, não o custo total de rodar o agente.
Por que o AWS Cost Explorer não consegue mostrar o custo por agente de IA? O Cost Explorer agrupa por serviço e por conta, não por agente. Todos os agentes de uma aplicação compartilham as mesmas linhas de Fargate e de Bedrock, então não existe na fatura uma dimensão para dividir o custo por agente individual.
O que decide o custo de um agente de IA, se não são os tokens? O compute. Nos três workloads com detalhamento completo de recursos, a linha de compute do Fargate ficou entre 57% e 80% do custo diário, contra 20% a 43% da linha do modelo; a participação de Fargate de um quarto workload, mais leve, foi de apenas 26%. O custo varia conforme o papel de orquestração, não conforme a quantidade de tokens que um workload consome.
Como medir o custo por agente de IA em infraestrutura compartilhada? Dividindo cada workload em seus recursos subjacentes — como compute, chamadas de modelo e qualquer outro recurso cobrado, como uma fila — em vez de depender de contagens de tokens ou de uma linha de faturamento agrupada. O Attribute faz isso no nível do workload usando dados de runtime em vez de tags.
A estimativa de custo baseada em tokens é confiável para sistemas de IA agênticos? Não por si só. Tokens são um proxy apenas para a linha do modelo. Uma visão só de tokens pode errar o ranking dos workloads quando os custos de compute deles diferem, como aconteceu com os seis workloads medidos aqui.
Acertar o custo de agentes de IA exige uma visão de compute por workload, não uma contagem de tokens.
