O que é o “tokenmaxxing”? A métrica de IA que se autodestruiu

Em 30 dias, os funcionários da Meta movimentaram aproximadamente 60 trilhões de tokens de IA por meio de um ranking interno que os classificava por consumo; uma despesa que provavelmente ultrapassou US$ 100 milhões para produzir um trabalho que foi, em grande parte, meramente performático. Noventa dias depois, o ranking havia desaparecido, e a empresa passou a racionar rigorosamente o uso da IA.

Esse ciclo é chamado de “tokenmaxxing”: é quando a maximização do uso de tokens de IA é promovida a um índice de desempenho e a um indicador de produtividade. Desde então, as empresas aprenderam a lição, e algumas exageraram na correção, em um fenômeno apelidado de “tokenminning”: usar o menor número possível de tokens de IA para reduzir os custos de computação. Ambas as abordagens falham porque tratam a contagem de tokens como um indicador confiável de crescimento impulsionado pela IA.

Neste artigo, abordaremos quanto o “tokenmaxxing” realmente custa, como os engenheiros se aproveitaram do sistema e a estrutura de medição que resiste a quem é bom em manipular números.

O que é o “tokenmaxxing”?

O “tokenmaxxing” é a prática de maximizar o consumo de tokens de IA e considerar um uso mais intenso como indício de maior produtividade ou adoção da IA. Os tokens são as unidades que um modelo de IA processa como entrada e produz como saída.

O uso de tokens tornou-se uma métrica de desempenho atraente porque é visível, quantificável e já é monitorado por muitas plataformas de IA. Isso facilita a geração de relatórios em comparação com resultados como tempo economizado, decisões aprimoradas ou receita gerada. Mas os tokens medem a atividade computacional, não o trabalho útil. Solicitações repetitivas, loops de agentes com falha e saídas sem sentido elevam o número sem produzir nada.

Os agentes de IA agravam essa situação. Um agente analisa o contexto, aciona ferramentas, revisa seu próprio trabalho e repassa tarefas a outros agentes. Cada etapa consome tokens. Embora mais atividade possa significar um trabalho mais útil, também pode indicar fluxos de trabalho ineficientes e aumento de custos.

Em termos simples, a falha central do tokenmaxxing é que as equipes maximizam o número visível, enquanto a produtividade, a qualidade e o retorno sobre o investimento permanecem os mesmos.

Por que o “tokenmaxxing” se tornou popular?

O “tokenmaxxing” ganhou popularidade porque a liderança precisava de um número para comprovar que a adoção da IA nas empresas estava ocorrendo. E o uso de tokens era a única métrica que aparecia no painel de faturamento.

O CEO da Nvidia, Jensen Huang, deu o tom no início de 2026 no podcast All-In com um experimento mental sobre a conta de tokens de um engenheiro com alto salário.

“Se aquele engenheiro que ganha US$ 500 mil não consumir pelo menos US$ 250 mil em tokens, vou ficar profundamente preocupado”, disse ele. E se a resposta fosse US$ 5 mil? Ele ficaria furioso.

O uso da IA havia se tornado um indicador visível de quem estava acompanhando o ritmo. Isso acontecia em um momento em que, em todas as reuniões de planejamento, surgiam perguntas sobre quais funções a IA viria a assumir. Os engenheiros que gastavam tokens pareciam estar se adaptando ao novo paradigma, enquanto aqueles que não o faziam corriam o risco de parecer um problema.

Eis a ironia: o primeiro ranking de tokens nunca teve a intenção de ser uma competição. A Shopify criou um para entender por que seus principais consumidores estavam gastando tanto, e não para classificá-los uns contra os outros. O vice-presidente e chefe de engenharia, Farhan Thawar, descreveu posteriormente como a ferramenta evoluiu.

A empresa renomeou o recurso como “painel de uso”, adicionou proteções contra sobrecarga e alertas de gastos, e utilizou os dados para identificar agentes fora de controle e falhas na infraestrutura. Farhan escreveu:

