Como Economizar na API Claude (Opus 4.8 e Fable 5)

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: o prompt do sistema, as definições de ferramentas, os documentos que você colou e todas as mensagens anteriores. Em um loop de agente longo ou em uma sessão de Claude Code, esse contexto reenviado se acumula rapidamente, e você paga por ele em cada solicitação. A saída é a parte menor da fatura.

Assim, as alavancas que realmente movem sua fatura são aquelas que diminuem o que você envia, cortam a taxa por token ou impedem que você reenvie contexto morto. Este guia detalha as alavancas concretas, começando pelas de primeira parte, depois um proxy de terceiros (pxpipe) que aborda de um ângulo diferente, e finalmente onde uma API mock se encaixa enquanto você ainda está construindo.

Se você deseja os fundamentos de precificação primeiro (como o medidor funciona, o que é um token, como o caching e o batching são cobrados), nosso explicador de custos da API Claude aborda esse terreno. Esta publicação mantém o foco em reduzir a fatura, então não repetiremos a teoria de precificação em detalhes.

botão

Alavanca 1: Cache de prompts

O cache de prompts é a mudança de maior retorno para a maioria das cargas de trabalho de agentes. Você marca um prefixo estável (prompt do sistema, definições de ferramentas, documentos de referência longos) como armazenável em cache, e o Claude o armazena. Na próxima solicitação que começar com os mesmos bytes, você lê do cache em vez de pagar o preço total de entrada para reprocessá-lo.

A economia é forte. As leituras do cache custam cerca de 0.1x a taxa de entrada base, então você economiza até ~90% na parte em cache. As escritas no cache custam mais do que um token de entrada normal: 1.25x para o TTL de 5 minutos, ou 2x para o TTL de 1 hora. Esse prêmio de escrita é o motivo pelo qual o cache só compensa quando você reutiliza o prefixo. O ponto de equilíbrio é de aproximadamente 2 solicitações para o cache de 5 minutos e cerca de 3 para o cache de 1 hora. Se um prefixo for acessado uma vez e descartado, o cache lhe custa dinheiro; se for acessado dezenas de vezes, é quase gratuito após a primeira escrita.

O problema é que o cache é uma correspondência de prefixo no nível do byte. Qualquer alteração dentro da região em cache o invalida e força uma nova escrita, com preço total. O culpado usual é uma variável que se infiltra na parte “estável”: um carimbo de data/hora no prompt do sistema, um ID de sessão, um contador de solicitações, uma lista de ferramentas reordenada. Parece estável para você e é lido como novos bytes pelo cache.

Verifique se o cache está realmente funcionando. Leia usage.cache_read_input_tokens em suas respostas. Em solicitações repetidas que compartilham um prefixo, esse número deve ser grande e diferente de zero. Se estiver travado em zero, algo em seu prefixo está mudando a cada chamada, e você está pagando o preço total enquanto acredita que está em cache. Para a mecânica de como e por que o cache funciona, consulte 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. Claude oferece uma clara escada de preços, e o roteamento por tarefa em vez de usar um modelo padrão é frequentemente a maior redução de custo que você obterá.

Aqui está a precificação atual por 1M de tokens:

Alguns pontos a serem observados na tabela. Fable 5 custa 2x o Opus 4.8 tanto na entrada quanto na saída, o que o torna o modelo mais caro amplamente lançado. Opus 4.8 possui uma janela de contexto completa de 1M de tokens sem prêmio para contexto longo, então você não paga extra por alimentá-lo com uma grande base de código. Sonnet 5 está disponível por um preço introdutório de $2/$10 até 31/08/2026, depois passa para $3/$15. Haiku 4.5 é o modelo de base a $1/$5, com uma janela menor de 200K.

Correlacione o modelo com a tarefa:

• Fable 5 para o raciocínio de longo prazo mais difícil, onde a capacidade extra realmente muda o resultado. Usar Fable por padrão quando Opus teria feito o trabalho é a maneira mais comum de as equipes dobrarem sua fatura sem motivo.
• Opus 4.8 para a maioria dos trabalhos de agente e codificação. É o padrão sensato para Claude Code e loops com muitas ferramentas.
• Sonnet 5 para tráfego de produção de alto volume onde você precisa de boa qualidade a uma taxa menor.
• Haiku 4.5 para tarefas simples ou críticas de velocidade: classificação, extração, roteamento, respostas curtas.

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, e a vez redirecionada é cobrada nas taxas do Opus. Isso geralmente é um desconto, não uma cobrança surpresa, mas vale a pena saber que seu tráfego Fable pode mostrar linhas com preço de Opus.

