- Medindo a fronteira da API no mesmo modelo, máquina e tarefa, o overhead fixo da primeira requisição no Sonnet 4.5 foi de cerca de 32.800 tokens no Claude Code e cerca de 6.900 tokens no OpenCode, uma diferença de 4,7x; no Fable 5 essa diferença caiu para cerca de 3,3x
- A maior parte da diferença vem dos schemas de ferramentas. O Claude Code usou cerca de 24.000 tokens para definir 27 ferramentas, enquanto o OpenCode usou cerca de 4.800 tokens para 10 ferramentas; mesmo com todas as ferramentas desativadas, os prompts de sistema ainda tinham cerca de 6.500 tokens e 2.000 tokens, respectivamente
- Em uma configuração real, um arquivo de instruções de 72 KB adicionou cerca de 20.000 tokens por requisição, e um único servidor MCP pequeno adicionou cerca de 1.000 a 1.400 tokens, fazendo a primeira requisição chegar a 75.000~90.817 tokens
- No mesmo trabalho de resumir arquivos, o Claude Code gerou 5,9 a 54 vezes mais gravações de cache do que o OpenCode; ao distribuir a tarefa entre dois subagentes, o uso saltou de 121.000 tokens em execução direta para 513.000 tokens, um aumento de 4,2x
- Não dá para julgar o custo total apenas pelo overhead fixo. Em tarefas de múltiplas etapas, o Claude Code agrupou chamadas de ferramenta em paralelo e usou cerca de 121.000 tokens em 3 requisições, enquanto o OpenCode usou cerca de 132.000 tokens em 9 chamadas seriais
Como foi medido na fronteira da API
- Foi colocado um proxy de logging entre o Claude Code e o OpenCode para registrar o JSON exato enviado pelo harness e o bloco de uso retornado pela API
- O corpo da requisição incluía blocos de sistema, schemas de ferramentas e mensagens
- O uso incluía tokens de entrada, gravações e leituras de cache e tokens de saída
- O corpo capturado da requisição foi usado como o conteúdo realmente transmitido, e o bloco de uso da API como base do valor realmente cobrado
- Na comparação básica foram usados Claude Code 2.1.207 e OpenCode 1.17.18, ambos fixados em
claude-sonnet-4-5com base em julho de 2026- Parte das medições de overhead fixo, operações de cache e tarefas de múltiplas etapas também foi refeita com
claude-fable-5 - Os valores padrão foram isolados em um diretório de configuração novo, sem servidor MCP, sem configurações de usuário, sem memória e em um workspace vazio, sem arquivos de instrução
- Parte das medições de overhead fixo, operações de cache e tarefas de múltiplas etapas também foi refeita com
- Três tarefas mediram estruturas de custo diferentes
- T1 isolou o overhead fixo com
Reply with exactly: OKe foi executada 3 vezes por harness - T2 pedia para ler um arquivo preparado previamente e fazer um resumo
- T3 executava o procedimento de escrever, rodar, testar e corrigir sobre FizzBuzz e um script de verificação
- T1 isolou o overhead fixo com
- Para comparar os prompts de sistema sem os schemas de ferramentas, foi aplicado
--tools ""no Claude Code e"tools": {"*": false}no OpenCode - O gateway LLM local adicionava um envelope fixo de cerca de 6.200 tokens por requisição, que foi corrigido e excluído das medições
- Os números por componente foram calculados a partir do corpo capturado da requisição, que o gateway não podia alterar
- Para converter caracteres em tokens, foi usada uma proporção medida em cache frio de 1 token a cada 4,1~4,4 caracteres, dependendo do harness
Os schemas de ferramentas aumentam o overhead básico
- Na primeira requisição do prompt T1, com 22 caracteres, o Claude Code enviou cerca de 32.800 tokens e o OpenCode cerca de 6.900 tokens
- O prompt de sistema do Claude Code tinha 3 blocos e 27.344 caracteres; o do OpenCode tinha 1 bloco e 9.324 caracteres
- Os schemas das 27 ferramentas do Claude Code tinham 99.778 caracteres; as 10 ferramentas do OpenCode tinham 20.856 caracteres
- Antes do prompt real, o Claude Code inseria um bloco
<system-reminder>de 7.997 caracteres com tipo de agente, habilidades disponíveis e contexto do usuário - O OpenCode enviava o bloco de sistema, 10 ferramentas de programação e o prompt do usuário, sem scaffolding separado para a primeira mensagem
- Em ambos os lados, as definições de ferramentas representavam a maior parte do volume
- Dos cerca de 33.000 tokens do Claude Code, cerca de 24.000 eram definições de ferramentas
- Dos cerca de 6.900 tokens do OpenCode, cerca de 4.800 eram definições de ferramentas
- As ferramentas do Claude Code incluíam não só funções de programação, mas também
CronCreate,Monitor, a famíliaTask, gerenciamento de árvore de tarefas, notificações push e outros recursos de agentes em segundo plano e orquestração
- Removendo todas as ferramentas, o prompt de sistema do Claude Code ficava com 26.891 caracteres, cerca de 6.500 tokens; o OpenCode ficava com 8.811 caracteres, cerca de 2.000 tokens
- Nos dois harnesses, o prompt encolhia um pouco quando as ferramentas eram desativadas
- A diferença restante vinha de instruções de comportamento, como tom, diretrizes de segurança, regras de gerenciamento de tarefas e informações de ambiente
- No Fable 5, o Claude Code encurtava o prompt dependendo do modelo, reduzindo a diferença para cerca de 3,3x
- As instruções de sistema caíram de 27.787 caracteres no Sonnet para 10.526 no Fable
- Mantendo as mesmas 27 ferramentas, o schema também caiu de 99.778 para 82.283 caracteres
- As requisições do OpenCode eram idênticas em bytes nos dois modelos
O uso total muda conforme o tipo de tarefa
- Em T2, de leitura e resumo de um arquivo, os dois harnesses produziram resultados corretos, mas com estruturas de requisição diferentes
- O Claude Code usou 6 requisições HTTP e cerca de 199.000 tokens de entrada acumulados
- O OpenCode usou 4 requisições e cerca de 41.000 tokens, com mais 1 chamada ao Haiku para gerar o título da sessão
- A maior parte do uso veio de leituras de cache, cobradas a um décimo do preço da entrada
- Mesmo com desconto de cache, a gravação de cache da primeira requisição, a leitura de cache a cada turno e a ocupação da janela de contexto crescem com o tamanho do payload
- A linha de base de 33.000 tokens já consome cerca de um sexto de uma janela de 200.000 tokens antes mesmo de o código entrar
- Em T3, tarefa de escrever, rodar, testar e corrigir, a forma de chamar ferramentas compensou a diferença de overhead básico
- O Claude Code agrupou 2 escritas de arquivo e 2 execuções de script em um único round-trip paralelo de ferramentas, registrando 3 requisições ao modelo e cerca de 121.000 tokens de entrada acumulados
- O OpenCode chamava apenas uma ferramenta por turno, registrando 9 requisições, mais 1 chamada de título, e cerca de 132.000 tokens de entrada acumulados
- A entrada total foi determinada aproximadamente por linha de base por requisição multiplicada pelo número de requisições, mais o crescimento da conversa
- Conforme a conversa avançava, o Claude Code aumentava os
<system-reminder>de 3 no primeiro turno para 4 no momento do primeiro round-trip de ferramenta - No OpenCode, o payload adicional por turno era de cerca de 400~2.200 caracteres, crescendo apenas com o conteúdo da conversa
Tokens adicionados por configurações reais
- Ao adicionar o
AGENTS.mdde 72 KB de um repositório de produção, os dois harnesses aumentaram em mais de 20.000 tokens por requisição- A medição do OpenCode subiu de 13.152 tokens para 33.336 tokens
- O Claude Code passou de 39.005 tokens para 59.243 tokens
- O Claude Code 2.1.207 ignorava
AGENTS.md; era preciso renomear paraCLAUDE.mdpara inseri-lo na primeira mensagem do usuário - O OpenCode lia os dois nomes de arquivo e os inseria no prompt de sistema
- Se você não verificar quais nomes de arquivo o harness realmente reconhece, o arquivo de instruções pode ser ignorado silenciosamente
- Um servidor MCP público e pequeno adicionava cerca de 1.000 a 1.400 tokens por requisição, por servidor
- Cinco servidores adicionaram 4.900 tokens ao payload do Claude Code e 6.967 tokens à medição do OpenCode
- O número de ferramentas subiu de 27 para 69 no Claude Code e de 10 para 52 no OpenCode
- Servidores de produção com APIs mais ricas podem enviar schemas maiores
- O modo print do Claude Code ignorava silenciosamente o
.mcp.jsonno escopo do projeto se não houvesse--mcp-configexplícito, então era preciso verificar na fronteira da API se a conexão realmente ocorreu
- Frameworks de workflow baseados em histórias, como BMAD, expandem templates grandes com personas, protocolos e checklists por meio de comandos slash
- O template de 8.405 caracteres do experimento equivalia por si só a cerca de 2.100 tokens, mas entrava no histórico da conversa e era reenviado em todas as requisições seguintes
- Em uma sessão com 9 requisições, o mesmo template era carregado 9 vezes, então o custo crescia como tamanho do template × número de requisições
- A primeira requisição em configurações reais ficou muito maior que o overhead básico
- O OpenCode, com 11 servidores MCP para email e calendário, gerenciamento de tarefas, bibliografia, análise de produto etc. e um arquivo de instruções de 72 KB, registrou 179 ferramentas, 277 KB de schema e 90.817 tokens de gravação em cache frio
- O Claude Code, com 4 servidores MCP, plugins instalados e o mesmo arquivo de instruções, registrou 118 ferramentas, 311 KB de payload e cerca de 75.000 tokens
- Descontando o envelope do gateway, a configuração do OpenCode era cerca de 12x maior que o padrão, que ficava em torno de 7.000 tokens
O custo de subagentes e pensamento estendido
- Quando o Claude Code distribuiu a tarefa em paralelo para dois subagentes, os 121.000 tokens da execução direta subiram para 513.000 tokens, um aumento de 4,2x
- Houve 9 requisições ao modelo no total, em três tipos de requisição: sessão principal, chamadas de subagentes e outras relacionadas
- As 5 chamadas de subagentes faziam bootstrap próprio com prompt de sistema de 3.554 caracteres e 24 ferramentas das 27 padrão
- Cada subagente arcava com o custo inicial e o pai ainda relia o histórico dessas execuções
- Os subagentes do OpenCode enviavam um perfil reduzido, com prompt de sistema de 1.379 caracteres e apenas 5 ferramentas
- Como a execução via gateway não foi concluída normalmente, o uso total de subagentes do OpenCode não foi quantificado
- Foi comparada apenas a diferença de design confirmada no payload capturado
- A saída de pensamento estendido é cobrada pela tarifa de saída, 5x maior que a de entrada, e os blocos de raciocínio entram no histórico da conversa e são reenviados nas requisições seguintes
- Como a política de raciocínio do próprio gateway impedia confirmar se as configurações dos dois harnesses estavam realmente sendo aplicadas, os números medidos não foram divulgados
- Ficou apenas confirmada a estrutura de custo em que os blocos de raciocínio passam a integrar o histórico
Economia e estabilidade do cache de prompt
- Ambos os harnesses configuravam corretamente os breakpoints de cache. O payload era gravado uma vez por 1,25x o preço normal de entrada, considerando TTL de 5 minutos, e depois lido a um décimo do preço
- Há três custos que o cache não reduz
- Se houver uma pausa de mais de 5 minutos, é preciso gravar toda a pilha de novo; então, depois de intervalos como reuniões ou almoço, o custo de gravação reaparece
- Leituras de cache também se repetem conforme o número de requisições, então loops seriais de ferramenta e distribuição para subagentes aumentam o custo
- A ocupação da janela de contexto não é afetada pelo desconto do cache; um bootstrap de 85.000 tokens ocupa mais de 40% de uma janela de 200.000 tokens e, quando a compressão começa, ainda surge custo de sumarização
- O OpenCode manteve um prefixo idêntico em bytes em todas as requisições e execuções capturadas
- Nas três sessões de T1, os bytes de ferramentas, sistema e mensagens eram idênticos, e as gravações de cache nas execuções repetidas foram 0
- A sessão T3, com 9 requisições, também manteve um prefixo estável
- O Claude Code criava tipos diferentes de requisição e itens de cache por sessão, como exploração de aquecimento, conversa principal e chamadas de subagentes
- Mesmo no mesmo workspace, os bytes do sistema e o scaffolding da primeira mensagem mudavam entre execuções
- No mesmo trabalho de resumo de arquivo, ele gravou 53.839 tokens de cache ao longo de 5 requisições e regravou uma vez, no meio do trabalho, quase todo o prefixo de cerca de 43.000 tokens
- No mesmo trabalho, o OpenCode gravou 1.003 tokens de cache
- As grandes regravações intermediárias de cache do Claude Code apareceram também em experimentos repetidos
- Nas duas primeiras execuções, ele regravou 43.342 tokens e 36.899 tokens, respectivamente; na terceira execução, usando um cache recém-aquecido, quase não gravou nada
- No Fable 5, também regravou 50.053 tokens sem leitura de cache, gerando uma diferença de 52x, semelhante aos 54x do Sonnet
- Dependendo da temperatura do cache, o volume de gravação de cache do Claude Code foi 5,9 a 54 vezes o do OpenCode
- O preço da gravação em cache é 1,25x no nível de 5 minutos e 2x no nível de 1 hora
- Uma única falha de cache pode ter sido causada por expulsão no gateway, mas o comportamento se repetiu em várias execuções e a instabilidade do prefixo também foi confirmada nos bytes capturados antes da requisição
- Quando o prefixo é grande, tem muitos tipos, é regravado repetidamente e ainda há subagentes, o medidor de uso do Claude Code pode subir mais rápido
Qualidade dos resultados e logs de auditoria
- Os dois harnesses concluíram corretamente todas as tarefas avaliadas
- Os resumos de arquivo estavam corretos em ambos os casos
- A tarefa de múltiplas etapas passou no script de verificação escrito por cada harness e terminou com sucesso
- Nesse escopo, foi possível comparar a diferença de custo em tokens para chegar ao mesmo resultado
- Não foi medido se, em tarefas reais de engenharia mais difíceis, os agentes em segundo plano, skills e orquestração do Claude Code aumentam a qualidade o suficiente para justificar o custo extra
- Para julgar isso, seria necessário um conjunto de testes apropriado, execuções suficientes e avaliação de taxa de aprovação
- Também foi identificado desperdício sem relação com qualidade
- Regravar no meio da sessão um prefixo de cache com bytes idênticos equivale a recomprar o mesmo conteúdo por um preço premium
- Se o harness ignora silenciosamente um arquivo de instruções, não há qualquer benefício vindo desse arquivo
- Os 185 registros de requisição e resposta capturados foram gravados em uma cadeia de hash SHA-256 com a biblioteca open source
@systima/aiact-audit-log- A cadeia foi verificada do início ao fim sem interrupções, e o resultado de integridade foi
VALID - Com a mesma estrutura, é possível reconstruir o conteúdo de envio e resposta e fornecer evidências de integridade a terceiros
- Esse é o mesmo método de registro estruturado oferecido para logging no Article 12 do EU AI Act
- A cadeia foi verificada do início ao fim sem interrupções, e o resultado de integridade foi
Limitações da medição e como reproduzir
- Os resultados são um snapshot de julho de 2026 com uma única máquina, duas versões de harness e uma amostra pequena
- T1 e T2 foram executados 3 vezes cada, e cada condição de multiplicação de configuração foi rodada 1 vez
- Os valores padrão e as condições de cache usaram Sonnet 4.5 e Fable 5, enquanto as condições de multiplicação de configuração usaram apenas um modelo
- Como os prompts dos harnesses mudam com frequência, o método de medir na fronteira da API tende a durar mais que os números pontuais
- Havia um gateway local no caminho da medição
- Os números por componente usaram o corpo da requisição, que o gateway não podia alterar
- As medições corrigiram o envelope fixo com base em referência de cache frio e excluíram números de execuções aquecidas quando a causa não podia ser separada
- Houve caso em que o gateway trocou silenciosamente por um snapshot mais novo do que o modelo fixado, então o modelo real de resposta também precisa ser verificado na fronteira
- No caminho Fable, houve retomada de sessão antiga do servidor e execução de ferramenta no host, por isso os resultados de múltiplas etapas do Claude Code com Fable foram excluídos
- A convergência de custo de T3 é uma observação única em um único tipo de tarefa
- Em tarefas que exigem execução estritamente sequencial, o número de requisições e o uso total do Claude Code podem voltar a subir
- As condições de remoção de ferramentas e de subagentes do OpenCode retornaram stream incorreto no gateway, então foi usado apenas o tamanho do payload capturado
- Os números de configuração real pertencem ao setup de um único usuário e podem variar em outros ambientes
- O aparato de reprodução é um proxy HTTP com cerca de 200 linhas de código Node
- Ele encaminha requisições para o endpoint do modelo enquanto grava em disco e na cadeia de auditoria o corpo da requisição e o bloco de uso da resposta
- Basta apontar
ANTHROPIC_BASE_URLpara o proxy e medir os valores padrão em um diretório de configuração novo e workspace vazio, adicionando depois, um por um, arquivos de instrução, servidores MCP e workflows - Se você usar um gateway, primeiro precisa medir seu próprio envelope com uma requisição mínima e confirmar qual modelo realmente está respondendo
- Se você tiver logging na fronteira da API para reconstruir exatamente o que um agente de produção enviou ao modelo em um dado momento, também passa a ter contabilidade de tokens
1 comentários
Comentários do Hacker News
Quem realmente queima muitos tokens são os subagentes. Dei uma tarefa grande ao Claude Code e ele imediatamente iniciou 7 subagentes; antes que qualquer um terminasse, o orçamento já tinha acabado. Tentei de novo 5 horas depois e aconteceu a mesma coisa
Quando faço o agente principal executar a mesma tarefa de forma sequencial, não há problema nenhum. Não sei se isso é tão ineficiente por causa do custo de comunicação e coordenação, ou se a Anthropic está tentando aumentar a receita porque quem usa subagentes em geral está em contas corporativas e paga por token
Já se a ideia for aplicar em paralelo uma tarefa bem planejada a vários alvos, é preciso especificar que os subagentes reduzam o nível para um modelo menos curioso. A consistência dos resultados também pode melhorar
Em execução sequencial, os arquivos são lidos mais ou menos uma vez só, e todas as requisições aproveitam o mesmo cache de prefixo
Nesse ambiente, a melhor estratégia pode ser colocar primeiro os novos recursos no plano mais caro, recuperar o custo e depois descer para os planos inferiores, ou chutar a escada para dificultar que concorrentes acompanhem
Mas, na etapa de validação, ele tentou iniciar 41 agentes de validação Fable. De algum jeito ele sempre acha uma brecha
Acho que o Claude Code usa muitos tokens porque a Anthropic quer ganhar mais dinheiro e empurrar os usuários para assinaturas. A política de não permitir usar os benefícios da assinatura em outros agentes de programação reforça isso. Eu uso pi
API e enterprise representam 75% a 85% da receita total, assinaturas corporativas cerca de 10% a 15%, e assinaturas pessoais cerca de 5%
Como na analogia pertinente do PUSH_AX, isso é como uma empreiteira A cobrar 33 mil dólares e a B cobrar 7 mil dólares, então precisamos verificar se estamos medindo a coisa certa
Por isso, vou adicionar ao post tarefas mais profundas, comparação qualitativa dos resultados e, se possível, materiais para reproduzir entrada e saída o mais rápido possível
Não é só o problema dos prompts de sistema grandes. O ambiente de execução dos agentes de programação também está usando ferramentas de forma mais agressiva, mesmo para solicitações triviais. Em testes, prompts como “Hey” ou “commit” às vezes geraram mais de 30 chamadas de ferramenta
https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
Dá para ver de fato uma inflação de tokens em que tarefas simples seguem consumindo cada vez mais tokens
A culpa também é minha por ter escrito nas regras que toda mudança deve ser validada por testes, mas se vão enfatizar tanto o I de AI, eu esperaria pelo menos discernimento suficiente para não colocar tomate numa salada de frutas
Depois de usar Claude por 6 meses, recentemente migrei para o Codex. O Codex é mais aberto, é mais fácil acompanhar como o modelo trabalha, e a experiência do fluxo de aprovação também é melhor. No geral, há mais transparência, e o custo de migração foi quase zero
Não gosto que o Claude tenha ficado mais opaco desde por volta de fevereiro, inclusive no prompt de sistema, e 33 mil tokens parecem demais
Recentemente a OpenAI ficou muito mais amigável ao consumidor
O agente pi tem um prompt de sistema menor, e o conteúdo completo pode ser visto aqui
https://github.com/earendil-works/pi/blob/main/packages%2Fco...
cmda cada chamada do prompt de sistema invalida o cacheSe só for invalidado quando a data ou o diretório raiz mudam, na prática isso já é algo suficientemente raro
No fim, o que importa não é o tamanho bruto do prompt. Se fosse, o Pi e suas variações deveriam ter o menor custo. O ponto central é a eficiência do prompt, e minimalismo de prompt e eficiência são coisas frequentemente confundidas. Ainda assim, o Claude Code parece inchado demais para o que faz
Mais importante ainda é a qualidade das ferramentas. Ferramentas ruins ou com bugs aumentam muito as chamadas de ida e volta, apagando qualquer vantagem que se queria economizar no início
Há alguns meses, fiz um benchmark completo de 7 agentes em 8 tarefas, e os dados e rastros estão em https://github.com/dirac-run/dirac. Tenho ligação direta com um deles, então não posso alegar neutralidade, mas o material é reproduzível. Como a maioria das tarefas está relacionada a refatoração, o Dirac venceu com grande folga por se destacar em ancoragem por hash e análise de árvore sintática abstrata
No trabalho sou obrigado a usar Claude Code, mas dá para resolver facilmente com
--system-prompt "". Seria bom se também permitissem outros ambientes de execução--system-prompt "", isso não remove até mesmo o prompt de sistema básico de que o modelo precisa para entender quais ferramentas estão disponíveis?Quando experimentei um modelo local pela primeira vez, conectei ao Claude Code e ele funcionou muito bem, mas era lento
Com a ajuda do Claude, configurei o mitmproxy e capturei o prompt de sistema inicial completo do Claude Code e, ao conferir de novo, deu 162 KB de JSON. Isso me levou a começar a experimentar Pi, OpenCode e Hermes
/contextem uma nova sessão do Claude Code agora, ele mostra que só usa 23 mil tokens do contexto de 1 milhão de tokens do Opus 4.8. Aparecem prompt de sistema 3,9 mil, ferramentas do sistema 13,9 mil, agente personalizado 235, arquivo de memória 28, recursos 4,9 mil, mensagens 8 e buffer comprimido 3 mil tokens4 mil tokens de prompt de sistema dão cerca de 15~20 KB. Eu até pediria para você colocar o conteúdo capturado em um Gist, mas pode haver dados sensíveis, e é bem possível que esses 162 KB visíveis não sejam só o prompt de sistema
O que eu fiz envia menos: https://maki.sh
Mas resumir conversas anteriores não acaba, na prática, invalidando o cache de contexto, fazendo você usar menos tokens, porém tokens mais caros?