O “tokenmaxxing” é um tema polêmico. Mais não significa melhor. Criamos o primeiro ranking de tokens de IA. Depois, evoluímos nosso pensamento. Ele se tornou um painel de uso. Os mesmos dados, mas com uma abordagem diferente. Adicionamos limitadores de fluxo e picos de gastos. Identificamos agentes fora de controle. Encontramos bugs em nossa própria infraestrutura. O verdadeiro indicador: não quem gastou mais, mas aqueles cujos tokens geraram maior impacto. Esses são os engenheiros com quem quero conversar.

A maioria das empresas que copiou o quadro de classificação do Shopify o utilizou para classificar funcionários, em vez de analisar os gastos com IA. A tabela abaixo mostra como isso se desenrolou em cada uma delas.

O padrão observado nesta tabela é consistente. As organizações que utilizaram dados de tokens para investigar gastos elevados mantiveram um indicador válido. Outras, que os utilizaram para classificar pessoas, perderam esse indicador em um trimestre.

Como os engenheiros inflaram o uso de seus tokens?

Os engenheiros inflaram seu uso de tokens gerando atividades de IA dispendiosas que nunca planejaram lançar. O site The Pragmatic Engineer relatou esse comportamento na Meta, na Microsoft e na Salesforce e identificou quatro táticas comuns. Nenhuma delas envolvia má-fé. As pessoas simplesmente viram um número visível, ficaram preocupadas com demissões e presumiram que o uso intenso de IA as protegeria:

Muitos engenheiros verificavam quanto seus colegas estavam gastando. Em seguida, consumiam apenas o suficiente para ficar um pouco acima da média. Mais do que estar na primeira posição, eles não queriam ser sinalizados por não usarem IA o suficiente.

Na Amazon, os funcionários atribuíam tarefas triviais e inventadas aos agentes de IA para elevar suas pontuações no Kirorank. Isso aumentou os custos com nuvem sem gerar nenhum resultado comercial. Quando a Amazon retirou o quadro de líderes, o vice-presidente sênior Dave Treadwell disse à equipe que ele havia sido criado com boas intenções. Em seguida, ele pediu claramente: “Por favor, não usem a IA apenas pelo simples fato de usá-la.”

Como parte dessa mudança, a Amazon agora monitora se o código gerado por IA funciona e agrega valor. O consumo de tokens não é sua principal prioridade.

Quanto o “tokenmaxxing” custou às empresas?

O “tokenmaxxing” provavelmente custou à Meta mais de US$ 100 milhões em um único mês e esgotou o orçamento anual da Uber para IA em quatro meses. A estimativa da Meta se baseia em uma simples conta aritmética. Pelo preço de lista da API da Claude Opus (na época em que a notícia foi divulgada), 60,2 trilhões de tokens custariam aproximadamente US$ 900 milhões. Uma empresa do porte da Meta negocia descontos significativos, mas, mesmo assim, a conta poderia chegar a nove dígitos.

A Uber oferece o panorama mais claro do custo, pois nunca manteve um ranking. A empresa forneceu a cerca de 5.000 engenheiros ferramentas de codificação autônomas sem um modelo de gastos. Em um mês, a parcela de engenheiros classificados como usuários autônomos subiu de 32% para 84%. Todo o orçamento anual se esgotou em quatro meses.

O diretor de tecnologia (CTO), Praveen Neppalli Naga, admitiu que a empresa estava “de volta à prancheta” no que diz respeito às suas premissas. As despesas mensais variavam de US$ 500 a US$ 2.000 por engenheiro, e a solução foi direta: um teto mensal de US$ 1.500 por ferramenta de programação, por engenheiro.

Quando engenheiros que realizam trabalhos semelhantes gastam quantias tão diferentes, essa variação mostra que ninguém havia definido o que seria um bom uso. Assim, cada engenheiro criou sua própria definição. O diretor de operações da Uber, Andrew Macdonald, reconheceu esse ponto, dizendo à revista Fortune que era “muito difícil traçar uma linha divisória” entre o código assistido por IA e os recursos úteis realmente lançados.

O Relatório de Impacto da IA da LeadDev constatou que apenas 19% dos líderes de engenharia consideram o “tokenmaxxing” eficaz. 57% deles afirmam que ele não consegue avaliar o valor real.

