As empresas estão adotando a IA mais rápido do que conseguem gerir sua economia de tokens

Por que o antigo modelo de custos falhou

Durante a maior parte da era do software, o custo de uma ferramenta aumentava proporcionalmente ao número de pessoas que a utilizavam. Compravam-se licenças: dez engenheiros custavam dez vezes o que custava um só, e o departamento financeiro podia prever esse gasto com um ano de antecedência. No entanto, o faturamento por tokens desmontou silenciosamente essa premissa, e os sistemas baseados em agentes deram o golpe final.

Uma interação de turno único com um modelo de linguagem grande (LLM) é breve e limitada: você envia um prompt, recebe uma resposta e pronto. Um fluxo de trabalho agêntico é diferente: um LLM coordena um sistema mais amplo de ferramentas, planeja um curso de ação, invoca serviços externos, lê os resultados e percorre dezenas de passos, carregando consigo seu histórico cada vez mais extenso a cada etapa. Esse histórico é o custo. Em um estudo sistemático sobre tarefas de codificação baseadas em agentes, pesquisadores descobriram que essas tarefas consomem cerca de 1.000 vezes mais tokens do que um chat de código ou raciocínio comum, com a fatura sendo impulsionada principalmente por tokens de entrada — o contexto realimentado no modelo a cada etapa — e não pelo que o modelo escreve.

Assim que um agente abre um arquivo ou executa um comando, os resultados permanecem em seu contexto de trabalho até a tarefa terminar, de modo que cada novo passo volta a consumir todos esses recursos. Uma análise de um agente de codificação popular descobriu que, em um único dia de trabalho intenso, 99% dos tokens que ele processou eram tokens de entrada acumulados ao longo da trajetória do agente, e apenas 1% foram gerados pelo modelo. O trabalho visível, o código ou a resposta, é a parte barata. O scrollback invisível (o registro crescente de tudo o que o agente viu e fez) é onde o dinheiro é gasto.

Há outros dois fatores que dificultam a estimativa de custos. O primeiro é a variabilidade: o mesmo estudo descobriu que uma única tarefa, executada duas vezes, pode diferir em até 30 vezes no total de tokens, porque um agente pode resolvê-la de forma limpa em uma execução e debater-se em becos sem saída na seguinte. O segundo são os retornos decrescentes: uma análise ao nível de sistema da KAIST revelou que os agentes ganham precisão à medida que se lhes permite usar mais recursos computacionais, mas os ganhos diminuem rapidamente enquanto o custo e a latência continuam a subir, algo que os autores descrevem como um problema de sustentabilidade iminente, e não como uma alavanca gratuita. Um número maior de tokens não garante melhores resultados.

Juntando tudo isso, obtemos exatamente a combinação que o modelo de orçamento por assento não consegue refletir: gastos variáveis, não lineares e apenas frouxamente atrelados ao valor. É por isso que, segundo relatos, os custos por desenvolvedor em algumas grandes empresas oscilavam entre algumas centenas e alguns milhares de dólares por mês, e por isso o diretor de tecnologia da Uber descreveu que sua equipe teve de recomeçar do zero. O modelo anterior não apenas subestimava o número; ele media o que não devia.

O que você não consegue ver, você não consegue gerenciar

A maioria das equipes não faz ideia de para onde vão seus tokens. O painel de faturamento mostra um total mensal, mas não indica qual tarefa, agente ou passo o gerou. Essa lacuna precisa ser sanada primeiro, porque a economia está nos detalhes que o total esconde.

Um estudo recente revela o que um total mensal não consegue mostrar. Em "Tokenomics", pesquisadores da Universidade Concordia rastrearam 30 tarefas de desenvolvimento de software de ponta a ponta através de uma estrutura multiagente e mapearam cada token para uma etapa do ciclo de vida do desenvolvimento. O resultado é contraintuitivo. A parte custosa não foi escrever o código. A etapa iterativa de revisão do código, na qual um agente critica e outro revisa, representou, em média, 59,4% de todos os tokens. O custo principal do trabalho de software por agentes está no refinamento e na verificação, os ciclos que são fáceis de deixar em execução e difíceis de detectar em uma fatura.