Para detalhamentos de custos mais aprofundados sobre os dois níveis mais caros, consulte precificação do Opus 4.8, precificação do Fable 5, e a comparação Fable 5 vs Opus 4.8 para saber quando o 2x vale a pena. Se você quiser experimentar os níveis mais altos com baixo ou nenhum custo enquanto avalia, cobrimos como usar o Opus 4.8 gratuitamente e como chamar a API Fable 5 diretamente.

Alavanca 3: API em lote (50% de desconto)

Se o seu trabalho não precisa de uma resposta em tempo real, a API em Lote (Batch API) reduz o custo de cada token pela metade. Você envia tarefas para /v1/messages/batches, elas são executadas assincronamente e você recebe os resultados de volta. A maioria dos lotes termina em uma hora; o limite máximo é de 24 horas. O desconto de 50% se aplica a todo o uso de tokens no lote, entrada e saída.

O ajuste é restrito, mas valioso. O lote é para trabalhos que você pode esperar:

• Executar avaliações em um conjunto de testes.
• Classificação ou extração em massa sobre um backlog.
• Preencher resumos, tags ou metadados adjacentes a embeddings para registros existentes.
• Qualquer grande trabalho offline onde alguns minutos de latência não lhe custam nada.

Se metade do seu gasto com Claude é processamento noturno que você está executando atualmente através do endpoint síncrono, movê-lo para lote é um corte direto de 50% nessa metade, sem alteração na qualidade. É a vitória mais barata nesta lista para considerar, porque o único trade-off é a latência que você não estava usando de qualquer forma.

Alavanca 4: Ajuste de esforço, max_tokens e count_tokens

Três configurações controlam o quanto uma única solicitação pode gastar, e configurá-las deliberadamente evita que os custos aumentem.

Esforço. O parâmetro output_config.effort aceita low (baixo), medium (médio), high (alto), xhigh (muito alto) ou max (máximo). Ele governa o quanto o modelo "pensa" antes de responder, e os tokens de pensamento são faturados. Menos esforço significa menos tokens de pensamento e de saída. Muitas tarefas executadas em high por hábito produzem a mesma resposta em medium ou low por menos dinheiro. Teste um ou dois níveis abaixo e verifique se a qualidade se mantém.

max_tokens. Este é um limite rígido para a saída. Não diminuirá o custo de uma resposta que seria curta, mas limita o caso de descontrole: um modelo que decide emitir um ensaio de 4.000 tokens quando você queria um objeto JSON. Defina-o para um limite razoável para a tarefa, para que uma única resposta prolixa não infle um item da fatura.

count_tokens. Estime o custo antes de enviar. O endpoint count_tokens informa exatamente quantos tokens de entrada uma solicitação cobrará, usando o próprio tokenizador do Claude. Não use tiktoken para isso. Tiktoken é o tokenizador da OpenAI e subestima o Claude em aproximadamente 15 a 20%, então orçar com ele significa que sua fatura real será significativamente mais alta do que sua estimativa. Se você estiver operando perto de um orçamento por solicitação, count_tokens é como você detecta um prompt superdimensionado antes que ele lhe custe.

Alavanca 5: Reduza o contexto que você reenvia

Como a API é sem estado (stateless), um loop de agente longo reenvia todo o seu histórico a cada turno, e a maior parte desse histórico é peso morto no 30º turno: saídas de ferramentas nas quais você já agiu, exploração que você já superou, arquivos que você leu uma vez. Você continua pagando o preço total de entrada para reenviar tudo isso.

Duas funcionalidades no lado do servidor o podam para você:

• Edição de contexto (clear_tool_uses_20250919) remove resultados de ferramentas obsoletos do contexto que é reenviado, para que chamadas de ferramentas antigas parem de ser cobradas em cada turno subsequente.
• Compactação (compact_20260112) resume o histórico mais antigo em uma forma mais curta, para que uma conversa longa não carregue mais sua transcrição bruta completa.

