Claude Code elimina 80% dos prompts de uma só vez, a Anthropic deu um exemplo com o Fable 5: a "redução de custos" na indústria de IA está apenas a começar.

“O preço do Fable 5 está muito acima do salário diário de um programador chinês. Escrever código que queima milhões de tokens por dia já é muito económico, e depois vê-se a conta: milhares de RMB.”

Isto é a realidade que está a acontecer. De acordo com os dados mais recentes, o dinheiro que a própria Anthropic gasta em poder computacional já atingiu 2,3 vezes as suas despesas salariais. Considerando o custo total de um engenheiro sénior de 224 mil dólares, a despesa anual em computação por engenheiro na Anthropic é de cerca de 515 mil dólares. Ou seja: as pessoas já não são tão caras como os modelos.

Perante facturas destas, até o próprio Claude teve de começar a poupar tokens.

Claude Code: Queimar tokens em troca da ilusão de "ser muito produtivo"

Recentemente, surgiu uma nova palavra na indústria: Token Apocalypse (Apocalipse dos Tokens).

Desde token maxing a token apocalypse, isto indica que está realmente a ocorrer uma grande mudança de paradigma na indústria da IA. Em março e abril deste ano, andava-se a exibir quantos tokens se usavam, quase como se fosse uma classificação. Mas usar IA não significa automaticamente poupar dinheiro, por isso começou a dar-se mais ênfase ao custo de cada token individual.

Mais subtil ainda, os grandes modelos estão a expandir muitos trabalhos que originalmente nem sequer precisavam de IA. Agora não queremos ler PDFs, não queremos ler textos longos, tudo tem de ser resumido pela IA. Ou transformamos coisas em slides com IA e passamos a outros, que depois podem usar IA para ler esses slides... A IA parece estar a injetar artificialmente uma camada de valor em trabalhos que já eram superficiais, ao mesmo tempo que empurra as contas silenciosamente para cima.

Atualmente, a perda de controlo de custos tornou-se normal. Empresas como Amazon, Adobe, Atlassian, Citigroup começaram a impor controlos rigorosos no uso de IA:

• Limitar o nível do modelo: alguns funcionários estão proibidos de usar modelos de topo como o Claude Opus, sendo forçados a versões mais baratas;
• Definir limites individuais: a Uber estabeleceu um limite de 1500 dólares por mês em tokens para cada engenheiro;
• Suspender completamente o acesso: instituições como o Citigroup já bloquearam totalmente o acesso a ferramentas avançadas de IA, e funcionários que não atingem os objetivos de uso podem até ver as suas contas empresariais revogadas. Antes disso, o CTO da Uber admitiu que a empresa esgotou o orçamento anual de IA em poucos meses. A Walmart também parou recentemente de usar algumas ferramentas.

As grandes empresas ou andam à procura de formas de poupar dinheiro, ou põem travão ao desperdício de tokens. Por isso, os funcionários recebem mensagens extremamente contraditórias: de um lado, "a IA pode aumentar a tua eficiência 100 vezes, tens de usar", do outro, "não leves a empresa à falência".

Este é também o problema mais típico da primeira vaga de adoção de ferramentas de IA: quando as ferramentas são lançadas, não há proteções suficientes para impedir as empresas de gastar milhões de dólares em grandes modelos de linguagem, nem mecanismos para alertar as equipas de que os tokens estão a ser queimados rapidamente. Quer sejam chatbots ou ferramentas de codificação, muitos produtos põem primeiro "ser utilizável" em primeiro lugar, deixando a gestão de custos, quotas de uso, classificação de modelos e gestão de contexto para depois.

Mas o Claude Code não é essencialmente uma ferramenta de eficiência, é uma ferramenta de marketing.

O seu objetivo de design é claro: fazer-te sentir produtivo. Boris, o responsável pelo projeto Claude Code, pensou inicialmente no produto: "Se o modelo se tornar inteligente o suficiente, como será o código? Como quero usar estas coisas?" – o ponto de partida não é "como ajudar os programadores a poupar tokens", mas "como mostrar a inteligência do modelo".

A Anthropic está disposta a queimar muitos tokens por esta "sensação" – quer seja o teu dinheiro, quer seja o deles. Gastar 200 dólares em cinco minutos não é um acidente para o Claude Code, é um design. A sua lógica subjacente é: se podes resolver um problema queimando mais tokens, nunca procures uma forma de poupar tokens. Todos os sub-agentes, todas as animações UI extravagantes, todos os reasoning traces longos, não são para eficiência, mas para que, ao olhares para o ecrã, sintas "este modelo é tão inteligente, tão capaz".

Por detrás disto, há um ciclo de marketing cuidadosamente desenhado: queimas muitos tokens, tens a sensação de "ser produtivo", então achas o Claude bom, e continuas a usá-lo. A Anthropic está até disposta a suportar muitos dos custos dos tokens para ganhar esta identificação emocional. É também por isso que a sua aplicação desktop está claramente sub-investida – o objetivo do Claude Code nunca foi ser uma boa ferramenta, mas sim tornar-se a "melhor montra" das capacidades do modelo da Anthropic.

