Os desvios da IA pelos quais você não deveria estar pagando

Não é que as empresas de IA de ponta necessariamente deixassem de manipular os preços dos tokens a seu favor ao vendê-los para nós, se pudessem fazê-lo sem consequências — afinal, em junho, a Anthropic aplicou um aumento efetivo de 30% nos preços; em agosto, a DeepSeek elevou os preços da API; e, no fim de setembro, a OpenAI relutantemente reverteu uma redução na cota de tokens de seu plano intermediário. Portanto, uma tendência à austeridade está agora bastante evidente.

De fato, esse pensamento costuma voltar à tona quando seu agente de IA consome toda a sua cota diária de tokens em 45 minutos, numa torrente de código nem sempre glorioso, e manda você voltar daqui a 3–4 horas. Num momento tão frustrante, é difícil não se perguntar se alguns dos mecanismos envolvidos nesse processo não favorecem os provedores. Afinal, é uma boa maneira de nos fazer desembolsar dinheiro por uma recarga extra de tokens — ou até nos levar a ativar a «recarga automática».

Bem, se isso realmente acontecer, neste momento as empresas de vanguarda podem se apoiar, com bastante credibilidade, na suposição de que nós não entendemos completamente como os tokens são usados em cargas de trabalho com agentes, entre diferentes modelos e estruturas de execução. E elas também não. Com exceção dos fluxos que levam ao pagamento (que são, de fato, muito fluidos), tudo ainda está em pré-alfa e continua sendo matéria-prima para pesquisas de ponta, apesar da ampla comoditização do produto.

Gestão do desperdício

O fato de que agentes de IA desperdiçam tokens (e, portanto, seu dinheiro) ao raciocinar em fluxos de trabalho com agentes é algo já bem estabelecido: exatamente há um ano, escrevi sobre novas pesquisas que indicavam até que ponto os modelos de IA com capacidade de raciocínio tendiam a gastar tokens «divagando»; no início deste ano, escrevi sobre outras pesquisas que apontavam o raciocínio em cadeia de pensamento como «decorativo»; e, na semana passada, Nils Bunge, chefe de produto da Tsuga, declarou, em um artigo de liderança de opinião publicado aqui:

«Uma equipe que consome o dobro de tokens não está necessariamente criando o dobro do valor. Ela pode estar lidando com um trabalho mais difícil, usando um modelo desnecessariamente poderoso ou dependendo de um agente que tenta repetidamente executar tarefas sem sucesso.»

O que se sabe menos é a forma como os tokens são desperdiçados em tarefas ou processos desnecessários; esse é o foco de um novo artigo que hoje voltou a chamar minha atenção para o tema.

Intitulado Como os agentes de IA desperdiçam seu dinheiro?, este novo trabalho, fruto de uma colaboração acadêmica dos EUA*, apresenta uma estrutura unificada capaz de quantificar quanto os processos com agentes desperdiçam tokens. Nos casos em que os modelos são de código fechado, uma metodologia «sombra», combinada com as estatísticas e métricas oficiais dos provedores, permite reconstruir em detalhes o que aconteceu com os tokens enquanto a IA raciocinava e agia:

O novo método para medir o desperdício de tokens de IA. O raciocínio, as ações e os custos de cada agente são registrados e, em seguida, analisados em busca de repetições, solicitações desnecessárias e desvios evitáveis. O desperdício identificado é removido, e a capacidade do agente de concluir a tarefa original é testada novamente. Fonte

Como mostrado acima, permite-se que o agente trabalhe normalmente, interceptando e registrando as comunicações com o provedor de IA, inclusive os momentos de raciocínio, o uso de ferramentas, o consumo de tokens e os custos. Em seguida, os registros são analisados por avaliadores baseados em Large Language Model (LLM), que distinguem o trabalho útil das repetições, buscas desnecessárias e desvios. Depois disso, o desperdício suspeito é removido, calcula-se a economia de tokens e o agente retoma o trabalho para verificar se ainda consegue concluir a tarefa com sucesso.