Ambos são executados no lado do servidor, o que significa que você não precisa criar um sumarizador manualmente ou fatiar arrays de mensagens. Para sessões de Claude Code de longa duração especificamente, esta é a mesma pressão por trás de atingir os limites de contexto no meio da tarefa; nosso guia sobre a janela de tokens do Claude Code e redefinições aborda como isso se manifesta no editor. A conclusão sobre o faturamento é simples: pare de pagar para reenviar contexto que o modelo não precisa mais.

Indo além: renderizar contexto como imagens com pxpipe

As alavancas de primeira parte todas diminuem ou reclassificam os tokens que você envia. pxpipe ataca o mesmo custo de token de entrada de uma direção diferente: ele renderiza o 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) que fica entre seu cliente e a API da Anthropic. Você aponta ANTHROPIC_BASE_URL para ele, e ele inspeciona cada solicitação ao sair.

Como ele reduz o custo. Texto denso é caro por token. pxpipe reescreve as partes volumosas e estáveis de uma solicitação (prompt do sistema, documentação de ferramentas, histórico mais antigo) em imagens PNG compactas antes que a solicitação saia de sua máquina. Conteúdo denso corresponde a cerca de 3.1 caracteres por token de imagem versus aproximadamente 1 caractere por token de texto, então a imagem desse conteúdo pode reduzir seus tokens de entrada por uma grande margem. O projeto relata um exemplo de prompt de sistema mais documentação de ferramentas de ~48 mil caracteres que resulta em cerca de 2.7 mil tokens de imagem versus cerca de 25 mil como texto. Crucialmente, ele usa portões de lucratividade: ele só transforma em imagem o conteúdo onde a matemática dos tokens realmente compensa, e a prosa esparsa passa como texto inalterado.

Instalar e executar. Dois comandos:

npx pxpipe-proxy

Isso inicia o proxy em 127.0.0.1:47821. Em seguida, aponte o Claude Code para ele:

ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude

Suporte a modelos. Por padrão, pxpipe transforma em imagem as solicitações para claude-fable-5 e GPT 5.6. Opus 4.7/4.8 e GPT 5.5 são opcionais, porque o projeto relata que eles leem o contexto imagístico visivelmente pior. Você os habilita com a variável de ambiente PXPIPE_MODELS (ou o painel na URL do proxy). Todo o resto passa inalterado.

Economias relatadas. Estes são os números relatados e de benchmark do próprio projeto, não dados que verificamos independentemente. pxpipe relata um instantâneo de produção de 59% de economia, uma fatura de $100 caindo para cerca de $41 em 13.709 solicitações, e um piloto SWE-bench Lite com redução de -65% no tamanho da solicitação. Trate-os como benchmarks de fornecedores e confirme em seu próprio tráfego.

As desvantagens honestas. A transformação em imagem não é dinheiro fácil.

• Interage com o cache de prompts. A transformação em imagem altera os bytes da solicitação, e seu prefixo em cache é uma correspondência exata de bytes. O cache e a imagem visam ambos o mesmo custo de token de entrada, então eles podem se contrapor: a mudança que faz a imagem vencer pode ser a mudança que altera sua região em cache. Qual abordagem economiza mais depende do seu prefixo específico e padrão de reutilização. Meça ambos em sua própria carga de trabalho em vez de assumir que eles se somam.
• O modelo lê o contexto imagístico através da visão. O próprio projeto sinaliza que strings densas (IDs hexadecimais longos, tokens exatos) podem ser mal interpretadas, e falhas são silenciosas, não erros. Verifique a qualidade da saída em suas próprias tarefas antes de confiar nas economias.
• É um proxy de terceiros que lida com seu tráfego. Ele é executado localmente, o que é bom, mas ainda está no caminho da sua solicitação. Avalie-o em relação à sua própria postura de segurança antes de rotear tráfego de produção através dele.

pxpipe vale a pena testar se o seu contexto é dominado por blocos grandes, estáveis e densos, e você pode validar a qualidade. Para cargas de trabalho esparsas ou altamente amigáveis ao cache, as alavancas de primeira parte já podem capturar a maior parte do ganho.

Reduza os tokens de desenvolvimento e teste que você desperdiça durante a construção