E é precisamente esta filosofia de design de "queimar tokens por experiência" que faz com que o Claude fique para trás da OpenAI em eficiência de tokens.

A OpenAI tem tentado ao máximo comprimir tokens. Desde a compressão dos reasoning traces até à otimização da eficiência dos modelos, a sua filosofia é: usar menos tokens para fazer o mesmo trabalho. O Codex 5.5 é o melhor exemplo.

Embora modelos como o Fable 5 sejam inteligentes, a sua eficiência não é grande em comparação com outros, como mostra bem este gráfico do Deep SWE. Se compararmos o mesmo lote de modelos, fica ainda mais claro: o GPT-5.5 medium usou apenas 20 mil tokens e obteve uma pontuação impressionante; já o Opus 4.8 usou 50 mil tokens e obteve uma pontuação mais baixa.

Esta é a representação mais direta das duas abordagens: a indústria está em pânico, o Claude a queimar, a OpenAI a poupar. E a questão seguinte é: já que é preciso reduzir custos, o que se corta primeiro? A resposta: aqueles prompts que se acumularam durante demasiado tempo.

A dívida de Prompt do Claude Code: Quanto mais se acumula, mais se deve

Numa apresentação recente, a Anthropic disse que já removeu 80% dos system prompts do Claude Code.

O membro da equipa técnica da Anthropic, Tariq Shihipar, explicou que isto reflete uma mudança fundamental na forma como se guiam os modelos de IA – antes, pensava-se que quanto mais instruções e exemplos, melhor o desempenho; agora, essa lógica já não se aplica. O novo modelo Fable 5 é mais imaginativo do que os exemplos que lhe damos, que acabam por ser uma limitação.

Isto tem, claro, uma componente de marketing, pois ele gabou a capacidade do Fable: "Os exemplos acabam por limitar o modelo, porque ele é na verdade mais imaginativo do que os exemplos que damos." Mas um facto é inegável: até a própria Anthropic começou a cortar nos system prompts.

Então, porque é que antes eram precisos tantos prompts?

No último ano ou dois, formou-se um pensamento habitual no mundo da codificação com IA: quanto maior o contexto, melhor; quanto mais instruções sobre ferramentas, melhor; quanto mais completo o system prompt, melhor. O modelo não sabe como o projeto está organizado? Escreve Agents.md. O modelo não sabe como usar as ferramentas? Escreve tool descriptions. O modelo não é suficientemente proativo? Escreve orientações comportamentais. O modelo não é estável? Continua a adicionar restrições ao system prompt.

É inegável que os system prompts foram um fator competitivo central para as ferramentas de codificação com IA. Pequenos ajustes nos prompts de um LLM podem trazer melhorias significativas de desempenho. Se o mesmo modelo se sente diferente no Codex, Cursor, OpenCode e Copilot, é quase certo que se deve a diferenças subtis nos prompts.

É também por isso que a Cursor passou muito tempo a testar system prompts, fazendo testes A/B e ajustando a forma de dar prompts para diferentes modelos. Comparado com usar o Opus no Claude Code, o harness do Cursor consegue melhorar significativamente o desempenho do modelo, com melhorias de benchmark que chegam a 10% a 30%. A diferença reside muitas vezes naqueles pequenos parágrafos de prompt.

Mas o problema é que, enquanto um prompt for útil, a equipa vai continuar a adicionar coisas. Se um modelo usa ferramentas de forma errada, adiciona-se uma regra; se não é suficientemente proativo, adiciona-se um incentivo; se pesquisa demasiado, adiciona-se uma limitação; se não entende o contexto do projeto, adiciona-se outro ficheiro markdown. Cada adição tem a sua razão, mas a longo prazo, o system prompt torna-se um enorme fardo de contexto permanente.

O problema é que os system prompts não são gratuitos. Cada chamada lê-os, fatura-os e ocupa contexto.

Depois de o Claude Code incorporar todas as ferramentas e funcionalidades, o system prompt chegou a ter 65 000 tokens; mesmo desativando a maioria das funcionalidades, ainda tinha 12 000 tokens. Por outras palavras, antes de o modelo escrever uma única linha de código, já carregava um manual de instruções. Em comparação, o contexto de inicialização do Pi tem menos de mil tokens.

Mais problemático ainda, a dívida de prompt é mais insidiosa do que a dívida de código.

O código antigo acaba por se revelar quando se alteram funcionalidades, se correm testes ou se tratam bugs. O prompt antigo, porém, pode apenas fazer o modelo piorar silenciosamente. O utilizador vê que "o Claude Code parece não ser tão inteligente como antes", ou que "o novo modelo não é tão forte como o anunciam", mas a verdadeira razão pode ser que o system prompt antigo não acompanhou o novo modelo.