Veja por que o dinheiro circula tão rápido: um agente que planeja uma alteração no código lê o repositório, aciona ferramentas, executa testes e repete a tentativa até obter sucesso. Um único ciclo pode consumir dezenas de milhares de tokens, e as leituras do cache de prompts aumentam ainda mais esse número.

As equipes financeiras elaboraram orçamentos para IA como se tratasse de uma licença por usuário. Mas, na verdade, ela se comporta como computação em nuvem. A mesma lacuna contábil surge quando as equipes montam uma pilha de IA envolvendo vários fornecedores sem atribuir a ninguém a responsabilidade pela conta. Esse é o mesmo tipo de falha que a proliferação descontrolada de ferramentas, mas em um nível superior.

O que é o “tokenminning”?

O “tokenminning” é a prática de minimizar o consumo de tokens de IA e considerar o baixo uso como meta. Como discutimos na introdução, trata-se de uma correção exagerada que também traz resultados ruins. O nome é uma abreviação de “token minimizing” e surgiu como correção ao “tokenmaxxing”. O New York Times noticiou essa mudança em várias empresas.

A Meta informou aos funcionários que limitaria o uso de IA após um “aumento exponencial” nos custos. A Uber estabeleceu um teto para os gastos mensais, o Walmart definiu limites para o uso das ferramentas, e tanto a Amazon quanto a Meta retiraram seus ranking de uso. Em poucas semanas, as mesmas empresas que haviam celebrado seus maiores usuários de IA estavam ensinando a todos a racionar o uso.

Essa correção repete o erro que deveria corrigir. A lei de Goodhart explica isso muito bem: quando uma medida se torna uma meta, ela deixa de ser uma boa medida. Portanto, se você definir o uso de tokens de IA como meta, as pessoas encontrarão maneiras de otimizar essa métrica, mesmo que isso signifique comprometer a intenção original. A lei de Goodhart alerta contra o “tokenmaxxing” e o “tokenminning”.

Recompense uma equipe por queimar tokens, e ela queimará tokens desnecessários. Recompense uma equipe por economizar tokens, e ela deixará de executar a IA que teria detectado um bug. Ou dividirá uma sessão completa em três sessões mais baratas, cada uma retornando uma resposta menos aprofundada. Ambas as equipes atingem suas metas de uso de tokens, enquanto a qualidade do trabalho real piora.

O controle de custos, por si só, não é o erro. Assim como no exemplo da Uber, o teto mensal de US$ 1.500 é uma decisão orçamentária tomada depois que a empresa gastou o orçamento de um ano em quatro meses. Mas estabelecer um limite de gastos resolve apenas um problema financeiro. Isso não responde se os tokens comprados serviram para algo útil.

A solução é separar dois tipos de números: os sinais que você monitora e os resultados que você busca. O uso de tokens, a taxa de adoção e a proporção de código escrito por IA são sinais que mostram o que está acontecendo dentro do sistema. Eles são úteis na investigação de um problema, mas não são boas metas. Isso porque cada um deles pode variar bastante sem que o cliente perceba qualquer diferença.

Uma organização deve, ao contrário, buscar resultados. Eles seguem a mesma lógica de qualquer conjunto bem elaborado de KPIs de desenvolvimento de software: associar um sinal precoce ao resultado que ele deve prever. A conversão do painel do Shopify serve de modelo: os mesmos dados, mas sem nenhuma classificação de desempenho associada a eles.

Neil Dhar, vice-presidente sênior da IBM Consulting, descreveu como a confusão se espalha em um artigo sobre os custos da IA.

#Tokenmaxxing tem sido destaque nas manchetes ultimamente. O esforço organizacional para usar o máximo possível de IA, o mais rápido possível, transformando o uso em um indicador de valor. Agora, a conta está chegando. À medida que os custos da IA superam os retornos, o instinto é cortar gastos. Mas cortar gastos por si só não resolverá o problema subjacente do ROI.

Segundo a IBM, a solução é tratar o uso como um sinal e associá-lo a um resultado que não possa ser falsificado.

Mais uso de tokens significa maior produtividade?

