AI coding agents estão queimando dezenas de milhares de tokens antes mesmo de lerem seu prompt

Antes de um AI coding agent ler uma única palavra que você digita, ele já gastou milhares de tokens se apresentando: system prompts, tool schemas, lembretes de scaffolding. Uma comparação independente recente de dois agent harnesses populares, Claude Code e OpenCode, mediu essa sobrecarga diretamente usando um proxy de logging que capturou os payloads JSON exatos enviados à API do modelo. A diferença foi grande o suficiente para mudar a forma como qualquer pessoa que executa essas ferramentas em escala deve pensar sobre custo.

Em uma baseline de primeira interação no Claude Sonnet 4.5, o Claude Code enviou cerca de 32.800 tokens antes que o prompt real do usuário fosse processado. O OpenCode enviou cerca de 6.900 tokens para a mesma tarefa — uma diferença de 4,7x. A disparidade se reduz para 3,3x em modelos mais novos, mas não desaparece. Essa sobrecarga é invisível no uso normal: você digita um prompt, recebe uma resposta e nunca vê o payload que foi enviado por baixo dos panos. Mas ela é cobrada como todo o resto, e se agrava de maneiras que importam quando você sai de exemplos simples.

Para onde os tokens realmente vão

A sobrecarga se divide em três componentes mensuráveis. Os system prompts respondem pela menor parcela, mas ainda assim relevante: o system prompt do Claude Code tem 27.344 caracteres (cerca de 6.500 tokens), contra 9.324 caracteres (~2.000 tokens) do OpenCode. Os tool schemas são o custo maior — o Claude Code carrega 27 definições de ferramentas totalizando cerca de 99.778 caracteres (~24.000 tokens), enquanto o conjunto mais enxuto de 10 ferramentas do OpenCode fica em 20.856 caracteres (~4.800 tokens). O restante é scaffolding: o Claude Code injeta blocos de lembrete, catálogos de agentes e enquadramento de contexto antes da mensagem real do usuário; o OpenCode não adiciona nada disso por padrão.

Nada disso é desperdício no sentido de ser inútil — mais ferramentas e scaffolding mais rico geralmente significam que o agent pode fazer mais sem fazer perguntas esclarecedoras. É uma troca real de design entre capacidade por requisição e custo por requisição, e é uma que a maioria dos usuários nunca consegue ver, muito menos escolher.

A diferença piora com configurações realistas

Os números base subestimam o custo real de setups em produção. Adicione um arquivo de instrução do projeto típico de 72KB (o tipo de arquivo CLAUDE.md ou AGENTS.md que a maioria das bases de código sérias agora mantém) e ambos os harnesses ganham cerca de 20.000 tokens adicionais por requisição — esta parte é orientada pela configuração, não pelo harness, então afeta ambas as ferramentas igualmente. Acrescente cinco servidores MCP (Model Context Protocol), uma configuração comum para equipes conectando Slack, Jira, bancos de dados ou APIs internas, e cada servidor adiciona de 4.900 a 6.967 tokens por requisição apenas para anunciar suas ferramentas disponíveis.

Empilhando tudo isso, uma configuração de produção realista chega a 75.000 a 85.000 tokens antes que o usuário tenha digitado uma única palavra de sua requisição real. Em uma janela de contexto de 200.000 tokens, isso representa mais de 40% do espaço disponível consumido por scaffolding antes que qualquer código seja escrito ou lido.

O comportamento de caching é onde a real divergência de custo acontece

A diferença mais consequente não é a contagem base de tokens — é o que acontece com essa sobrecarga ao longo de uma sessão. O OpenCode mantém um prefixo de requisição byte-idêntico entre as interações, o que significa que o prompt caching funciona quase perfeitamente: os mesmos tokens são reutilizados do cache turno após turno com reescritas mínimas.

O scaffolding do Claude Code, por outro lado, é reescrito no meio da sessão — novos blocos de lembrete, contexto atualizado, estado de ferramentas renovado — o que força o cache a ser invalidado e reconstruído repetidamente. O volume medido de cache-write para o Claude Code variou de 5,9x a 54x o do OpenCode, dependendo de quão "quente" o cache estava no momento da medição. Cache writes não são gratuitos: eles são cobrados com um prêmio de 1,25x sobre a taxa de input base para um TTL padrão de 5 minutos. Um harness que está constantemente reescrevendo seu próprio cache paga esse prêmio com muito mais frequência do que um que não o faz.

Subagents multiplicam o problema, não apenas somam a ele

O número mais gritante na comparação envolve delegação. Uma tarefa que custou 121.000 tokens cumulativos quando executada diretamente custou 513.000 tokens quando o mesmo trabalho foi distribuído para dois subagents — um aumento de 4,2x para o que, em princípio, deveria ser a mesma quantidade total de trabalho dividido. Cada subagent paga integralmente a sobrecarga base (system prompt, tool schemas, scaffolding) de forma independente; a delegação não compartilha esse custo, ela o multiplica pelo número de agents gerados.

Isso importa diretamente para como as equipes devem arquitetar workflows agentic. Distribuir uma tarefa para subagents é frequentemente apresentado como uma vitória pura de paralelismo — mais agents, menos tempo de relógio. A contabilidade de tokens conta uma história diferente: é uma troca de custo real, e para tarefas pequenas ou médias, a multiplicação da sobrecarga pode superar qualquer tempo economizado.

O que fazer com isso na prática

Curiosamente, em tarefas complexas de múltiplas etapas, os harnesses convergem: Claude Code usou 121.000 tokens cumulativos em 3 requisições (agrupamento agressivo de tool calls), enquanto OpenCode usou 132.000 tokens em 9 requisições serializadas. Para trabalhos genuinamente complexos, a diferença de sobrecarga base importa menos porque é amortizada por mais trabalho real por requisição.

As conclusões práticas: audite o tamanho do seu arquivo CLAUDE.md/AGENTS.md — esse imposto de 20.000 tokens atinge cada requisição, independentemente do harness. Seja deliberado sobre quantos servidores MCP você mantém ativos; cada um é um custo fixo por requisição, quer você o use ou não em uma determinada interação. E trate a distribuição para subagents como uma decisão de custo, não apenas de velocidade — reserve-a para tarefas grandes o suficiente para que o multiplicador de sobrecarga de 4x valha a pena pagar pelo paralelismo.