Quanto custa cada padrão de uso do Claude Code

90% do que você paga é o agente relendo o próprio contexto. Só 10% é o que ele escreve.

Eu achava que era o contrário. A intuição de quem usa é que o custo está na resposta, porque a resposta é a parte que você vê. Medi 48.120 turnos de trabalho real e a conta não fecha nem perto disso.

Leia isto antes dos números, porque muda como interpretá-los.

O que foi medido. Todas as sessões locais do Claude Code na minha máquina entre 29 de junho e 20 de agosto de 2026: 67 sessões, 26 projetos, 48.120 turnos de assistente precificados. Outros 86 turnos ficaram de fora por serem mensagens sintéticas do próprio Claude Code, sem cobrança associada. O Claude Code grava cada turno em JSONL sob ~/.claude/projects/, com input_tokens, cache_creation_input_tokens, cache_read_input_tokens, output_tokens e os tokens de raciocínio. Extraí só os contadores e os metadados, nunca o conteúdo das mensagens.

Os valores em dólar são preço de tabela da API, e não o que eu paguei. Eu uso assinatura. Converti os tokens pelas taxas públicas da Claude API para ter uma unidade comparável entre padrões de uso. Trate os valores como peso relativo, não como fatura. As proporções são o que transfere para o seu caso; os totais, não.

Se o seu caso é o oposto do meu — pagamento por token, em volume, sem assinatura no meio —, a conta que importa é outra, e ela está em onde o dinheiro vaza em produção.

Onde isso é fraco. Um operador só, uma janela de sete semanas, mix de projetos de web e conteúdo. Não é benchmark controlado, e não roda a mesma tarefa em condições diferentes. Cinco modelos aparecem na amostra (Fable 5, Opus 5, Opus 4.8, Sonnet 5 e Haiku 4.5) e 22 versões distintas do Claude Code. O nível de esforço fica concentrado em xhigh, o que puxa os tokens de raciocínio para cima em relação a quem roda no padrão.

A detecção de compactação é heurística. Contei como evento toda queda de leitura de cache abaixo de 55% do valor anterior, partindo de um pico acima de 150 mil tokens. Isso captura compactação e pode capturar também um /clear ou reinício de sessão. Declaro o critério para você julgar.

A tabela que reorganizou minha cabeça:

Somando as duas primeiras linhas: quase 90% da conta é contexto entrando e saindo do cache. O que o modelo produz é um décimo.

Isso tem uma consequência prática que parece contraintuitiva: pedir uma resposta mais longa é barato; ter uma conversa mais longa é caro. Duplicar o tamanho da resposta mexe em 10% da conta. Duplicar o tamanho do histórico mexe nos outros 90%, e mexe em todo turno seguinte, não só naquele.

O turno mais caro de toda a amostra ilustra isso melhor que qualquer explicação. Um único turno em Opus 5, com 989.308 tokens gravados em cache de uma hora e 1.075 tokens de saída:

Dez dólares num turno, e 99,7% disso foi guardar contexto. O que o modelo escreveu custou menos de três centavos.

Cada requisição reenvia a conversa inteira. Conforme ela cresce, cresce o que precisa ser lido do cache em todo turno. A curva medida:

Três coisas nessa tabela.

A subida é real e previsível. Do bloco 1-10 ao bloco 401-800, o custo por turno multiplica por 3,3, e a leitura de cache média por 12,9. A mesma pergunta, feita cedo ou tarde na sessão, tem preços diferentes.

A faixa 11-25 é mais barata que a 1-10. Os primeiros turnos carregam CLAUDE.md, memória, definições de ferramenta e descrições de skill, tudo escrito no cache a preço de escrita. Depois disso, o prefixo passa a ser lido, que é dez vezes mais barato. A partida custa mais que o cruzeiro, e é o argumento econômico para manter o CLAUDE.md enxuto: ele é gravado a preço cheio em toda sessão nova.

O platô no fim não é economia de escala. Do bloco 401-800 para o 801+, o custo por turno cai de US$ 0,750 para US$ 0,732. Isso é a compactação automática segurando o contexto num teto. A sessão não fica mais eficiente; ela para de crescer porque algo apara.

O mecanismo por trás disso está em por que seu agente esquece.

318 eventos de compactação, em 62 sessões com mais de 20 turnos.

Convertido em dinheiro, por turno seguinte:

O ponto que importa: essa economia não é do turno em que você compacta, é de todos os turnos depois dele. Numa sessão que ainda vai render 200 turnos, compactar cedo devolve algo entre US$ 46 e US$ 92 em preço de tabela. Adiar até a compactação automática disparar significa pagar o preço cheio em cada turno até lá.