Não, um alto uso de tokens não significa alta produtividade. Os maiores conjuntos de dados disponíveis mostram que os dois fatores evoluem de forma independente. Uma pesquisa da plataforma de inteligência para desenvolvedores DX constatou que a adoção da IA está próxima da saturação, enquanto os ganhos de produtividade medidos permaneceram estáveis.

Laura Tacho, diretora de tecnologia (CTO) da DX, compartilhou os números. Entre os desenvolvedores, 92,6% agora usam um assistente de programação de IA pelo menos uma vez por mês, e cerca de 75% usam um semanalmente. A IA escreve 26,9% do código de produção. No entanto, a economia de tempo relatada pelos próprios desenvolvedores permaneceu em cerca de quatro horas por semana por mais de um ano. E o ganho inicial de produtividade de 10% nunca aumentou.

O uso continuou aumentando, enquanto os resultados permaneceram estagnados. Qualquer métrica que acompanhe apenas o uso vem relatando um sucesso que nunca aconteceu.

O relatório DORA do Google Cloud explica por que as mesmas ferramentas produzem resultados tão diferentes. Ele constatou que a adoção da IA melhorou a velocidade de entrega, mas prejudicou a estabilidade da entrega. O relatório descreve a IA como um amplificador: ela realça os pontos fortes de organizações bem administradas e os pontos fracos daquelas que enfrentam dificuldades.

Os próprios dados da DX mostram esse amplificador em ação. Em um grupo de 67 mil desenvolvedores, algumas organizações viram os incidentes envolvendo clientes dobrarem, enquanto outras os reduziram pela metade, usando as mesmas ferramentas durante o mesmo período. O Tacho atribui a responsabilidade de acordo com o que os dados indicam:

Na verdade, trata-se de um problema de gestão. O entusiasmo em torno do assunto deu a impressão de que bastaria experimentar a IA para obter resultados automáticos. Mas, até agora, a maioria das ferramentas tem sido utilizada para tarefas individuais de programação. Para observar um impacto real, precisamos usar a IA no nível organizacional, e não apenas para tarefas isoladas.

Há um segundo problema subjacente ao primeiro: as pessoas avaliam erroneamente o próprio ganho de velocidade proporcionado pela IA. O laboratório de pesquisa sem fins lucrativos METR realizou um ensaio clínico randomizado. Dezesseis desenvolvedores experientes de código aberto resolveram 246 problemas reais em repositórios que mantinham há, em média, cinco anos. Antes de começarem, os desenvolvedores previram que a IA os tornaria 24% mais rápidos. Após terminarem, estimaram que ela os havia tornado cerca de 20% mais rápidos. O cronômetro indicou que eles estavam 19% mais lentos.

Em uma atualização posterior, o laboratório explicou que seu próximo experimento se deparou com efeitos de seleção que não foi possível corrigir. Também afirmou que, atualmente, os desenvolvedores provavelmente são realmente mais rápidos com a IA, em grande parte graças às ferramentas agentivas. O que permanece válido: a produtividade auto-relatada não substitui a produtividade medida, e a diferença entre elas pode variar para qualquer um dos lados.

O que você deve medir em vez do uso de tokens?

Em vez do uso de tokens, avalie os resultados primeiro no nível da equipe e, depois, no nível organizacional. Trate o uso de tokens como um indicador de custo que não serve para classificar ninguém. O que importa são os resultados alcançados.

Uma regra prática a ser seguida: associe cada sinal que você publicar a um resultado que ele não possa inflar. Uma equipe pode queimar tokens sem lançar nada. No entanto, ela não pode falsificar uma queda na taxa de falhas.

Essa estrutura se baseia em estruturas de medição nas quais os líderes de engenharia já confiam. O DORA abrange a velocidade de entrega e a estabilidade, e sua constatação de que a IA amplifica ambos é a razão pela qual essa combinação é importante.

O DX Core 4 mede quatro dimensões: velocidade, eficácia, qualidade e impacto nos negócios. Abi Noda e Laura Tacho o desenvolveram em parceria com Nicole Forsgren e Margaret-Anne Storey, as pesquisadoras por trás do DORA, do SPACE e do DevEx. As quatro dimensões se contrapõem propositalmente.