Quando o prompt passa de vantagem competitiva a fardo, a Anthropic opta por cortar 80%, melhorando também a eficiência dos tokens.

O "imposto da conversa fiada" do Claude: Cada palavra a mais é dinheiro a mais

O Claude Code tem demasiada conversa fiada.

Este ano, um plugin chamado Caveman tornou-se rapidamente popular, precisamente para resolver este problema. O seu nome significa "homem das cavernas", sugerindo falar como um primitivo – sem educação, sem gramática extra, sem palavras de preenchimento, mantendo apenas o essencial.

À primeira vista, parece uma brincadeira. Mas quando se percebe, vê-se que resolve um problema muito real nos LLMs: demasiada conversa fiada, demasiados tokens, custos desnecessariamente altos.

E a sua origem é precisamente o Claude Code.

"Fiz o Caveman no início de abril, porque estava a usar intensamente o Claude Code e notei que muitos dos meus tokens estavam a ser desperdiçados em texto desnecessário: saudações, expressões vagas, transições, e aquelas conversas informais que não são importantes nos loops dos agentes", disse Julius Brussee, criador do Caveman.

Os testes de Brussee mostram que o Caveman reduz entre 65% a 75% dos tokens de saída em comparação com a saída padrão, ainda assim superando um simples comando "sê conciso". Comprime principalmente a linguagem circundante, sem afetar código, comandos, caminhos, URLs, nomes de funções, que precisam de precisão.

Segundo relatos, o diretor de engenharia da OpenAI, Shayne Sweeney, também contribuiu com código para o projeto, de forma a suportar o Codex.

Mais interessante ainda, a OpenAI já aplicava este padrão de linguagem nas fases de raciocínio.

Alguns reasoning traces que foram divulgados (não os reasoning summaries mostrados ao público) deixaram entrever isto. O conteúdo não é inglês normal, mas sim uma espécie de taquigrafia de engenharia comprimida:

"Use core new nodes. Need infer. Need add VAE encode for images. Try. Try period."

Estas frases parecem engraçadas, até um pouco confusas, mas o seu foco não é a legibilidade, é a eficiência de tokens. Quando o modelo raciocina internamente, não precisa de ser educado, completo e fluente como quando fala com um utilizador. Precisa apenas de reter as ações, objetos, julgamentos e próximos passos. Por outras palavras, desde que a resposta final seja normal, o modelo pode usar uma linguagem mais curta, mais grosseira e que poupe tokens para pensar, na procura louca de eficiência de tokens.

Isto é ainda mais útil do que na fase de escrever prompts. Comprimir os reasoning tokens traz maiores benefícios, porque os agentes executam múltiplos passos, e o pensamento do passo anterior torna-se entrada do passo seguinte. Cada vez que o modelo "pensa" menos, poupa não só os tokens desse momento, mas também os custos repetidos ao longo de toda a cadeia de execução seguinte.

Esta é uma diferença clara entre as abordagens da OpenAI e do Claude.

O Claude sempre foi melhor a conversar, mais um assistente que pensa e se expressa em linguagem completa. Basta ver que os seus reasoning traces são muito mais longos para adivinhar que provavelmente usa inglês comum. As suas saídas e raciocínios são frequentemente mais longos, por isso depende mais de janelas de contexto grandes para os conter.

É também por isso que o Claude usa por defeito uma janela de contexto de 1 milhão de tokens. Muitos pensam que é para conseguir meter bases de código maiores, mas a razão é mais simples: o que o Claude gera é tão longo que sem uma janela grande não cabe. Eles são também maus na compactação – quando recuperas um tópico antigo, o Claude sugere que não mantenhas o contexto completo, mas tentes compactar. Porque não mantêm os reasoning traces – de facto, limpam-nos após 10 a 20 minutos, porque os reasoning tokens são tão ineficientes que não vale a pena mantê-los, senão os custos tornam-se absurdamente inaceitáveis.

Já os modelos da OpenAI têm uma janela de contexto de cerca de 200 mil ou menos, mas como logo de início conseguem compressão através desta linguagem curta, tal é suficiente.

Um detalhe que vale a pena saborear: se a Anthropic corrigir o problema de "demasiada conversa fiada", as suas receitas vão cair significativamente. Se os programadores conseguirem fazer o mesmo trabalho com o modelo, mas gerando menos tokens, esse é dinheiro que eles deixam de ganhar.

Fonte: InfoQ

Aviso de risco e termos de isenção de responsabilidade

        O mercado tem riscos, o investimento requer cautela. Este artigo não constitui aconselhamento pessoal de investimento, nem considera os objetivos, situação financeira ou necessidades específicas de cada utilizador. Os utilizadores devem considerar se qualquer opinião, perspetiva ou conclusão neste artigo se adequa à sua situação específica. Qualquer investimento baseado neste artigo é da responsabilidade do próprio.