Nos testes, os pesquisadores descobriram que cerca de 18% dos tokens de saída dos agentes eram desperdiçados. Em mais de 45% das tarefas, um agente desperdiçou mais tokens do que outro precisou para concluir o mesmo trabalho com sucesso. Também constataram que remover 41–46% do raciocínio desnecessário teve pouquíssimo efeito no desempenho, o que sugere que é possível obter economias substanciais sem comprometer significativamente os resultados.

O artigo afirma:

«Em todas as trajetórias coletadas, cerca de 18% dos tokens de saída são identificados como desperdício.»

«Surpreendentemente, em mais de 45% das tarefas, a saída desperdiçada por um único agente supera a saída total de outro agente que conclui a mesma tarefa com sucesso.»

Além disso, o estudo constatou que os agentes desperdiçaram mais recursos ao explorar ferramentas desconhecidas e seguir abordagens que, no fim, não levaram a lugar algum; também concluiu que aumentar o esforço de raciocínio não proporciona melhorias consistentes: no nível máximo de esforço, descobriu-se que o Kimi-K3 gerava 6,6 vezes mais tokens de raciocínio do que no nível baixo, sem qualquer garantia correspondente de melhores resultados.

Resultados dos testes que mostram o desempenho de Kimi-K3 em quatro níveis de esforço de raciocínio, em cinco benchmarks. Um esforço de raciocínio maior não melhorou as taxas de sucesso de forma consistente, e o esforço máximo às vezes produziu resultados piores do que configurações mais baixas.

Por analogia, em vez de dirigir um carro potente sem nunca explorar de fato todo o seu potencial, essas sessões com agentes se parecem mais com dirigir um carro que acelera até a velocidade máxima que consegue atingir em cada viagem, mesmo quando isso não traz benefício algum e apesar das possíveis consequências negativas.

O artigo também examina o papel que diferentes estruturas de execução desempenham na geração de desperdício de tokens e constata que o mesmo modelo de IA, Kimi-K3, pode gerar mais de quatro vezes mais raciocínio em tarefas idênticas, dependendo da estrutura utilizada, sem necessariamente alcançar resultados melhores.

Parte do desperdício foi atribuída a falhas básicas de software: constatou-se que OpenCode, Kimi Code CLI e OpenClaw iniciavam repetidamente tarefas no ambiente Python errado, provocando erros e novas tentativas que consumiam tokens. O Kimi Code CLI também permitia que a IA solicitasse tempos limite que o próprio software rejeitaria, obrigando-a a fazer ainda mais tentativas dispendiosas.

Ao contrário do que se poderia esperar, estruturas de execução que ofereciam mais ferramentas não eram necessariamente mais propensas ao desperdício, e algumas ineficiências recorrentes pareciam ter origem nos próprios modelos, independentemente da estrutura que os controlava.

‘[Several] características da estrutura de execução que parecem obviamente relevantes não explicam de forma consistente as diferenças observadas no desperdício. Por exemplo, como mostra [below], estruturas que disponibilizam mais ferramentas não são necessariamente mais propensas ao desperdício. A OpenClaw disponibiliza muito mais ferramentas do que as outras estruturas, mas apresenta apenas um nível moderado de desperdício. Além disso, nem todo desperdício varia conforme a estrutura de execução.

‘[Below right] demonstra que, no SWE-bench Verified, há um desvio recorrente em que Kimi-K3 escreve o que acredita ser a correção original do projeto e depois a abandona. ‘

Resultados dos testes que comparam o desperdício de tokens entre estruturas de execução de agentes de IA. À esquerda: oferecer mais ferramentas não aumenta necessariamente o desperdício. À direita: Kimi-K3 tenta repetidamente implementar uma suposta correção original de software e a abandona, independentemente da estrutura utilizada, mas raramente faz isso em outro tipo de tarefa.