Uma equipe que melhora um aspecto em detrimento de outro expõe imediatamente essa contradição. Nenhuma das duas estruturas inclui uma métrica de tokens, e nenhuma delas adicionou uma.

Três regras fazem com que essa combinação funcione na prática:

Como definir uma política de uso de IA que os funcionários não possam manipular?

Para definir uma política de uso de IA que os funcionários não possam manipular, remova todos os números visíveis do desempenho individual e tome cinco decisões:

1. Decida para que serve o número antes de coletá-lo

Cada métrica da política precisa ter um objetivo definido por escrito antes que o primeiro painel seja lançado. O quadro de líderes do Shopify funcionou em sua fase inicial. A liderança o utilizou para iniciar conversas com os maiores gastadores sobre o que eles estavam desenvolvendo. O número serviu para dar início a uma investigação. Assim que o mesmo número encerra uma investigação, tirando conclusões sobre uma pessoa em vez de fazer perguntas sobre o trabalho, ele se transforma em uma pontuação. E pontuações são gerenciadas.

Anote três pontos por métrica:

A linha de inação é a que dá mais trabalho, porque os funcionários testam a política em relação a ela. Se a resposta honesta à pergunta “o que acontece quando os gastos aumentam” envolver a posição de alguém na hierarquia, você criou um quadro de classificação com etapas adicionais.

2. Defina o orçamento no nível da equipe

Um orçamento compartilhado pela equipe substitui o limite individual, e a diferença é comportamental, não contábil. A variação mensal de US$ 500 a US$ 2.000 na Uber entre engenheiros que realizam trabalhos comparáveis mostra o que acontece sem um ponto de referência comum. Cada um cria sua própria definição do que é razoável. Os orçamentos compartilhados funcionam da mesma forma que qualquer outra iniciativa para concentrar gastos dispersos com IA em um único local responsável.

O envelope lhe proporciona três coisas que um limite por pessoa não pode oferecer:

Estabeleça o primeiro limite com base nos dados observados. Considere a média dos últimos três meses da equipe e acrescente uma margem de segurança para um projeto caro. Um limite definido por suposições é ultrapassado já na segunda semana, mostrando a todos que a política é apenas para enfeite.

3. Torne visível o caminho mais caro

Mostre aos engenheiros o custo de cada execução, em vez de limitar o que eles podem gastar. As execuções do Agentic que ficam em loop devido a testes com falha são onde os orçamentos se esgotam, levando a necessidade de um limite rígido à tona. Outra opção é divulgar o custo por execução ao engenheiro que a acionou, sem reportá-lo para a gerência.

Um engenheiro que observa um ciclo de tentativas repetidas queimar US$ 40 irá corrigir o ciclo. Por outro lado, um engenheiro que teme um relatório deixará de usar o agente por completo, mesmo nas ocasiões em que a execução dispendiosa foi a decisão certa.

Os interruptores de circuito do Shopify funcionam assim: o sistema detecta a anomalia, e a pessoa mais próxima do trabalho decide o que fazer. A visibilidade muda o comportamento mais rapidamente do que um limite máximo, e mantém a execução cara, mas correta, disponível quando o trabalho justifica o gasto.

4. Separe a meta de adoção da IA da avaliação de desempenho

Deixe a separação por escrito, pois garantias verbais não sobrevivem a um ciclo de demissões. O engenheiro da Microsoft que descreveu ao The Pragmatic Engineer como inflacionava suas próprias métricas de uso não estava buscando um prêmio. Ele estava evitando um rótulo em um ano marcado por demissões relacionadas à IA.

Se as pessoas acreditarem que os dados de uso chegam a uma reunião de calibração, elas cuidarão desses dados, não importa o que alguém diga em voz alta.

A redação da política precisa de exatamente duas linhas:

Então, valorize ambos. O primeiro engenheiro que perceber que os dados de uso estão aparecendo em uma revisão vai contar para todo mundo, provando que a métrica é redundante.

5. Revise o emparelhamento a cada trimestre