Foi a medição que mais mudou meu comportamento: passei a rodar /compact no intervalo entre tarefas em vez de esperar.

O número bruto é 5,9x, e ele engana. Parte da diferença é que rodei subagentes em modelos mais baratos: metade deles em Opus 5, 13% em Sonnet 5, contra uma thread principal quase toda em Fable 5 e Opus 5. Comparar sem controlar isso mistura preço de modelo com tamanho de contexto.

Controlando por modelo, comparando turno de subagente com turno principal no mesmo modelo:

A vantagem persiste com o modelo fixo, e a causa aparece no contexto:

Sete vezes menos contexto por turno. O subagente trabalha numa janela própria e pequena, então cada turno dele relê pouco. A conversa principal relê tudo.

Uma projeção, declarada como projeção: se aqueles 12.441 turnos de subagente tivessem rodado na thread principal, ao custo médio dela, teriam custado US$ 7.268 em vez de US$ 1.240. E isso subestima a diferença, porque ignora o efeito de segunda ordem: cada leitura de arquivo que ficou no subagente é uma leitura que não engordou o contexto principal para todos os turnos seguintes.

Na amostra, só 15 das 67 sessões usaram subagente, com mediana de 6 por sessão e uma sessão chegando a 103. O critério de quando delegar está em subagentes: quando delegar.

Custo por turno, ordenado:

1% dos turnos responde por 22% do custo total. No nível de sessão a concentração é ainda maior: as 10% mais caras concentram 53% do gasto, com mediana de US$ 87 contra média de US$ 311 e um máximo de US$ 3.034.

Isso é boa notícia. Otimizar o turno mediano não vale o esforço, porque ele custa trinta centavos. O que vale é encontrar o punhado de turnos e sessões que dominam a conta, e eles têm assinatura reconhecível: leitura de arquivo grande demais, sessão que passou de mil turnos sem /clear, e busca ampla que despejou muito resultado no contexto de uma vez.

O catálogo desses padrões está em as armadilhas do Claude Code.

Vale dimensionar o que o mecanismo de cache já economiza antes de qualquer otimização sua.

Sem cache, cada turno reprocessaria o histórico inteiro a preço cheio de entrada. Um detalhe curioso da amostra: a escrita ficou dividida quase ao meio entre os dois TTLs, 49,0% em cache de uma hora e 51,0% em cinco minutos.

Tokens de raciocínio somaram 18,0% da saída, US$ 385 no total. É um custo real e pequeno perto dos 90% que o contexto consome.

O projeto que produziu este blog aparece na amostra e é o exemplo mais honesto que eu tenho, porque você está lendo a saída dele.

Uma sessão, 864 turnos, tudo em Opus 5:

Dezoito posts publicados, com pesquisa, verificação de fonte, geração de schema e auditoria de cluster. Dá US$ 21,12 por post a preço de tabela.

O detalhe que fecha o argumento: a saída inteira, 1,4 milhão de tokens de texto, código e tabela, custou US$ 35,14. Os outros US$ 345 foram o agente reconstruindo, turno após turno, aquilo que ele já tinha visto. A proporção do projeto (48,6 / 42,1 / 9,2) reproduz quase exatamente a da amostra completa (52,0 / 37,9 / 10,0), o que é um bom sinal de que o padrão não é acidente de um projeto só.

Isto não depende de acreditar em mim. Os dados estão na sua máquina.

# -*- coding: utf-8 -*-
import json, os, glob, collections

BASE = os.path.expanduser("~/.claude/projects")
PRECO = {  # USD por milhao de tokens, preco de tabela da Claude API
  "claude-opus-5":  dict(inp=5.0,  w5m=6.25,  w1h=10.0, r=0.50, out=25.0),
  "claude-fable-5": dict(inp=10.0, w5m=12.50, w1h=20.0, r=1.00, out=50.0),
}
total = collections.Counter()

for arq in glob.glob(os.path.join(BASE, "*", "*.jsonl")):
    with open(arq, encoding="utf-8", errors="replace") as fh:
        for l in fh:
            if '"usage"' not in l: continue
            try: d = json.loads(l)
            except Exception: continue
            if d.get("type") != "assistant": continue
            m = d.get("message") or {}
            u = m.get("usage") or {}
            p = PRECO.get(m.get("model"))
            if not u or not p: continue
            cc = u.get("cache_creation") or {}
            total["leitura"] += u.get("cache_read_input_tokens", 0) * p["r"] / 1e6
            total["escrita"] += (cc.get("ephemeral_5m_input_tokens", 0) * p["w5m"]
                               + cc.get("ephemeral_1h_input_tokens", 0) * p["w1h"]) / 1e6
            total["saida"]   += u.get("output_tokens", 0) * p["out"] / 1e6