Você não consegue agir sobre nada disso sem medir, e as métricas são simples de definir: contagem de tokens por tarefa, custo por tarefa concluída, taxa de acertos em cache, latência e contagem de novas tentativas. Cada uma delas aponta para um vazamento diferente. Uma baixa taxa de acertos em cache (a proporção de chamadas em que o provedor devolveu um resultado armazenado em vez de reprocessar o prompt) significa que você está pagando o preço cheio por um contexto que poderia ser reutilizado. Uma contagem elevada de novas tentativas indica que um agente está sobrecarregado. Uma relação crescente entre entradas e saídas indica que o histórico se acumula mais rápido do que o trabalho justifica. Uma fatura de tokens que você não pode detalhar por tarefa ou etapa não é um orçamento; é uma surpresa prestes a acontecer. O setor está convergindo para definições compartilhadas para essas medidas, mas nenhuma equipe precisa esperar por um padrão para começar a contar.

Gastando menos em cada chamada

Uma vez que você tem uma ideia clara dos gastos, a primeira medida é parar de pagar pela mesma coisa repetidamente. Há duas técnicas que fazem a maior parte do trabalho:

A primeira é o cache de prompt (prompt caching), em que o provedor armazena a forma processada de um prefixo de prompt estável para que ele não precise ser recalculado na próxima chamada. Todos os principais provedores oferecem suporte a isso, com orientações publicadas pela OpenAI, Anthropic e Google. O quanto isso ajuda em execuções longas e de várias etapas de agentes era a grande dúvida, e Lumer e seus colegas responderam em "Don't Break the Cache". Em mais de 500 sessões de agentes em três provedores, o cache reduziu os custos de API em 41% a 80% e reduziu o atraso antes do início da resposta (tempo até o primeiro token) entre 13% e 31%.

O título do artigo é, por si só, uma advertência. Armazenar em cache apenas as partes estáveis, como uma metodologia reutilizável para manter o prompt do sistema e as instruções das ferramentas, proporcionou melhorias consistentes, já que o prefixo do prompt permanece idêntico em todas as chamadas. Armazenar em cache o contexto completo de forma indiscriminada, incluindo os resultados dinâmicos das ferramentas que variam a cada execução, quebra a correspondência: o cache nunca é reutilizado, mas o sistema continua arcando com a sobrecarga de procurá-lo, o que pode piorar a latência em comparação com não armazenar nada em cache. Faça o cache do que for estável e mantenha o que muda no final do prompt.

A segunda medida é a disciplina de contexto: enviar menos dados ao modelo desde o início. O contexto extenso é o fator de custo mais silencioso em qualquer sistema de agentes, já que o agente envia todo o seu histórico acumulado ao modelo a cada passo e a API cobra por todo esse volume de cada vez. A compressão de prompts ataca isso diretamente. O trabalho original do LLMLingua da Microsoft mostrou que um prompt longo poderia ser reduzido em até 20 vezes com apenas uma pequena queda no desempenho da tarefa, fazendo com que um modelo pequeno remova os tokens de baixa informação antes que o modelo caro os analise. No entanto, isso não é gratuito.

Um estudo de grande escala, realizado em 2026, intitulado "Prompt Compression in the Wild", revelou que o tempo adicional gasto na compressão inicial precisa ser compensado pela economia que ela gera nas etapas seguintes, mas isso nem sempre ocorre. O hábito mais confiável está antes de qualquer algoritmo: recuperar apenas os arquivos, registros ou trechos de que uma tarefa precisa, resumir as evidências em vez de colá-las por inteiro e resistir a entregar ao modelo tudo "por via das dúvidas". O token mais barato é aquele que você nunca envia.

Gastando no modelo certo na hora certa

A última medida consiste em adaptar o trabalho ao modelo, assim como o tempo de resposta à necessidade. Uma estrutura útil vem da pesquisa "Token Economics for LLM Agents", que aborda a escolha do modelo como uma substituição sujeita a restrições orçamentárias: você quer a entrada mais barata que ainda realize o trabalho, e não o modelo mais potente por puro instinto.

