← Todos os textos

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

Nesta página

Um novo artigo de pesquisadores de Stanford, Michigan, DeepMind, All Hands, Microsoft AI e MIT é o estudo empírico aberto mais detalhado que já vi sobre como os agentes de IA realmente gastam tokens em escala1. Os autores rodam oito modelos de fronteira em 500 tarefas do SWE-bench Verified, com quatro execuções cada, e capturam a telemetria completa das trajetórias, decomposta por tipo de token, fase e ação. Eles liberam o conjunto de dados junto com o artigo, que é, até onde sei, o corpus público mais granular de trajetórias de agentes disponível hoje.

O artigo é rigoroso, cuidadoso com o que afirma e coloca números concretos em perguntas que até agora só tinham resposta em anedotas. Recomendo ler inteiro.

O que vem a seguir é um passeio por quatro das observações do artigo, intercaladas com o que a gente vê na Flowstate, com exatamente os mesmos padrões aparecendo nos ambientes dos clientes. Ficamos no caminho da requisição entre o usuário e o provedor de IA, o que quer dizer que observamos as mesmas trajetórias que o artigo analisa, só que em produção e numa gama de ferramentas de IA muito mais ampla do que a do SWE-bench.

Os dois conjuntos de observações são surpreendentemente próximos. Os pesquisadores mediram num benchmark. A gente vê nos dispositivos dos clientes. A concordância entre os dois é o que torna o artigo tão útil para quem tenta de fato gerenciar esse gasto.

Tokens de entrada dominam o gasto dos agentes

A primeira descoberta do artigo é que programar com agentes consome cerca de 1.000 vezes mais tokens do que tarefas equivalentes de chat de código ou de raciocínio sobre código, com uma razão de entrada para saída de aproximadamente 153:1 (contra 1,33 do chat e 0,16 do raciocínio)2.

O motivo é estrutural. Os fluxos de trabalho com agentes acumulam contexto a cada rodada, e o mesmo conteúdo volta para o modelo em todo turno. O cache de tokens ajuda na margem, mas o volume de contexto acumulado domina o custo.

É exatamente o padrão que vemos também no uso de IA sem agentes. O uso em estilo de chat do Claude, do ChatGPT e de ferramentas parecidas tem o mesmo formato, porque as pessoas continuam conversas ao longo de dias em vez de abrir sessões novas com o contexto explícito. Um cliente descreveu assim para a gente:

“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.”

Essa é a descoberta do artigo em forma humana. Uma sessão de chat que deveria ter sido um prompt novo vira uma conversa que paga de novo por todo o seu histórico a cada turno. O usuário acha que está fazendo uma pequena edição. Estão pedindo ao modelo que reprocesse o documento inteiro. O fornecedor cobra de acordo.

A implicação é que uma fatia enorme do custo controlável de IA fica antes do modelo. Prompts melhores. Sessões novas. Contexto explícito fornecido 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 ele foi configurado.

A escolha do modelo gera 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 1,5 milhão de tokens a mais que o GPT-53. Mesmos problemas, mesmas respostas corretas, apetites por token muito diferentes.

O artigo tem o cuidado de descartar a explicação óbvia: a diferença de custo persiste tanto no subconjunto de sucessos em comum quanto no de falhas em comum. Os modelos mais caros não estavam enfrentando problemas mais difíceis. Estavam só gastando mais tokens nos mesmos problemas.

Isso bate com um comportamento que observamos o tempo todo. As pessoas usam por padrão o modelo mais em evidência na interface, e “mais em evidência” costuma significar o mais caro. Opus quando o Sonnet daria conta. Os fornecedores não têm nenhum incentivo comercial para empurrar o usuário 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.”

Existe um jeito de controlar, mas ele não mora no produto do fornecedor. O lugar natural é a camada que enxerga a categoria da tarefa e roteia no nível da requisição: o trabalho repetitivo para o modelo mais enxuto, o planejamento longo para o mais pesado. A descoberta de Stanford de que a eficiência de tokens é propriedade do modelo, e não da tarefa, é justamente o que torna o roteamento viável. Se os modelos mais pesados só gastassem mais tokens em problemas mais difíceis, o roteamento seria inútil. Não gastam, então 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 até 30x de variação no custo total em tokens4. A execução mais cara de um dado problema custa, em média, cerca de o dobro da mais barata. Quanto mais o custo sobe, menos previsível ele fica.

E mais: os autores testam se os agentes conseguem prever o próprio uso de tokens antes de executar uma tarefa. A melhor correlação que encontraram foi de 0,39. Todos os oito modelos subestimam de forma sistemática5. Nem o agente sabe quanto uma tarefa vai custar.