Como medida corretiva, os autores sugerem que as estruturas de execução de agentes reconheçam quando restrições do ambiente tornam impossível avançar, comuniquem claramente essas limitações ao modelo de IA e interrompam a execução, em vez de permitir que tentativas repetidas e malsucedidas consumam mais tokens. Também propõem usar suas medições do desperdício de tokens para aprimorar o treinamento dos modelos, as estratégias de raciocínio e o projeto das estruturas de execução.

Metodologia

Para reconstruir a atividade de um agente de IA, os pesquisadores acompanharam cada interação entre o modelo e o software que o controlava, registrando seu raciocínio, suas respostas, as solicitações de ferramentas e os custos em tokens — com níveis de detalhamento que variavam conforme o provedor: Kimi-K3 revela todo o seu processo de raciocínio; Gemini 3.1 Pro revela apenas resumos; e Claude não revela nada.

Os resultados de cada ferramenta eram enviados de volta ao agente, permitindo que os pesquisadores acompanhassem o processo até a conclusão ou até que o agente atingisse seu limite operacional.

Quatro exemplos de como os agentes de IA gastam tokens. Repetir informações já conhecidas, fazer buscas idênticas e acrescentar desculpas sem propósito são considerados desperdício, enquanto uma busca malsucedida não é necessariamente um desperdício, pois o agente pode ter tido bons motivos para realizá-la.

As solicitações dos agentes eram encaminhadas por meio de um proxy para que sua atividade fosse monitorada; foram necessárias apenas pequenas alterações no código, e cada solicitação era identificada com seu benchmark, execução, tarefa e tentativa (com exceção da OpenClaw, que não oferece suporte a essas identificações — nesse caso, foi usado um proxy separado, criado com LiteLLM, para cada teste).

Quatro participantes

O estudo define o desperdício de tokens com base em quatro padrões recorrentes: Repetição (repetir informações já conhecidas); Busca duplicada (repetir solicitações desnecessárias a ferramentas); Enchimento (acrescentar texto irrelevante); e Desvio (seguir abordagens plausíveis, mas que acabam sendo improdutivas).

Cada sessão gravada foi analisada por um LLM como juiz (LLMaJ**), ao qual foram fornecidos a tarefa original, o registro completo e os critérios para identificar os quatro padrões de desperdício. O desperdício suspeito foi marcado e removido, e os tokens restantes foram contados novamente para calcular a proporção desperdiçada e o custo. Em seguida, as contagens foram verificadas com os tokenizadores ou ferramentas de contagem de cada provedor e com o uso de saída informado por eles (foram relatadas apenas pequenas diferenças de formatação).

Testes

Os modelos testados no estudo foram Kimi-K3, Gemini 3.1 Pro, GPT-5.6 Terra, GPT-6 Astra, Claude Sonnet 5 e Claude Fable 5.1. Eles foram avaliados nos benchmarks τ²-bench (atendimento ao cliente nos setores aéreo e varejista), SWE-bench Verified (engenharia de software), Claw-Eval e MCP-Atlas (uso de ferramentas de finalidade geral).

Além disso, o Kimi-K3 foi testado em diferentes níveis de raciocínio, e cinco estruturas de agentes foram comparadas: OpenCode, OpenClaw, OpenHands, Hermes e Kimi Code CLI. Essas últimas comparações foram usadas para avaliar como os modelos, as tarefas, o esforço de raciocínio e o projeto da estrutura afetam o desperdício de tokens (e, em testes adicionais, o desperdício suspeito foi removido para verificar seu efeito no desempenho).

Para determinar quanto dinheiro foi desperdiçado por cada modelo, o custo do texto desnecessário e das chamadas a ferramentas foi comparado com o custo total das saídas, calculando-se a média dos resultados dos quatro benchmarks. O raciocínio interno foi avaliado separadamente no caso do Kimi-K3, o único modelo que expunha todo o seu processo de raciocínio:

Resultados dos testes que comparam os custos de saída desperdiçados por seis modelos de IA, com médias calculadas nos quatro benchmarks. À esquerda: taxas gerais de desperdício, com o raciocínio interno do Kimi-K3 apresentado separadamente. À direita: taxas de desperdício em tarefas bem-sucedidas e malsucedidas; em geral, as falhas geraram mais desperdício.

Como mostra o gráfico acima, estimou-se que entre 11% e 24,9% do dinheiro gasto para gerar respostas e usar ferramentas foi desperdiçado. O GPT-6 Astra teve o melhor desempenho, e o Claude Sonnet 5, o pior. No caso do Kimi-K3, cerca de um em cada seis tokens foi desperdiçado em respostas e no uso de ferramentas; durante o raciocínio interno, essa proporção passou de um em cada quatro.

Em geral, houve mais desperdício quando as tarefas falharam, embora o contrário tenha ocorrido com o raciocínio do Kimi-K3; tampouco houve evidências claras de que gastar mais tokens em trabalho desnecessário aumentasse as chances de sucesso.

Em outro teste, tentou-se reduzir o desperdício de tokens enquanto a IA ainda estava trabalhando: a cada etapa, um juiz de IA** era usado para remover informações repetidas e texto sem propósito do raciocínio do modelo, antes de permitir que a tarefa prosseguisse:

Resultados dos testes que mostram como a remoção de raciocínio desnecessário da IA afetou as taxas de sucesso em dois benchmarks. Remover de 41% a 46% do raciocínio teve pouco efeito no desempenho, enquanto remover todo o raciocínio provocou um aumento considerável nas falhas.

No SWE-bench Verified, 41% do raciocínio foi removido sem perda de desempenho; na verdade, a taxa de sucesso subiu ligeiramente, de 89% para 89,5%. No MCP-Atlas, removeu-se 46%, e a taxa de sucesso caiu apenas modestamente, de 65% para 62,3%.

Em outras palavras, quase metade do raciocínio poderia ser descartada enquanto a IA trabalhava, sem prejudicar seriamente sua capacidade de concluir a tarefa.

Por fim^†, o Kimi-K3 foi testado em tarefas idênticas usando diferentes estruturas de agentes. Nesse caso, a quantidade de raciocínio gerada variou mais de quatro vezes, sem qualquer melhoria consistente no desempenho, como mostra o gráfico abaixo:

Resultados dos testes que comparam o consumo de tokens do Kimi-K3 em diferentes estruturas de agentes, em dois benchmarks. O raciocínio interno aparece em azul; as respostas e chamadas a ferramentas, em laranja. Em tarefas de programação, o Mini-SWE gerou mais de quatro vezes mais raciocínio do que o Hermes.

Parte do desperdício foi atribuída a falhas básicas de software. OpenCode, Kimi Code CLI e OpenClaw iniciaram testes de programação no ambiente Python errado, causando erros e novas tentativas.

Conclusão

Este é apenas um breve olhar sobre um artigo cuja extensão e metodologia meticulosa talvez justifiquem uma leitura mais aprofundada.

O tema me fez pensar em algo que costuma me chamar a atenção: o enorme abismo entre o que nós e os fornecedores de modelos de ponta realmente entendemos sobre esses processos e a disposição das empresas de apresentar o produto como se ele tivesse passado os últimos três meses por um analisador de código e recebido a nota máxima.

No momento, quando os resultados são ruins, não podemos culpar ninguém além de nós mesmos, porque estamos comprando algo que quase todos nós sabemos ser um produto profundamente experimental e imprevisível.

* Com contribuições declaradamente iguais da University of Illinois Urbana-Champaign, da Northeastern University, da University of California (Los Angeles) e de um pesquisador independente.

* O artigo não identifica qual modelo foi usado, até onde consigo perceber.

^† Para este artigo, não para o artigo acadêmico, que é mais longo do que costumo me permitir abordar e contém mais testes e maior profundidade do que podemos acomodar aqui. Consulte o PDF original, com link acima, para obter mais detalhes.

Publicado originalmente na sexta-feira, 6 de novembro de 2026