Na prática, isso se traduz em uma estratégia em níveis. Tarefas como formatação, refatoração, classificação rotineira e síntese de um documento limpo funcionam perfeitamente bem em um modelo menor e mais barato, reservando a passagem para um modelo de ponta para os raciocínios verdadeiramente complexos: uma decisão arquitetônica, uma vulnerabilidade sutil, um achado ambíguo que exija discernimento. Direcionar por padrão cada tarefa para o modelo mais capaz é a forma mais comum de as equipes gastarem demais, e é exatamente o comportamento que transformou projetos-piloto modestos em faturas exorbitantes.

O tempo de resposta é a outra metade da estratégia. Uma grande parte dos fluxos de trabalho empresariais não precisa de uma resposta em tempo real. Avaliações offline, classificação de conjuntos de dados, processamento de documentos em massa e geração de relatórios noturnos podem ser executados de forma assíncrona, e os provedores cobram por essa flexibilidade de acordo. A orientação de custos da OpenAI, por exemplo, aponta para sua Batch API para consolidar muitas solicitações em um único trabalho assíncrono e para o processamento flexível, o que substitui respostas mais lentas e ocasionalmente interrompidas por custos substancialmente mais baixos em tarefas não urgentes. Reservar as chamadas em tempo real ao modelo de ponta nos momentos em que são necessárias e processar o restante em lote tende a reduzir os custos sem uma queda visível na qualidade.

O lado da segurança na economia de tokens

É aqui que isso deixa de ser uma questão financeira e se torna uma questão de segurança, um aspecto que a maioria dos artigos sobre economia de tokens deixa de lado. Cada fator mencionado nas seções anteriores modifica o perfil de risco do sistema, não apenas a sua fatura, e uma equipe de segurança precisa analisar os dois aspectos em conjunto.

Considere o cache de prompt, a técnica que, como mencionamos há pouco, reduz os custos em até 80%. Ela funciona processando um prefixo compartilhado uma vez e reutilizando o resultado, de modo que um prompt em cache retorna mais rápido do que um não armazenado. Essa diferença de velocidade é observável, e diferenças de tempo observáveis são um canal lateral clássico (uma forma de extrair informação não do conteúdo de um sistema, mas de seu comportamento).

Em "Auditing Prompt Caching in Language Model APIs", Gu e seus colegas de Stanford demonstraram que, quando um provedor mantém um único cache compartilhado entre todos os usuários, essa diferença de velocidade se converte em um sinal. Um atacante pode enviar prompts candidatos e medir quanto tempo cada um leva para responder. Uma resposta rápida indica um acerto no cache, o que significa que outra pessoa enviou esse prefixo recentemente. Testando sistematicamente os candidatos e anotando quais produzem acertos, um atacante pode deduzir o que outros usuários estão perguntando, sem ler suas mensagens diretamente.

Ao auditar 17 provedores, a equipe detectou armazenamento em cache em oito deles e o compartilhamento global de cache entre usuários em sete, entre os quais estava a OpenAI. A mesma técnica revelou até um segredo arquitetônico: um dos modelos de embedding da OpenAI respondia de forma consistente apenas com um design somente de decodificador, um detalhe estrutural que a empresa não havia divulgado. Os autores relacionam isso diretamente com Meltdown e Spectre, os ataques de hardware que exploravam o mesmo princípio: o comportamento do sistema vaza informações que seus projetistas nunca pretenderam expor, e que agora ressurgem na camada da API de LLM.