soma = sum(total.values())
for k, v in total.most_common():
    print(f"{k:<10} US$ {v:8.2f}   {100*v/soma:5.1f}%")

Rode e compare suas proporções com as minhas. Se a sua saída passar muito de 10%, você usa o Claude Code de um jeito diferente do meu, e o que vale otimizar no seu caso é outro.

Quatro mudanças, todas derivadas direto dos números acima.

Compacto no intervalo, não quando o sistema manda. Cada compactação adiada custa entre US$ 0,23 e US$ 0,46 por turno até ela acontecer.

Delego leitura grande. Turno de subagente custa um quinto do turno principal, e o arquivo lido não fica pesando no contexto para sempre.

Uso /clear ao trocar de assunto. Conversa antiga não é passiva. Ela é reenviada e recobrada em toda mensagem seguinte.

Escolho o modelo no começo da sessão. Trocar de modelo no meio invalida o cache inteiro, e o cache é 90% da conta. O detalhamento dessa e das outras sete ações que quebram o cache está em Claude Code em produção.

Três lacunas que eu preferia ter fechado, declaradas em vez de preenchidas com estimativa.

Agent teams não aparecem na amostra. Eu queria comparar o custo de um time de agentes com o de uma sessão comum, porque é a configuração com fama de cara. Nenhuma das 67 sessões usou o recurso, então não tenho medição própria e não vou converter a documentação em número que soe medido.

Não há comparação controlada entre modelos. Para dizer qual modelo entrega mais por dólar, seria preciso rodar a mesma tarefa em cada um e avaliar o resultado. Eu rodei trabalhos diferentes em modelos diferentes, conforme a tarefa pedia, e isso confunde preço com carga.

Custo por tarefa concluída continua em aberto. Tudo aqui é custo por turno e por sessão, que é o que o registro permite contar. Uma sessão pode conter cinco tarefas ou meia, e o registro não marca onde uma termina e a outra começa. É a métrica que mais interessa a quem decide orçamento, e é justamente a que os dados brutos não entregam sozinhos.

A primeira lacuna se fecha com uso. As outras duas exigem desenho de experimento, não mais coleta.

Esses valores são o que você pagou?

Não. Eu uso assinatura, e converti os tokens medidos pelo preço de tabela da Claude API para ter uma unidade comparável entre padrões de uso. O que transfere para o seu caso são as proporções e as razões entre padrões, não os totais em dólar.

Por que a saída é só 10% do custo?

Porque o modelo não guarda nada entre requisições. A cada turno, a conversa inteira é reenviada e reprocessada, enquanto a resposta nova é só o pedaço do fim. Numa sessão de 400 turnos, o histórico já é ordens de grandeza maior que qualquer resposta individual.

Vale a pena trocar para um modelo mais barato?

Na minha amostra, turnos em Fable 5 custaram em média US$ 0,707 contra US$ 0,284 em Opus 5, o que reflete tanto o preço de tabela, que é o dobro, quanto o tipo de trabalho que rodei em cada um. Como não rodei a mesma tarefa nos dois, esse número não serve para dizer qual entrega mais por dólar. Serve para dizer que a escolha de modelo mexe na conta em proporção maior que a diferença de tabela sugere.

Como sei se minha sessão está cara agora?

/context mostra a distribuição atual por categoria e /cost mostra o gasto da sessão. Se a leitura de cache por turno passar de algumas centenas de milhares de tokens, você está na parte cara da curva e uma compactação se paga em poucos turnos.

• Anthropic — Claude API: Pricing. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: How Claude Code uses prompt caching. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: Explore the context window. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: Create custom subagents. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: How Claude Code works. Acesso em 20/08/2026.

Dados primários: 48.120 turnos de assistente precificados, extraídos de ~/.claude/projects/, 67 sessões em 26 projetos, entre 29/06/2026 e 20/08/2026. Script de extração acima, reproduzível na sua própria máquina.

Verificado em 20 de agosto de 2026.

Gatilho de reavaliação: refazer a medição quando (a) os preços de tabela da Claude API mudarem, (b) o comportamento de compactação automática mudar de limiar, ou (c) a amostra dobrar de tamanho, o que permitiria separar padrão de uso por tipo de tarefa.