Sua fatura do Claude é composta principalmente por tokens de entrada, não de saída. A API é sem estado (stateless), então, a cada turno, você reenvia o histórico completo da conversa: prompt do sistema, definições de ferramentas, documentos colados e mensagens anteriores. Em loops de agente longos ou sessões de Claude Code, esse contexto reenviado cresce rápido — e você paga por ele em cada solicitação.
As alavancas que realmente reduzem custo são as que diminuem o que você envia, reduzem a taxa por token ou evitam reenviar contexto morto. Este guia mostra como aplicar cada uma: primeiro recursos nativos, depois o proxy pxpipe, e por fim onde uma API mock ajuda durante desenvolvimento e testes.
Se você quer revisar os fundamentos de precificação primeiro — como o medidor funciona, o que é um token, como caching e batching são cobrados — veja nosso explicador de custos da API Claude. Aqui o foco é reduzir a fatura na prática.
Alavanca 1: Cache de prompts
O cache de prompts costuma ser a mudança com maior retorno para cargas de trabalho de agentes. A ideia é simples:
- Separe um prefixo estável da solicitação.
- Marque esse prefixo como armazenável em cache.
- Reutilize exatamente os mesmos bytes nas próximas chamadas.
Esse prefixo normalmente inclui:
- prompt do sistema;
- definições de ferramentas;
- documentos de referência longos;
- instruções fixas de formato;
- contexto base compartilhado entre turnos.
Na próxima solicitação que começar com os mesmos bytes, o Claude lê do cache em vez de reprocessar o texto inteiro pelo preço cheio de entrada.
Quando o cache compensa
Leituras do cache custam cerca de 0.1x a taxa de entrada base, ou seja, você pode economizar até ~90% na parte cacheada.
Mas a escrita no cache custa mais:
- TTL de 5 minutos:
1.25xo token de entrada normal; - TTL de 1 hora:
2xo token de entrada normal.
Por isso, cache só vale a pena quando o prefixo é reutilizado:
- cache de 5 minutos: ponto de equilíbrio em aproximadamente 2 solicitações;
- cache de 1 hora: ponto de equilíbrio em aproximadamente 3 solicitações.
Se você cacheia um prefixo usado uma única vez, ele encarece a chamada. Se reutiliza dezenas de vezes, a parte cacheada fica quase gratuita depois da primeira escrita.
Checklist para não invalidar o cache
O cache usa correspondência de prefixo em nível de byte. Qualquer alteração dentro da região cacheada força uma nova escrita.
Evite colocar no prefixo estável:
- timestamp;
- ID de sessão;
- contador de requisições;
- dados do usuário;
- mensagens recentes;
- ferramentas em ordem variável;
- documentos montados dinamicamente.
Um padrão seguro é estruturar sua solicitação assim:
[REGIÃO CACHEÁVEL]
- prompt do sistema fixo
- ferramentas em ordem fixa
- documentação estável
- políticas fixas de resposta
[REGIÃO DINÂMICA]
- mensagem atual do usuário
- histórico recente
- dados da sessão
Como verificar se está funcionando
Não assuma que o cache está ativo. Leia o campo:
usage.cache_read_input_tokens
Em chamadas repetidas com o mesmo prefixo, esse valor deve ser grande e diferente de zero.
Se ele estiver sempre em zero, algum byte do prefixo está mudando entre chamadas. Nesse caso, você está pagando preço cheio enquanto acredita estar usando cache.
Para a mecânica detalhada, veja o que é cache de prompt e como funciona.
Alavanca 2: Escolha o modelo certo
O gasto excessivo mais comum é usar um modelo maior do que a tarefa exige. Em vez de definir um modelo padrão para tudo, roteie por tipo de tarefa.
Precificação atual por 1M de tokens:
| Modelo | ID do Modelo | Entrada | Saída | Janela de contexto |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 |
$10 | $50 | 1M |
| Opus 4.8 | claude-opus-4-8 |
$5 | $25 | 1M |
| Sonnet 5 | claude-sonnet-5 |
$3 ($2 intro) | $15 ($10 intro) | 1M |
| Haiku 4.5 | claude-haiku-4-5 |
$1 | $5 | 200K |
Pontos importantes:
- Fable 5 custa 2x o Opus 4.8 na entrada e na saída.
- Opus 4.8 tem janela de contexto de 1M sem prêmio adicional para contexto longo.
- Sonnet 5 tem preço introdutório de $2/$10 até 31/08/2026, depois passa para $3/$15.
- Haiku 4.5 é o modelo base a $1/$5, com janela menor de 200K.
Roteamento recomendado
Use uma matriz simples:
| Tipo de tarefa | Modelo recomendado |
|---|---|
| Raciocínio de longo prazo muito difícil | Fable 5 |
| Agentes, codificação e uso intenso de ferramentas | Opus 4.8 |
| Produção de alto volume com boa qualidade | Sonnet 5 |
| Classificação, extração, roteamento e respostas curtas | Haiku 4.5 |
Na prática:
- Fable 5: use apenas quando a capacidade extra muda o resultado.
- Opus 4.8: bom padrão para Claude Code e loops com muitas ferramentas.
- Sonnet 5: útil para tráfego em volume quando custo por chamada importa.
- Haiku 4.5: ideal para etapas simples do pipeline.
Exemplo de estratégia de roteamento:
function chooseClaudeModel(task: {
type: "classification" | "coding" | "bulk_summary" | "hard_reasoning";
volume: "low" | "high";
}) {
if (task.type === "classification") return "claude-haiku-4-5";
if (task.type === "hard_reasoning") return "claude-fable-5";
if (task.volume === "high") return "claude-sonnet-5";
return "claude-opus-4-8";
}
Um detalhe de faturamento sobre Fable 5: se um classificador de segurança recusar uma solicitação, o parâmetro beta fallbacks pode redirecionar essa vez para Opus 4.8. A vez redirecionada é cobrada nas taxas do Opus. Em geral, isso é um desconto, não uma cobrança surpresa.
Para análises mais detalhadas, veja:
- precificação do Opus 4.8;
- precificação do Fable 5;
- Fable 5 vs Opus 4.8;
- como usar o Opus 4.8 gratuitamente;
- como chamar a API Fable 5.
Alavanca 3: API em lote com 50% de desconto
Se a tarefa não precisa de resposta em tempo real, use a API em Lote (Batch API).
Você envia tarefas para:
/v1/messages/batches
Elas são executadas de forma assíncrona e você busca os resultados depois. A maioria dos lotes termina em uma hora; o limite máximo é de 24 horas.
O desconto de 50% se aplica a todos os tokens do lote:
- entrada;
- saída.
Bons casos de uso
Use lote para trabalhos que podem esperar:
- avaliações em conjunto de testes;
- classificação em massa;
- extração em backlog;
- geração de resumos para registros existentes;
- tags e metadados adjacentes a embeddings;
- jobs noturnos;
- reprocessamento offline.
Se metade do seu gasto com Claude vem de processamento noturno via endpoint síncrono, migrar essa metade para lote reduz diretamente 50% desse bloco de custo, sem mudar a qualidade.
A única troca é latência. Se você não precisava da resposta imediata, é uma economia direta.
Alavanca 4: Ajuste effort, max_tokens e count_tokens
Três controles ajudam a limitar quanto uma solicitação pode gastar.
1. Reduza output_config.effort
O parâmetro output_config.effort aceita:
low
medium
high
xhigh
max
Ele controla quanto o modelo “pensa” antes de responder. Tokens de pensamento são faturados.
Muitas tarefas executadas em high por hábito funcionam em medium ou low com qualidade suficiente.
Teste assim:
- Escolha uma amostra real de prompts.
- Rode com o esforço atual.
- Rode um nível abaixo.
- Compare qualidade, custo e latência.
- Reduza o padrão se a qualidade se mantiver.
Exemplo de configuração conceitual:
{
"model": "claude-opus-4-8",
"max_tokens": 800,
"output_config": {
"effort": "medium"
}
}
2. Defina max_tokens
max_tokens é um limite rígido para a saída.
Ele não reduz o custo de uma resposta que já seria curta, mas evita o pior caso: o modelo gerar 4.000 tokens quando você esperava um JSON pequeno.
Exemplos de teto por tarefa:
| Tarefa |
max_tokens sugerido |
|---|---|
| Classificação | 20–100 |
| Extração JSON simples | 200–500 |
| Resumo curto | 300–800 |
| Explicação técnica | 1.000–2.000 |
| Geração longa | limite específico do produto |
Para respostas estruturadas, combine max_tokens com instruções explícitas:
Responda somente com JSON válido.
Não inclua explicações.
Use no máximo 5 campos.
3. Use count_tokens antes de enviar
O endpoint count_tokens informa quantos tokens de entrada a solicitação cobrará usando o tokenizador do próprio Claude.
Não use tiktoken para estimar Claude. tiktoken é o tokenizador da OpenAI e pode subestimar Claude em aproximadamente 15% a 20%.
Use count_tokens quando:
- você tem orçamento por solicitação;
- usuários podem colar documentos grandes;
- o histórico cresce dinamicamente;
- o prompt é montado por várias fontes;
- você precisa bloquear chamadas caras antes de enviá-las.
Fluxo recomendado:
montar solicitação
→ chamar count_tokens
→ comparar com orçamento
→ resumir/cortar se necessário
→ enviar para /messages
Alavanca 5: Reduza o contexto reenviado
Como a API é sem estado, loops longos reenviam o histórico completo a cada turno.
No 30º turno, boa parte disso já é peso morto:
- resultados de ferramentas já processados;
- explorações abandonadas;
- arquivos lidos uma única vez;
- mensagens antigas que não influenciam mais a próxima decisão.
Você continua pagando tokens de entrada para reenviar tudo.
Duas funcionalidades no lado do servidor ajudam a podar esse contexto.
Edição de contexto
A edição de contexto:
clear_tool_uses_20250919
remove resultados de ferramentas obsoletos do contexto reenviado.
Use quando seu agente chama ferramentas com frequência e os resultados antigos não precisam continuar no prompt.
Compactação
A compactação:
compact_20260112
resume histórico antigo em uma forma menor.
Use em conversas longas para evitar reenviar a transcrição bruta inteira.
Essas duas abordagens rodam no lado do servidor. Você não precisa criar seu próprio sumarizador nem manipular arrays de mensagens manualmente.
Para sessões longas de Claude Code, essa é a mesma pressão que aparece ao atingir limites de contexto no meio da tarefa. Veja o guia sobre a janela de tokens do Claude Code e redefinições.
A regra prática é simples: não pague para reenviar contexto que o modelo não precisa mais.
Indo além: renderizar contexto como imagens com pxpipe
As alavancas anteriores reduzem ou reclassificam tokens enviados. O pxpipe tenta atacar o custo de entrada por outro caminho: renderizar contexto volumoso e estável como imagens para que seja tokenizado de forma mais barata.
O que é
pxpipe é um proxy local:
- licenciado MIT;
- escrito em TypeScript;
- executado entre seu cliente e a API da Anthropic;
- ativado apontando
ANTHROPIC_BASE_URLpara ele.
Ele inspeciona a solicitação antes de ela sair da sua máquina.
Como reduz custo
Texto denso é caro por token. O pxpipe reescreve partes grandes e estáveis da solicitação como imagens PNG compactas, por exemplo:
- prompt do sistema;
- documentação de ferramentas;
- histórico antigo.
Segundo o projeto, conteúdo denso pode ficar em torno de 3.1 caracteres por token de imagem, contra cerca de 1 caractere por token de texto.
O projeto relata um exemplo em que um prompt de sistema mais documentação de ferramentas com ~48 mil caracteres vira cerca de 2.7 mil tokens de imagem, versus cerca de 25 mil como texto.
Importante: ele usa portões de lucratividade. Só transforma em imagem o conteúdo em que a matemática de tokens compensa. Prosa esparsa passa como texto.
Instalação
Inicie o proxy:
npx pxpipe-proxy
Ele sobe em:
127.0.0.1:47821
Aponte o Claude Code para o proxy:
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
Suporte a modelos
Por padrão, pxpipe transforma em imagem solicitações para:
-
claude-fable-5; - GPT 5.6.
Opus 4.7/4.8 e GPT 5.5 são opcionais, porque o projeto relata que eles leem contexto imagístico visivelmente pior.
Para habilitar outros modelos, use:
PXPIPE_MODELS=claude-opus-4-8 npx pxpipe-proxy
Ou configure pelo painel na URL do proxy.
Todo o resto passa inalterado.
Economias relatadas
Estes números são relatados pelo próprio projeto, não verificados independentemente aqui:
- 59% de economia em snapshot de produção;
- fatura de $100 caindo para cerca de $41 em 13.709 solicitações;
- piloto SWE-bench Lite com redução de -65% no tamanho da solicitação.
Trate como benchmark de fornecedor. Meça no seu tráfego antes de adotar.
Desvantagens
pxpipe pode ajudar, mas não é dinheiro grátis.
1. Interage com cache de prompts
A transformação em imagem muda os bytes da solicitação. Como o cache de prompts depende de correspondência exata de prefixo, imagem e cache podem se contrapor.
Ambos atacam o mesmo custo: tokens de entrada.
Teste as duas opções no seu prefixo real:
cenário A: cache de prompts sem pxpipe
cenário B: pxpipe sem cache
cenário C: ambos, se aplicável
Compare custo, qualidade e taxa de acerto do cache.
2. O modelo lê imagens via visão
O projeto sinaliza que strings densas podem ser mal interpretadas, como:
- IDs hexadecimais longos;
- tokens exatos;
- hashes;
- chaves;
- valores que exigem leitura literal.
Falhas podem ser silenciosas. A saída parece válida, mas baseada em uma leitura errada da imagem.
Valide qualidade em tarefas reais antes de usar em produção.
3. É um proxy de terceiros no caminho da solicitação
Mesmo rodando localmente, ele manipula seu tráfego.
Antes de usar em produção, avalie:
- dados sensíveis;
- logs;
- política de rede;
- revisão de segurança;
- atualização de dependências;
- comportamento em falhas.
pxpipe vale testar se seu contexto é grande, estável e denso. Para prompts esparsos ou altamente favoráveis a cache, os recursos nativos podem capturar a maior parte da economia.
Reduza tokens desperdiçados em desenvolvimento e teste
Nenhuma das alavancas anteriores muda um ponto: você queima tokens pagos enquanto ainda está construindo a integração.
Apidog não reduz sua fatura de produção do Claude, e nem pretende. Onde ele ajuda é no ciclo de desenvolvimento e teste.
Durante desenvolvimento, cada chamada contra a API Anthropic ao vivo custa tokens reais:
- execução quebrada;
- tentativa de parser;
- ajuste de prompt;
- teste local;
- job de CI em cada push;
- validação de tratamento de erro.
Grande parte disso não precisa de um modelo real. Você só precisa validar se sua aplicação envia e recebe o formato correto.
Use mock da API durante a construção
Em vez de chamar a API real em todos os testes, simule a resposta da Anthropic no Apidog.
Fluxo prático:
- Defina o contrato do endpoint Claude que sua aplicação chama.
- Modele o corpo da requisição esperado.
- Modele a resposta esperada.
- Configure um mock determinístico.
- Aponte testes locais e CI para o mock.
- Use a API real apenas para validações de qualidade do modelo.
Exemplo de resposta mockada:
{
"id": "msg_mock_123",
"type": "message",
"role": "assistant",
"content": [
{
"type": "text",
"text": "{\"status\":\"ok\",\"category\":\"billing\"}"
}
],
"usage": {
"input_tokens": 120,
"output_tokens": 18
}
}
Isso permite testar:
- serialização da requisição;
- parsing da resposta;
- validação de JSON;
- tratamento de erro;
- timeouts;
- retries;
- integração com CI.
Você também documenta o contrato de request/response no mesmo lugar, para que o time alinhe a interface antes de gastar tokens reais.
O escopo é honesto: isso reduz tokens de desenvolvimento e teste, não sua fatura de produção.
Combine as alavancas
Essas técnicas não são exclusivas. A maior redução vem da combinação.
Um plano prático:
Cacheie o prefixo estável
Prompt do sistema, ferramentas e documentos. Depois confirme quecache_read_input_tokensé diferente de zero.Roteie por tarefa
Use Opus 4.8 como padrão, Fable 5 só quando necessário, Sonnet 5 para volume e Haiku 4.5 para tarefas simples.Mova trabalho offline para lote
Tudo que não é sensível à latência deve ir para/v1/messages/batches.Controle cada solicitação
Ajusteeffort, definamax_tokense usecount_tokenspara bloquear prompts caros antes do envio.Reduza reenvio de histórico
Use edição e compactação de contexto para loops longos.Teste pxpipe quando o contexto for denso
Compare contra cache no seu tráfego real. Não presuma que as economias se somam.Use mocks durante desenvolvimento
Tire testes locais e CI do medidor pago sempre que o modelo real não for necessário.
Comece por cache e roteamento de modelos. Esses dois normalmente explicam a maior parte da redução. Depois meça cada mudança separadamente, porque o único número que importa é a sua fatura real.
FAQ
Tokens de entrada ou saída custam mais na fatura do Claude?
Por token, saída custa mais do que entrada em todos os modelos. Mas, em cargas de trabalho de agente e codificação, entrada costuma dominar a fatura porque a API sem estado faz você reenviar o histórico completo a cada turno.
Por isso, as maiores alavancas miram tokens de entrada.
Cache de prompts ou Batch API economiza mais?
Depende da carga de trabalho.
Cache de prompts economiza até ~90% no prefixo repetido de tráfego interativo. É ideal para chats e loops de agente que reutilizam prompt do sistema e ferramentas.
Batch API corta 50% de tudo, mas apenas para trabalhos assíncronos.
Muitas equipes usam ambos:
- cache no caminho interativo;
- lote para processamento offline.
Devo usar Fable 5 como padrão?
Não.
Fable 5 custa o dobro do Opus 4.8 e é voltado ao raciocínio de longo prazo mais difícil. Para a maioria dos trabalhos de agente e codificação, Opus 4.8 é o padrão mais econômico.
Usar Fable por padrão quando Opus seria suficiente é uma das formas mais comuns de dobrar a fatura sem necessidade.
pxpipe se soma ao cache de prompts?
Não de forma limpa.
pxpipe altera os bytes da solicitação ao transformar texto em imagem. O cache de prompts depende de correspondência exata de bytes no prefixo.
Como ambos miram o mesmo custo de entrada, podem se contrapor. Teste no seu prefixo real e compare.
Apidog reduz meus custos de produção do Claude?
Não.
Apidog permite simular a API da Anthropic para que testes locais e CI usem um mock em vez de gastar tokens pagos durante desenvolvimento.
Isso reduz gasto de desenvolvimento e teste, não a fatura de produção.
Top comments (0)