A lição não é abandonar o cache. É que a configuração padrão mais econômica e a mais segura nem sempre coincidem. O armazenamento em cache por usuário elimina o vazamento entre usuários, ao mesmo tempo que conserva a maior parte da economia, mas alguém precisa escolhê-lo ativamente. Essa mesma tensão se aplica às demais medidas. A disciplina contextual economiza dinheiro ao cortar o que se envia, mas a tentação oposta, colar um repositório inteiro ou um registro de cliente bruto em um prompt para pular uma ida e volta, amplia silenciosamente a superfície de exposição de dados e expõe registros sensíveis a um modelo de terceiros. Migrar para um modelo menor e mais barato economiza tokens, mas as escolhas de modelo e de arcabouço não são neutras em termos de segurança. Como nosso post anterior sobre a governança de sistemas baseados em agentes mostrou, as taxas de recusa para as mesmas solicitações maliciosas oscilaram entre 30,8% e 52,3% dependendo unicamente do arcabouço do agente. Cada otimização de custos também é uma decisão de segurança, e fingir o contrário é a forma como um sistema mais barato se torna um mais exposto.

Existe também uma armadilha mais sutil. Uma redução agressiva de custos pode apagar justamente as evidências das quais uma equipe de segurança depende para investigar incidentes, verificar se um agente se comportou conforme o previsto e demonstrar conformidade regulatória. A compressão do contexto, o resumo dos resultados das ferramentas e o corte do histórico reduzem a informação que chega aos registros. Sem um registro completo, não há como reconstruir o que um agente decidiu, a qual ferramenta recorreu, a quais dados acessou ou por que chegou a determinada conclusão. Como argumentamos nesse mesmo trabalho, os registros dos agentes devem preservar os prompts, as chamadas de ferramentas, as permissões e o raciocínio que sustenta uma conclusão, e não apenas a resposta final. Se você otimiza esse registro, economiza alguns tokens à custa de sua trilha de auditoria. Uma economia de tokens sólida trata a observabilidade e a auditabilidade como restrições, não como mais gordura a cortar.

Por que isso pertence a uma política, não a um hábito

Todas essas ideias levantam uma questão que cada equipe que adota agentes enfrentará: O uso econômico de agentes de IA deve ser governado por uma política interna explícita, assim como o uso da nuvem, o tratamento de dados e a revisão de código já são? A resposta honesta é que a alternativa — deixar isso a cargo do hábito individual — foi o que provocou os estouros de orçamento em primeiro lugar.

Uma política aqui não significa um documento extenso que ninguém lê. Significa chegar a um acordo em torno de um punhado de valores padrão antes das faturas chegarem. Qual modelo é a opção padrão para o trabalho rotineiro e o que justifica a passagem para um mais avançado. Qual contexto um agente pode receber e quais categorias de dados (registros de clientes, informações confidenciais, registros completos) nunca devem ser coladas em um prompt, independentemente da conveniência. Quais prompts são armazenados em cache e com qual nível de compartilhamento. O que é registrado e o que um registro precisa preservar para ser útil em uma auditoria. Quando uma chamada em tempo real se justifica e quando o trabalho deve ser processado em lote. Nenhuma dessas questões exige conhecimento especializado. São decisões que todas as equipes já tomam de maneira informal sempre que implementam um agente. Uma política simplesmente as coloca por escrito uma vez, para que sejam aplicadas de maneira consistente e possam ser revistas quando as circunstâncias mudarem.

É aqui que a questão dos custos e a da segurança finalmente convergem. O estudo "Token Economics for LLM Agents" dedica uma seção inteira à dimensão da segurança e chega a uma afirmação marcante: a governança funciona como infraestrutura econômica, porque as regras que você define sobre como os tokens são gastos também são as regras que limitam a sua exposição. O trabalho de padrões que está surgindo, desde a expansão da comunidade de FinOps para a IA até a nova Tokenomics Foundation, reflete o esforço do setor para documentar essa política em grande escala. Para uma empresa de segurança de aplicações, ou qualquer organização de TI, tratar a economia dos agentes de IA como uma prática governada, em vez de uma preferência pessoal, é a diferença entre adotar a IA e controlá-la.

Como isso se parece na prática

Nada disso é meramente teórico. A seguir, mostramos como as medidas mencionadas anteriormente se aplicam a quatro situações de trabalho do setor de tecnologia.

