← Todos os textos

Observações sobre o consumo de tokens dos agentes de IA

Nesta página

Um novo artigo de investigadores de Stanford, Michigan, DeepMind, All Hands, Microsoft AI e MIT é o estudo empírico aberto mais detalhado que vi sobre como os agentes de IA gastam tokens à escala1. Os autores correm oito modelos de fronteira em 500 tarefas do SWE-bench Verified, com quatro execuções cada, e registam a telemetria completa das trajetórias, decomposta por tipo de token, fase e ação. Publicam o conjunto de dados junto com o artigo, que é, que eu saiba, o corpus público mais granular de trajetórias de agentes que existe neste momento.

O artigo é rigoroso, cuidadoso com o que afirma e põe números concretos em perguntas a que até agora só se respondia com anedotas. Recomendo que o leias na íntegra.

O que se segue é um percurso por quatro das observações do artigo, intercalado com o que vemos na Flowstate, onde os mesmos padrões aparecem em ambientes de clientes. Estamos no caminho do pedido entre o utilizador e o fornecedor de IA, o que quer dizer que observamos as mesmas trajetórias que o artigo analisa, mas em produção e numa gama de ferramentas de IA muito mais larga do que o SWE-bench cobre.

Os dois conjuntos de observações são notavelmente próximos. Os investigadores mediram-no num benchmark. Nós vemo-lo em dispositivos de clientes. A concordância entre os dois é o que torna este artigo tão útil para quem tenta mesmo gerir esta despesa.

Os tokens de entrada dominam a despesa dos agentes

A primeira conclusão do artigo é que a programação com agentes consome cerca de 1 000 vezes mais tokens do que tarefas equivalentes de chat de código ou raciocínio de código, com uma razão entrada/saída de aproximadamente 153:1 (contra 1,33 no chat e 0,16 no raciocínio)2.

A razão é estrutural. Os fluxos de trabalho com agentes acumulam contexto ao longo das rondas, e o mesmo conteúdo volta a entrar no modelo em cada turno. A cache de tokens ajuda nas margens, mas o volume de contexto acumulado domina o custo.

É exatamente o padrão que vemos também na utilização de IA sem agentes. O uso em estilo chat do Claude, do ChatGPT e de ferramentas parecidas tem a mesma forma, porque os utilizadores continuam as conversas ao longo de dias em vez de começarem sessões novas com contexto explícito. Um cliente descreveu-nos isto assim:

“We think they’re creating PowerPoints, and then they’re like, ‘change this word on slide three’, and then they’re just continuing to generate these really large documents.”

É a conclusão do artigo em versão humana. Uma sessão de chat que devia ter sido um prompt novo torna-se um fio que volta a pagar o histórico inteiro em cada turno. O utilizador acha que está a fazer uma pequena edição. Ao modelo pede-se que reprocesse o documento todo. O fornecedor cobra em conformidade.

A implicação é que uma fatia enorme do custo de IA que se pode controlar está a montante do modelo. Melhores prompts. Sessões novas. Contexto explícito dado uma vez, em vez de construído aos poucos ao longo de uma tarde. O comportamento do agente é, em grande parte, consequência de como foi configurado.

A escolha do modelo produz diferenças de custo de uma ordem de grandeza

Nas 230 tarefas do SWE-bench que todos os modelos testados resolveram com sucesso, o Kimi-K2 e o Claude Sonnet 4.5 usaram em média mais 1,5 milhões de tokens do que o GPT-53. Os mesmos problemas, as mesmas respostas certas, apetites de tokens completamente diferentes.

O artigo tem o cuidado de excluir a explicação óbvia: a diferença de custo mantém-se tanto no subconjunto de sucessos partilhados como no de falhas partilhadas. Os modelos mais caros não estavam a atacar problemas mais difíceis. Estavam simplesmente a gastar mais tokens nos mesmos problemas.