Nada do que foi dito acima muda o fato de que você queima tokens reais e pagos enquanto ainda está construindo a integração. Apidog não reduzirá sua fatura de produção do Claude, e nem pretende. Onde ele economiza dinheiro é no ciclo de desenvolvimento e teste.

Toda vez que você executa sua integração contra a API Anthropic ao vivo durante o desenvolvimento, cada iteração custa tokens reais: a execução falha, a tentativa, o trabalho de CI que é acionado a cada push. Esse gasto se acumula enquanto você itera no formato do prompt, lógica de parsing e tratamento de erros, nenhum dos quais precisa de um modelo real para validação.

Simule a resposta da Anthropic no Apidog em vez disso. Defina o contrato de solicitação e resposta para o endpoint do Claude que você está chamando, então aponte seus testes e CI para o mock. Seu loop é executado contra um falso determinístico que retorna o formato que você espera, e você gasta zero tokens validando a implementação. Você também pode projetar e documentar esse contrato de solicitação/resposta no mesmo local, para que sua equipe concorde com a interface antes que alguém gaste um token nela. Isso reduz os tokens de desenvolvimento e teste que você desperdiça durante a construção, não sua fatura de produção. Esse é o escopo honesto.

Combine as alavancas

Estas não são exclusivas. Os maiores cortes vêm da combinação:

1. Armazene o prefixo estável em cache. Prompt do sistema, ferramentas, documentos. Verifique se cache_read_input_tokens é diferente de zero.
2. Roteie por tarefa. Opus 4.8 como padrão, Fable 5 apenas onde muda o resultado, Sonnet 5 para volume, Haiku 4.5 para trabalho simples.
3. Processe o trabalho offline em lote. Qualquer coisa não sensível à latência vai para /v1/messages/batches com 50% de desconto.
4. Limite cada solicitação. Ajuste o effort, defina um teto para max_tokens, estime com count_tokens.
5. Reduza o reenvio. Edição e compactação de contexto para que loops longos parem de pagar por histórico morto.
6. Teste se a transformação em imagem ajuda. Se o seu contexto for grande e denso, compare o desempenho do pxpipe com o cache no seu próprio prefixo.
7. Simule durante a construção. Mantenha o ciclo de desenvolvimento e teste fora do medidor pago.

Comece com o cache e o roteamento de modelos, pois esses dois geralmente respondem pela maior parte da redução. Meça após cada alteração, porque o único número que importa é a sua fatura real.

FAQ

Tokens de entrada ou saída custam mais na minha fatura do Claude? Por token, a saída custa mais do que a entrada em todos os modelos. Mas para cargas de trabalho de agente e codificação, o lado da entrada geralmente representa a maior parte da fatura, porque a API sem estado (stateless) faz com que você reenvie o histórico completo da conversa a cada turno. É por isso que as maiores alavancas visam os tokens de entrada.

O cache de prompts ou a API em lote (Batch API) oferece a maior economia? Depende da sua carga de trabalho. O cache economiza até ~90% no prefixo repetido de tráfego interativo, então ele é vantajoso para chats e loops de agente que reutilizam um prompt do sistema. A API em lote corta 50% de tudo, mas apenas para trabalhos que você pode executar assincronamente. Muitas equipes usam ambos: armazenam em cache o caminho interativo, processam em lote os trabalhos offline.

Devo usar Fable 5 como padrão para tudo? Não. Fable 5 custa o dobro do Opus 4.8 e é destinado ao raciocínio de longo prazo mais difícil. Para a maioria dos trabalhos de agente e codificação, Opus 4.8 oferece o mesmo resultado pela metade da taxa de entrada e saída. Usar Fable por padrão quando Opus seria suficiente é o gasto excessivo mais comum.

O pxpipe se acumula com o cache de prompts? Não de forma limpa. A transformação em imagem altera os bytes da solicitação, e o cache é uma correspondência de prefixo no nível do byte, então os dois visam o mesmo custo de token de entrada e podem se contrapor. Teste ambos no seu prefixo real e meça qual economiza mais; não presuma que eles se somam.

O Apidog reduz meus custos de produção do Claude? Não. O Apidog simula a API da Anthropic para que seus testes e CI atinjam um falso em vez de queimar tokens pagos enquanto você constrói. Isso reduz seus gastos de desenvolvimento e teste, não sua fatura de produção.