Nos testes de segurança, os elementos estáveis são justamente aqueles que valem a pena armazenar em cache: o escopo do teste, a metodologia e as instruções da ferramenta de que um agente precisa em cada execução. No entanto, a matéria-prima não deveria ser reintroduzida no modelo a cada passo. Reintroduzir um log de varredura completo ou uma captura de pacotes no modelo a cada passo é caro e representa uma ampliação desnecessária da superfície de exposição de dados. Portanto, a melhor prática consiste em sintetizar as evidências em achados concisos e usá-los nas etapas seguintes. Os modelos mais robustos justificam seu custo em decisões difíceis, como confirmar uma vulnerabilidade sutil ou interpretar um resultado ambíguo, enquanto a priorização rotineira é feita com algo mais leve.

No âmbito do desenvolvimento, o sucesso está na disciplina de recuperar a informação. Um agente de codificação raramente precisa de todo o repositório em contexto; o que ele precisa é de alguns arquivos relevantes para a tarefa, além de um conjunto armazenado em cache de convenções do repositório para reutilizar em todas as sessões. A formatação, a refatoração e a geração de código repetitivo funcionam com facilidade em um modelo menor, enquanto o modelo de ponta fica reservado para decisões arquitetônicas e raciocínios sobre vulnerabilidades, em que uma resposta incorreta sai cara. O ciclo de revisão merece atenção especial, pois, como mostrou o estudo da Concordia, é ali que os tokens se concentram silenciosamente.

O trabalho de design tem seu próprio núcleo estável. As diretrizes de marca e as regras do sistema de design mudam lentamente e devem ser incluídas em um prompt armazenado em cache, enquanto a informação variável é, por natureza, limitada: trata-se da tela ou do componente específico que está sendo revisado, não de toda a biblioteca de design. Ao enviar apenas o contexto relevante, cada iteração fica simples o suficiente para ser repetida rapidamente, o que costuma ser a principal razão para recorrer a um agente no design.

O trabalho de criação de conteúdo se beneficia de uma abordagem em etapas em vez de uma única tarefa gigantesca. Os guias de estilo e os perfis de público são salvos uma única vez e reutilizados; a pesquisa é resumida em notas em vez de ser colada tal e qual a cada passo; e os rascunhos são construídos seção por seção, para que o contexto nunca transborde. Escrever este blog post por partes, por exemplo, em vez de fazê-lo como uma única tarefa gigantesca, não só foi mais fácil de gerenciar, como também saiu mais barato de produzir.

A adoção foi a parte fácil

Cada onda de computação acaba dando origem a uma disciplina para gerenciar seus custos. A gestão de despesas de telecomunicações seguiu a disseminação das redes telefônicas corporativas; o FinOps na nuvem seguiu a migração para os grandes provedores de nuvem; a economia de tokens é a mesma história, um ciclo depois, razão exata pela qual agora existe uma Tokenomics Foundation. Esse padrão é reconfortante em certo sentido: o problema tem solução e o manual já foi parcialmente escrito.

No entanto, a lacuna é real no momento. A McKinsey descobriu que 92% das empresas planejam aumentar seus investimentos em IA nos próximos três anos, enquanto apenas 1% consideram suas implantações maduras. A iniciativa NANDA do MIT relatou que 95% dos projetos-piloto de IA generativa corporativa não geraram impacto mensurável de lucros e perdas, um dado que atraiu críticas metodológicas, mas cuja descoberta central se alinha com evidências mais amplas: a falha não está nos modelos, mas em como as organizações os integram. A adoção, em outras palavras, foi a parte fácil. Transformá-la em valor, sem perder o controle da fatura ou da superfície de ataque, é o trabalho mais difícil e decisivo.

Essa é a verdadeira mensagem por trás da explosão dos orçamentos. As empresas que se destacarão não serão aquelas que executam o maior número de agentes, mas aquelas que conseguirem ver no que seus agentes gastam, governar como o fazem e garantir que tomem as medidas necessárias para gastar menos. Para uma empresa de segurança, esses três pilares não são preocupações separadas. Eles são a mesma prática. Uma vez que você considera um token algo que vale a pena contabilizar, você está gerindo os custos, reforçando a governança e reduzindo o risco ao mesmo tempo.