Isto bate com um comportamento que observamos de forma consistente. Os utilizadores usam por omissão o modelo mais proeminente na interface, e “mais proeminente” costuma querer dizer o mais caro. Opus quando o Sonnet teria feito o trabalho. Os fornecedores não têm incentivo comercial para encaminhar os utilizadores para modelos mais baratos. De outra conversa com um cliente:

“We definitely know that people are using just all Opus. The people that are using up their tokens, they’ll continue to do that unless there’s a way to control it. We did not know there was a way to control that in Claude. I know there isn’t.”

Há maneira de o controlar, mas não vive no produto do fornecedor. O sítio natural é a camada que consegue ver a categoria da tarefa e encaminhar ao nível do pedido: o trabalho repetitivo para o modelo mais leve, o planeamento longo para o mais pesado. A conclusão de Stanford de que a eficiência em tokens é uma propriedade do modelo e não da tarefa é precisamente o que torna o encaminhamento viável. Se os modelos pesados só gastassem mais tokens em problemas mais difíceis, o encaminhamento seria inútil. Não gastam, por isso não é.

O uso de tokens é muito variável e difícil de prever

A terceira observação do artigo é que quatro execuções do mesmo modelo na mesma tarefa podem produzir uma variação de até 30 vezes no custo total em tokens4. A execução mais cara num dado problema custa, em média, cerca do dobro da mais barata. Quanto mais o custo sobe, menos previsível ele é.

Mais ao ponto: os autores testam se os agentes conseguem prever o seu próprio uso de tokens antes de executarem uma tarefa. Encontraram correlações de 0,39 no melhor caso. Os oito modelos subestimam sistematicamente5. Nem o próprio agente sabe quanto vai custar uma tarefa.

O que vemos do lado dos clientes são líderes a tentar gerir a despesa com os únicos dados de que dispõem. Normalmente uma contagem de chats do painel de administração do fornecedor:

“What are these five people doing? They’re always saying they don’t have enough tokens.”

Uma contagem de chats não responde a isto. Uma contagem de tokens diz quanto se gastou, mas não porquê. O “porquê” é estruturalmente invisível na fatura. Só se vê na camada do pedido, onde o trabalho real é observável. Nenhuma previsão antecipada vai fechar a diferença, porque o próprio trabalho é estocástico.

Custo mais alto não dá mais precisão

O artigo divide as execuções em quartis de custo e conclui que a precisão atinge o pico no segundo quartil mais barato e estabiliza a partir daí. As execuções mais caras não dão melhores resultados do que as de preço moderado6.

Os autores atribuem isto a um padrão de comportamento específico: no quartil de custo mais alto, as modificações repetidas de ficheiros são cerca de 4 vezes mais frequentes do que no quartil mais barato, e as visualizações repetidas de ficheiros são 2 vezes mais frequentes7. As execuções caras não estão a fazer mais trabalho. Estão a fazer o mesmo trabalho, outra vez, nos mesmos ficheiros.

O artigo descreve isto, com delicadeza, como “unproductive exploration rather than deeper reasoning.” Vemos a mesma forma na utilização de IA que não é de programação. Regeneração repetida do mesmo artefacto com alterações marginais. Sessões longas em que o utilizador deixou de estar presente há horas. Prompts idênticos reenviados depois de corrigir uma gralha. Nada disto são falhas do agente. São padrões que vêm do utilizador e que o agente herda.

A lacuna de medição

Nenhum dos padrões acima pode ser tratado à escala sem medição na camada do pedido. Os painéis dos fornecedores agregam por ferramenta e por tenant. Os gateways de IA (um proxy que fica entre ti e o teu fornecedor de IA) cobrem o encaminhamento em produção do lado do servidor. As ferramentas de eficácia de engenharia cobrem assistentes de programação limitados e ficam por aí.

Construímos a Flowstate porque a camada de medição necessária para agir sobre estes padrões não existia em lado nenhum da stack.

