“O Claude Code queima tokens demais” tem sido uma das reclamações mais comuns nas comunidades de desenvolvedores nos últimos seis meses — sem ninguém fazendo as contas com honestidade. Em 29 de julho, a Composio, empresa de infraestrutura para agentes, fez os cálculos direito: mesmo modelo, mesmas tarefas, e o consumo de tokens variou até 30 vezes puramente em função do framework de agente (harness) em que o modelo rodava.
Esta não é uma reclamação sobre um único produto. É um sinal: à medida que as capacidades dos modelos convergem e os preços despencam rumo a níveis de commodity, a batalha de custos dos agentes está migrando para a casca invisível que envolve o modelo.
Três Experimentos que Colocaram a Conta na Mesa
Experimento um: o confronto da Composio — taxas de sucesso parecidas, uma conta 6x maior. A Composio colocou o mesmo modelo, o Kimi K3, em três harnesses — Claude Code, Hermes e Kimi Code — e executou 28 tarefas idênticas:
-
As taxas de sucesso ficaram praticamente empatadas: Kimi Code 22/28, Hermes 21/28, Claude Code 20/28.
-
O consumo de tokens se separou por completo: mediana de aproximadamente 61K no Kimi Code, 67K no Hermes e 340K no Claude Code — 6x o Kimi Code, com tarefas individuais chegando a uma diferença de 30x.
-
Em termos monetários (K3 a US$ 3 por milhão de tokens de entrada, com fluxos de trabalho de agentes rodando ~95% de entrada): cerca de US$ 0,22 por tarefa no Kimi Code, US$ 0,28 no Hermes e US$ 2,00 no Claude Code.
-
A velocidade também divergiu: o Hermes foi o mais rápido (mediana de 179 segundos), o Kimi Code o mais econômico (297 segundos) e o Claude Code o mais lento (348 segundos).
Em outras palavras: o modelo se saiu quase de forma idêntica em todos os casos, e só o harness multiplicou o custo por 9. Para economizar, troque a casca antes de trocar o modelo.
Experimento dois: a observação de Sebastian Raschka — o excesso está todo nos tokens de entrada. O conhecido pesquisador de ML relatou o mesmo padrão com o Qwen 3.6: em taxas de sucesso comparáveis, o Claude Code frequentemente consumia 2–3x mais tokens que outros harnesses. Um caso que ele analisou no mês passado: uma execução do Claude Code gastou cerca de 578K tokens de entrada contra aproximadamente 4.500 tokens de saída em 25 turnos. O problema não é um modelo falador — o harness realimenta a cada turno o histórico completo da conversa, chamadas de ferramentas, saídas de comandos e conteúdos de arquivos, então o contexto de entrada vira uma bola de neve.
Experimento três: o teste controlado da Writer — trocar apenas a camada de orquestração cortou o custo em 41%. A plataforma de agentes corporativos Writer fez o teste mais limpo: 22 tarefas empresariais fixas em 6 modelos de base fixos (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6), variando apenas a camada de orquestração. O custo médio por tarefa caiu 41% (US$ 0,21 → US$ 0,12), a latência mediana caiu 44%, o consumo de tokens caiu 38%, enquanto a qualidade das tarefas se manteve praticamente estável (0,78 → 0,81). A qualidade por dólar subiu 82%, e o número de tarefas concluídas por milhão de tokens saltou de 54,9 para 92,0.
Três experimentos independentes convergem para uma conclusão: a eficiência do harness agora é tão decisiva para a economia dos agentes quanto a capacidade do modelo.
A Estrutura: Harness = Agente − Modelo
Boris Cherny, criador do Claude Code, oferece uma fórmula mínima: Harness = Agente − Modelo. A casca em volta do modelo — interface, orquestração de fluxos de trabalho, governança de permissões, memória, observabilidade — é o harness.
Encaixando os experimentos nessa fórmula, surgem duas camadas:
No eixo da eficiência, o harness escreve a sua conta de tokens. Quando as chamadas de ferramentas, as repetições e os loops de múltiplos turnos começam a girar, o custo se multiplica em vez de crescer linearmente — alguns já pedem uma linha de “imposto do harness” nos benchmarks. Quando os modelos viram utilidades, o harness é o ar-condicionado que decide o valor da sua conta de luz.
No eixo do tempo, o harness tem uma validade de seis meses. Em uma entrevista ao YC em 28 de julho, Cherny foi além: quanto mais forte o modelo, mais fina a casca. Seu conselho para quem constrói produtos de IA — apagar o system prompt inteiro e depois devolver as linhas uma a uma, observando o que cada uma realmente faz — é um estudo de ablação em embalagem de produto. Para o Opus 5, ele afirma, a maior parte desse andaime já é desnecessária. Um exemplo interno da Anthropic: entregue ao Opus 5 um binding do OpenCV e ele desenha retratos sem que ninguém peça — ninguém o treinou para desenhar. Isso é elicitação de modelo: a capacidade já vive nos pesos, e o trabalho do harness é liberá-la, não pensar pelo modelo.
Empilhando as duas camadas, chega-se a uma conclusão contraintuitiva: o harness importa, mas não merece um fosso competitivo. Ele pode economizar 9x hoje e ser absorvido pela capacidade nativa do modelo ou achatado por alternativas de código aberto amanhã. A frase mais afiada de Cherny: programação é um problema resolvido — o verdadeiro fosso é o domínio, o conhecimento vertical, os dados e a estrutura organizacional em torno dele.
Três Estágios da Corrida dos Agentes
-
Primeiro tempo: a corrida dos modelos. Parâmetros, benchmarks, preço. Praticamente decidida — modelos abertos emparelharam com os fechados, os preços caíram para centavos por milhão de tokens, e o modelo em si luta para ser uma barreira.
-
Meio: a corrida dos harnesses. Eficiência de orquestração, economia de tokens, ecossistemas de ferramentas. Os experimentos da Composio e da Writer são o tiro de largada — mas a janela é curta, porque os harnesses têm barreiras baixas e iteram rápido. O “prazo de validade de seis meses” de Cherny já está se confirmando.
-
Segundo tempo: a corrida dos domínios. Quem possui os dados verticais e qual organização consegue reconstruir seus processos em torno dos agentes. Em equipes assistidas por agentes, produto, design, dados e finanças todos escrevem um pouco de código; os fluxos de informação e decisão se comprimem. O fosso começa a crescer na organização, não na base de código.
Para fundadores, a dedução é dura, mas esclarecedora: se a proposta de valor do seu produto é essencialmente “construímos um harness melhor”, sua janela é de seis meses a um ano. Redirecione para flywheels de dados e conhecimento do setor — é assim que você sobrevive à guerra de custos.
Três Coisas para Fazer Imediatamente
1. Faça uma ablação no seu próprio fluxo de trabalho. Confie no seu livro-caixa, não nos benchmarks. Apague o system prompt e a lista de ferramentas por completo, devolva as linhas uma a uma e registre o efeito sobre taxa de sucesso, tokens e latência. É provável que você descubra que 80% do seu andaime não rende nada nos modelos mais recentes.
2. Escolha pelo custo por tarefa, não pelo preço por milhão de tokens. O preço de etiqueta não é a conta — a gestão de contexto do harness decide o que você realmente paga. Fique de olho na participação de tokens de entrada e na taxa de repetição: cerca de 95% dos tokens de fluxos de trabalho de agentes são de entrada, e é aí que o dinheiro vaza.
3. Instale disjuntores nas tarefas de longa duração. Loops multiagente e trabalhos noturnos não supervisionados são onde o imposto do harness morde mais forte: inflação de contexto somada a loops de repetição fazem as contas crescerem de forma não linear. Limites de orçamento de tokens e detecção de loops custam muito menos do que ler a fatura depois.
Os modelos são a rede elétrica, o harness é o seu ar-condicionado — e o que de fato agrega valor é o que você instalou no ambiente. O segundo tempo da corrida dos agentes é sobre quem faz mais trabalho com a mesma eletricidade.
