Todos dizem que o Claude Code gasta muito token; afinal, quanto ele gasta? Finalmente, alguém calculou os números.
Recentemente, houve um experimento comparativo interessante da equipe da Composio. Eles usaram o mesmo modelo Kimi K3, executado separadamente em três diferentes frameworks de agentes (harness) — Claude Code, Hermes e Kimi Código—— Foram testados 28 tarefas completamente idênticas.
Como resultado, as três harness tiveram taxas de sucesso semelhantes ao concluir as tarefas: Kimi Code teve 22 sucessos em 28, Hermes teve 21, Claude Code teve 20. A diferença não é grande.
O que realmente faz a diferença é o consumo de tokens. Para a mesma tarefa, o uso de tokens pode variar até 30 vezes dependendo do harness utilizado!
Na mediana, Kimi O código usa aproximadamente 61 mil tokens, Hermes cerca de 67 mil, enquanto o Claude Code dispara para 340 mil, quase Kimi Seis vezes o código.
Clique Kimi Considerando o preço de US$ 3 por milhão de tokens de entrada (os tokens de entrada geralmente representam cerca de 95% no fluxo de agente), o custo médio por tarefa é aproximadamente: Kimi Código 0,22 dólares, Hermes 0,28 dólares, Claude Code chegou a 2 dólares. A diferença é clara.
Também há diferenças na velocidade. O tempo mediano mais curto é do Hermes, com 179 segundos; Kimi Código 297 segundos; Claude Código 348 segundos.
Então o mais rápido é o Hermes, o que consome menos tokens é Kimi Código, os dois não se sobrepõem.
A equipe da Composio chegou a uma conclusão direta: se você quiser reduzir o custo dos agentes, primeiro analise qual harness está sendo usado, em vez de trocar o modelo imediatamente. Seus dados mostram que o harness sozinho pode aumentar o custo em até 9 vezes, enquanto o desempenho dos modelos é praticamente o mesmo.
Sebastian Raschka também postou sobre esse resultado, dizendo que é semelhante às observações que ele fez anteriormente com o Qwen3.6: o Claude Code usa geralmente duas a três vezes mais tokens do que muitos outros harness, com taxas de sucesso semelhantes.
Ele levantou algumas possíveis causas: será que não foi bem otimizado? Há algum bug? Ou foi intencionalmente projetado assim (pois pode ser útil em tarefas mais difíceis)? Ele afirmou que precisa dedicar mais tempo para investigar cuidadosamente.
Em seguida, ele acrescentou as observações feitas ao escrever o artigo sobre agentes de codificação local no mês passado. Na ocasião, ele analisou por que o Claude Code utilizava mais tokens e descobriu que a diferença estava principalmente nos tokens de entrada, e não nos tokens de saída. Ou seja, o Claude não estava gerando o dobro do conteúdo. Os logs mostram que o harness do Claude, durante interações múltiplas, repete constantemente mais contexto de volta ao modelo, incluindo mensagens anteriores, chamadas de ferramentas, saídas de comandos e conteúdo de arquivos. Por exemplo, em uma ocasião, o Claude utilizou cerca de 578 mil tokens de entrada, mas apenas cerca de 4.500 tokens de saída, distribuídos em 25 rodadas. Portanto, a explicação mais provável é que o harness do Claude, durante execuções de agente em múltiplos passos, acumula ou considera um histórico maior na extremidade do prompt.
These test results appear to reveal a trend that cannot be ignored: the importance of harness is now on par with the model itself.
Um artigo recente (da Writer, uma empresa que desenvolve uma plataforma de agentes de IA empresarial) sistematicamente demonstrou isso: por meio de experimentos com variáveis controladas, provou que trocar a camada de harness é mais eficaz para reduzir custos do que trocar o modelo, e todos os modelos se beneficiam.
Especificamente, eles realizaram um experimento rigoroso de “variáveis controladas”: mantendo fixos 22 tarefas empresariais e 6 modelos básicos (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6), substituíram apenas a camada de orquestração — trocando o ciclo de agente de produção tradicional pelo Harness próprio da Writer.
Os resultados do experimento mostram: redução média de 41% no custo por tarefa (de US$ 0,21 para US$ 0,12), redução de 44% na latência mediana (de 48 segundos para 27 segundos) e diminuição de 38% no consumo de tokens (de 14,2k para 8,8k), enquanto a qualidade de conclusão das tarefas permaneceu基本mente estável (0,78 para 0,81, considerando-se a pequena amostra como sem diferença significativa). Em termos de custo-benefício, o aumento na qualidade por dólar custo foi de até 82%, e o número de tarefas concluídas por milhão de tokens aumentou de 54,9 para 92,0.
Então, após o modelo se tornar "água, luz e gás", o harness é o ar condicionado que determina sua conta de energia? Em outras palavras: antes, diziam-se "modelo é produto"; agora, é "harness é produto"?
Since harness is so important, shouldn't the subsequent accounting be more detailed?
Alguém apontou que é necessário adicionar o item "imposto do harness" aos benchmarks existentes. Especialmente considerando que, uma vez que chamadas de ferramentas e repetições entrem em um loop, esse imposto não cresce linearmente.
Em outras palavras, na competição de agentes futuros, a primeira metade será sobre “se é possível fazer”, e a segunda metade será sobre “quem faz a mesma coisa com menos custo” — e o segredo para economizar não está no modelo, mas no harness.
Durante a execução do Agent, você já teve uma experiência semelhante? Comente abaixo.
Este artigo é do canal oficial do WeChat "Machine Heart" (ID: almosthuman2014), autor: Machine Heart