A cada trimestre, verifique se cada diagnóstico ainda explica o resultado ao qual está associado. A precificação de modelos, o comportamento de cache e a arquitetura de agentes mudam mais rapidamente do que um ciclo de planejamento anual.

A forma como as equipes aplicam a IA ao planejamento e à geração de relatórios está em constante mudança. Uma contagem de tokens que significava uma coisa em janeiro passa a significar algo diferente em junho, após dois cortes de preço e uma atualização do agente.

A análise apresenta resultados honestos para cada métrica: ela ainda prevê o resultado esperado, precisa ser recalibrada de acordo com novos preços ou deixou de explicar qualquer coisa e é aposentada sem cerimônia. As equipes são as que mais resistem à aposentadoria. No entanto, trata-se de um processo importante, pois uma métrica que perdeu seu significado é exatamente o tipo de número sobre o qual a era dos rankings foi construída.

Erros comuns que as equipes cometem ao medir a adoção de IA

Os quatro erros mais comuns são: tratar a adoção como a linha de chegada, confiar em economias de tempo declaradas pelos próprios usuários, publicar tabelas de classificação individuais e medir a velocidade sem avaliar a estabilidade. É possível identificar cada um deles antes que se tornem um custo elevado.

1. Encarar a adoção como a linha de chegada

O painel de implementação indica 90%, a liderança declara a iniciativa de IA concluída e ninguém pergunta o que mudou a jusante. Os dados da DX expuseram essa armadilha em grande escala: 92,6% de adoção com produtividade estagnada em 10%. A adoção apenas confirma que as ferramentas chegaram às pessoas. Ela não diz nada sobre o que as ferramentas mudaram.

A solução: Retire o gráfico de adoção assim que a implementação terminar e substitua-o por um emparelhamento entre sinal e resultado.

2. Confiar nas economias de tempo declaradas pelos próprios usuários

Uma pesquisa indica que a equipe economiza cinco horas por semana, mas o tempo de ciclo não sofreu alterações nos últimos dois trimestres. O teste da METR mostra por que esses dois números divergem: desenvolvedores que trabalharam visivelmente mais devagar com IA ainda estimaram um aumento de 20% na velocidade posteriormente. O que as pessoas acreditam e o que o relógio registra são duas medidas diferentes.

A solução: Mantenha a pesquisa voltada para a experiência do desenvolvedor, onde a percepção é importante. Use dados do sistema para qualquer afirmação relacionada ao tempo.

3. Publicar um ranking individual só por diversão

Alguém cria isso em uma wiki interna em uma tarde, dá nomes divertidos e a equipe realmente se diverte com isso por cerca de três semanas. Depois, o incentivo toma conta. O “Claudeonomics” do Meta e o “Kirorank” da Amazon começaram como diversão espontânea. Ambas as empresas os retiraram de circulação assim que a parte lúdica superou o entusiasmo.

A solução: Agregue os dados ao nível da equipe ou não os divulgue.

4. Medir a velocidade sem medir a estabilidade

A taxa de processamento aumenta, todos comemoram, e o volume de incidentes cresce no painel de outra equipe. O relatório DORA identificou exatamente essa divisão: a velocidade melhora, enquanto a estabilidade piora. Manter os dois números em painéis separados faz com que o problema passe despercebido.

A solução: Coloque a taxa de falha nas alterações na mesma tela que qualquer métrica de velocidade, e não em uma análise de confiabilidade separada que ninguém consulta.

Como acompanhar o impacto da IA no ClickUp

Para acompanhar o impacto da IA no ClickUp, avalie os resultados em relação ao próprio trabalho: as tarefas, os sprints e os resultados que a IA deveria agilizar. A maioria dos painéis de tokens fica no console do provedor, longe do trabalho que eles descrevem. Transferir as métricas de resultados para o espaço de trabalho elimina essa lacuna.

A relação entre sinal e resultado mencionada anteriormente se reflete diretamente na plataforma:

Acompanhe a contagem de tokens sem atribuir pontuação às pessoas envolvidas