A Flowstate observa cada chamada de IA que um utilizador faz, seja o ChatGPT no navegador, o Claude Code no terminal, o Midjourney para imagens ou o Suno para áudio, e liga cada chamada a um utilizador, projeto, modelo e classe de custo8. Os clientes mantêm os seus próprios contratos e as suas próprias chaves de API com cada fornecedor que usam. Não vendemos acesso a IA e não restringimos as ferramentas a que as pessoas podem recorrer.

Essa posição arquitetural tem consequências além da medição de custos. A mesma instrumentação que revela o desperdício de tokens revela também padrões que importam para a segurança. Prompts com dados pessoais de clientes a seguir para uma ferramenta de IA de consumo. Código-fonte colado no ChatGPT. Funcionários a correr projetos pessoais na subscrição da empresa. Vemos isto no terreno só porque a camada do pedido é o único sítio onde são visíveis.

O artigo de Stanford faz um argumento económico limpo a partir de um benchmark. As nossas observações fazem exatamente o mesmo argumento a partir de ambientes empresariais reais. Os padrões que fazem subir o custo da IA são grandes, mensuráveis e consistentes. Só precisas da canalização para os ver.

Footnotes

  1. Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., and Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750v2. Os autores reconhecem trabalho em paralelo sobre a distribuição de tokens em sistemas multiagente (Salim et al. 2026, Wang et al. 2025) e sobre a dinâmica de preços em modelos de raciocínio (Chen et al. 2026), mas a combinação de escala, granularidade e publicação aberta dos dados faz deste o artigo mais útil que vi para perceber como é a despesa com agentes na realidade. Os autores publicam também um site do projeto com o conjunto de dados das trajetórias, um repositório de código de análise para replicar as figuras, e um jogo interativo giro, o Can You Guess the Token Cost?, que mostra a conclusão principal do artigo em cerca de trinta segundos. ↩

  2. Bai et al., Figura 1. A programação com agentes tem em média 4,17M de tokens por tarefa e um custo de 1,86 $, contra 3,39k tokens nas tarefas de chat de código e 1,19k tokens no raciocínio de código de um só turno. O valor de 1 000 vezes é a razão face ao raciocínio. Face ao chat é de aproximadamente 1 200 vezes. ↩

  3. Bai et al., Figura 6 e Secção 4. A Secção 4 trata especificamente a objeção de que “as tarefas mais difíceis custam naturalmente mais”, mostrando que a diferença se mantém no subconjunto de sucessos partilhados (n=230 tarefas resolvidas por todos os modelos testados). Os autores descrevem a diferença como “model-specific behaviour rather than intrinsic task difficulty.” ↩

  4. Bai et al., Figura 2a e 2b. Variação de até 30 vezes entre instâncias. Na mesma tarefa, ao longo de quatro execuções, a mais cara custa em média cerca de 2 vezes a mais barata. ↩

  5. Bai et al., Figura 10 e Figura 11. A melhor correlação entre os oito modelos é 0,39 (Claude Sonnet 4.5, tokens de saída). A previsão de tokens de entrada é sempre pior do que a de tokens de saída. Todos os modelos subestimam sistematicamente. A Figura 11 mostra as previsões agrupadas bem abaixo da diagonal em toda a linha. ↩

  6. Bai et al., Figura 3b. A precisão aumenta de forma significativa do quartil mais barato para o segundo mais barato e depois estabiliza. O terceiro e o quarto quartis não se distinguem estatisticamente do segundo. ↩

  7. Bai et al., Figura 4 e Apêndice A. Coeficientes de regressão de efeitos mistos de aproximadamente 4x para modificações repetidas e 2x para visualizações repetidas no quartil de custo mais alto, ambos significativos com p < 0,001 face ao grupo de custo mínimo, controlando para a identidade do modelo. A análise de tokens de saída no apêndice mostra o mesmo padrão. ↩

  8. Flowstate. Cofundei-a, por isso aplica-se a óbvia declaração de conflito de interesses. ↩