O que vemos do lado dos clientes é a liderança tentando gerenciar o gasto com os únicos dados que tem. Em geral, uma contagem de chats vinda do painel de administração do fornecedor:

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

Contagem de chats não responde a isso. Contagem de tokens responde quanto foi gasto, mas não por quê. O “porquê” é estruturalmente invisível na fatura. Só dá para ver na camada da requisição, onde o trabalho de fato é observável. Nenhuma previsão antecipada vai fechar essa lacuna, porque o próprio trabalho é estocástico.

Custo maior não traz acurácia maior

O artigo divide as execuções em quartis de custo e descobre que a acurácia atinge o pico no segundo quartil mais barato e estaciona dali em diante. As execuções mais caras não entregam resultados melhores do que as de preço moderado6.

Os autores atribuem isso a um padrão de comportamento específico: no quartil de maior custo, as modificações repetidas de arquivo são cerca de 4x mais frequentes do que no quartil mais barato, e as visualizações repetidas de arquivo são 2x mais frequentes7. As execuções caras não estão fazendo mais trabalho. Estão fazendo o mesmo trabalho, de novo, nos mesmos arquivos.

O artigo descreve isso com educação como “exploração improdutiva em vez de raciocínio mais profundo”. Vemos o mesmo formato no uso de IA que não é de programação. Regeneração repetida do mesmo artefato com mudanças marginais. Sessões longas em que o usuário perdeu o interesse horas atrás. Prompts idênticos reenviados depois de corrigir um erro de digitação. Nada disso é falha do agente. São padrões guiados pelo usuário que o agente herda.

A lacuna de medição

Nenhum dos padrões acima pode ser tratado em escala sem medição na camada da requisição. Os painéis dos fornecedores agregam por ferramenta e por tenant. Os gateways de IA (um proxy que fica entre você e o seu provedor de IA) cobrem o roteamento de produção no lado do servidor. As ferramentas de eficácia de engenharia cobrem assistentes de código restritos e param aí.

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

A Flowstate observa cada chamada de IA que um usuário faz, seja o ChatGPT no navegador, o Claude Code no terminal, o Midjourney para imagens ou o Suno para áudio, e amarra cada chamada a um usuário, projeto, modelo e classe de custo8. Os clientes mantêm os próprios contratos e as próprias chaves de API com cada provedor que usam. A gente não vende acesso a IA e não restringe as ferramentas que as pessoas podem usar.

Essa posição de arquitetura tem consequências além da medição de custo. A mesma instrumentação que expõe o desperdício de tokens também expõe padrões que importam para a segurança. Prompts com dados pessoais de clientes indo para uma ferramenta de IA de consumo. Código-fonte colado no ChatGPT. Funcionários tocando projetos paralelos na assinatura da empresa. A gente vê isso no campo só porque a camada da requisição é o único lugar onde essas coisas ficam 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 corporativos reais. Os padrões que movem o custo de IA são grandes, mensuráveis e consistentes. Você só precisa da infraestrutura para enxergá-los.

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 trabalhos paralelos 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 abertura dos dados faz deste o artigo mais útil que já vi para entender como é de fato o gasto com agentes. Os autores também publicam 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 joguinho interativo bem divertido, o Can You Guess the Token Cost?, que crava a principal descoberta do artigo em uns trinta segundos. ↩

  2. Bai et al., Figura 1. A programação com agentes tem média de 4,17 M de tokens por tarefa e US$ 1,86 de custo, contra 3,39 mil tokens nas tarefas de chat de código e 1,19 mil tokens no raciocínio de código em um só turno. O número de 1.000x é a razão contra o raciocínio. Contra o chat, é de cerca de 1.200x. ↩

  3. Bai et al., Figura 6 e Seção 4. A Seção 4 trata especificamente da objeção “tarefas mais difíceis naturalmente custam mais”, mostrando que a diferença persiste no subconjunto de sucessos em comum (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., Figuras 2a e 2b. Até 30x de variação entre instâncias. Na mesma tarefa, ao longo de quatro execuções, a mais cara custa em média cerca de 2x a mais barata. ↩

  5. Bai et al., Figuras 10 e 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 que a de tokens de saída. Todo modelo subestima de forma sistemática. A Figura 11 mostra as previsões agrupadas bem abaixo da diagonal em todos os casos. ↩

  6. Bai et al., Figura 3b. A acurácia sobe de forma significativa do quartil mais barato para o segundo mais barato e depois estaciona. O terceiro e o quarto quartis não são estatisticamente distinguíveis do segundo. ↩

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

  8. Flowstate. Eu sou cofundador, então vale a divulgação óbvia de conflito de interesses. ↩