Toda a história se resume a uma regra: use os dados dos tokens para fazer perguntas, nunca para classificar pessoas. A Shopify perguntou “o que nossos maiores gastadores estão desenvolvendo?” e descobriu agentes fora de controle e falhas na infraestrutura. A Meta e a Amazon perguntaram “quem está usando mais a IA?” e se depararam com tarefas falsas, desperdício de milhões e rankings inúteis.

Portanto, faça três coisas neste trimestre. Transfira o acompanhamento de tokens para o nível da equipe e exclua tudo o que mostre o nome de uma pessoa. Estabeleça, na política, que os dados de uso nunca sejam considerados em avaliações de desempenho. E coloque uma métrica de qualidade (a taxa de falha de alterações é a mais fácil) na mesma tela que todas as métricas de velocidade que você relata.

Se você quer que essa tela fique ao lado do trabalho em si, em vez de ficar em uma ferramenta de relatórios separada, comece a usar o ClickUp gratuitamente e crie o painel antes mesmo de precisar dele.

Perguntas frequentes sobre o Tokenmaxxing (FAQs)

O que é a regra dos 30% para o “tokenmaxxing”?

Não existe uma “regra dos 30%” oficial específica para o tokenmaxxing. A expressão costuma ser uma forma abreviada de se referir a duas constatações distintas que as pessoas confundem: que a IA tende a elevar a produtividade de engenharia medida em cerca de 10%, e não 30%, e que os desenvolvedores costumam prever ganhos em torno de 20 a 30% que não se concretizam. Trate qualquer porcentagem fixa como um indicador a ser investigado, nunca como uma meta a ser atingida.

Um milhão de tokens equivale a aproximadamente 750 mil palavras de texto em inglês, já que um token tem, em média, cerca de três quartos de uma palavra. O custo depende inteiramente do modelo e da divisão entre entrada e saída. Com base nas taxas dos modelos de ponta de 2026, ele varia de alguns dólares a poucas dezenas de dólares por milhão. Sessões com agentes consomem milhões de tokens rapidamente porque cada loop relê o contexto, e as leituras do cache de prompts aumentam a contagem.

“Tokenmaxxing” combina “token” com o sufixo da internet “-maxxing”, que significa maximizar uma característica. O termo se espalhou nos círculos de engenharia no início de 2026, depois que rankings internos de tokens da Meta e da Amazon vazaram para a imprensa. A Business Insider chamou isso de “o novo debate sobre IA no Vale do Silício ” em abril de 2026. Rankings públicos como o Viberank e o tokenmaxxing.sh adotaram então o termo, classificando desenvolvedores individuais em todo o mundo com base no gasto com APIs.

Em grande parte, sim. A revista Fortune declarou o fim do “tokenmaxxing” em maio de 2026, depois que Meta, Amazon, Microsoft e Uber reduziram ou encerraram seus rankings de tokens. O Relatório de Impacto da IA da LeadDev constatou que apenas 19% dos entrevistados consideram o “tokenmaxxing” eficaz para medir o valor da IA, enquanto 57% afirmam que ele falha completamente. Rankings públicos criados por entusiastas ainda persistem, mas como um jogo, não como uma prática de gestão.

Não há um parâmetro de referência estabelecido. Na implantação da Uber, as faturas mensais variavam de US$ 500 a US$ 2.000 por engenheiro, antes de a empresa limitar os gastos a US$ 1.500 por ferramenta. O CEO da Nvidia, Jensen Huang, argumentou que um engenheiro que ganha US$ 500.000 deveria consumir US$ 250.000 em tokens anualmente, mas isso é, muito provavelmente, uma provocação, não um padrão. As conclusões mostram grande variação entre trabalhos comparáveis, o que significa que ninguém definiu o que constitui um bom uso.

A programação “vibe” é uma forma de trabalhar: delegar a implementação a um agente de IA e orientar-se pelos resultados. O “tokenmaxxing” é uma forma de medir: tratar os tokens que você consome como evidência de produtividade. É possível programar “vibe” de forma eficiente ou desperdiçadora; o “tokenmaxxing” recompensa a versão desperdiçadora, pois conta apenas o consumo. Empresas que limitaram o uso de tokens para impedir o “tokenmaxxing” muitas vezes penalizaram o trabalho legítimo dos agentes nesse processo.