| |
Algumas semanas atrás, publiquei um artigo explicando por que 99% do que você envia para o Claude já está em cache. Tensores KV, VRAM, SSDs locais — toda a maquinaria interna. Mas deixei de fora a parte que mais dói: a conta.
Porque o prompt caching é uma daquelas coisas que parecem um baita negócio até você olhar de perto os números. E então percebe que está pagando para economizar.
O paradoxo do custo
Vamos aos números. Com Claude Sonnet:
| Conceito | Preço por milhão de tokens |
|---|---|
| Input normal | $3,00 |
| Cache write | $3,75 (1,25x) |
| Cache read | $0,30 (0,10x) |
Olho no dado: escrever no cache custa 25% mais que processar o input sem cache. Você está pagando um extra pelo privilégio de que na próxima vez será mais barato.
É como pagar uma anuidade no Sam’s Club. A taxa inicial dói. Mas se você comprar o suficiente, vale a pena.
O problema é que “o suficiente” depende de quantas vezes você vai acessar aquele cache antes que ele expire.
Quando você perde dinheiro
Imagine que você envia um prompt de 100K tokens com cache_control. Primeira requisição:
100.000 tokens × $3,75/M = $0,375 (cache write)
Se você tivesse enviado isso sem cache:
100.000 tokens × $3,00/M = $0,300 (input normal)
Você pagou $0,075 a mais. Um acréscimo de 25%. Você perdeu dinheiro.
Agora, uma segunda requisição com os mesmos 100K tokens de prefixo:
100.000 tokens × $0,30/M = $0,030 (cache read)
Comparado com:
100.000 tokens × $3,00/M = $0,300 (input normal sem cache)
Você economizou $0,27. Em duas requisições, já recuperou os $0,075 extras da escrita e está no positivo.
O ponto de equilíbrio está em 1,4 leituras. Dito de forma simples: se você vai usar aquele prefixo pelo menos duas vezes nos próximos 5 minutos, o cache vale a pena.
Por que com Claude Code é óbvio
Numa sessão no Claude Code, cada mensagem que você envia inclui o system prompt, as ferramentas e todo o histórico da conversa. Mensagem após mensagem. Sem cache, você estaria pagando $3,00/M pelos mesmos 150K tokens de contexto a cada vez que escreve “mude a cor desse botão”.
Ninguém consegue pagar isso.
Com prompt caching, você paga o write uma vez e, em seguida, lê os tokens a $0,30/M durante toda a conversa. Numa sessão de 50 mensagens com 150K de contexto acumulado, a diferença é brutal:
Sem cache: 50 × 150.000 × $3,00/M = $22,50
Com cache: 1 × 150.000 × $3,75/M + 49 × 150.000 × $0,30/M = $2,77
De $22,50 para $2,77. Uma economia de 88%. Por isso a Anthropic ativa o cache por padrão no Claude Code. Seria economicamente inviável não fazer isso.
O contraditório: o cache read é o que faz disparar seu contador de tokens
E aqui vem a parte que confunde todo mundo.
Quando você abre seu painel de uso e vê cacheReadInputTokens: 4.241.579.174, seu cérebro diz: “consumi quatro bilhões de tokens”. E tecnicamente é verdade: sua conta processou esses tokens. Mas não processou da forma que você pensa.
Um cache read não recalcula os tensores KV. Ele lê da memória. É enormemente mais barato para a Anthropic do que um input normal, e por isso eles cobram com um desconto de 90%.
Mas o número é gigante comparado com todo o resto. Meus dados reais de um mês:
cacheReadInputTokens: 4.241.579.174 (99,5%)
cacheCreationInputTokens: 196.596.243 (4,6%)
inputTokens: 1.293.019 (0,03%)
outputTokens: 2.517.666 (0,06%)
99,5% dos tokens que passam pela minha conta são cache reads. Se a Anthropic decidisse cobrar os cache reads pelo preço normal do input, minha conta aumentaria 10 vezes. Literalmente.
Isso tem uma consequência prática: quando você compara seu consumo com o de outras pessoas, cacheReadInputTokens é a métrica mais inútil que existe. Alguém que tem 200 sessões curtas e alguém com 10 sessões longas podem ter cache reads radicalmente diferentes com o mesmo gasto real.
As três alavancas que você controla
Se você usa a API diretamente (não o Claude Code, onde a Anthropic gerencia o cache para você), existem três coisas que você pode fazer para otimizar:
1. Organize seu prompt do mais estável ao menos estável
O cache funciona por prefixo. Se você muda algo no início, invalida tudo o que vem depois. Essa é a regra de ouro:
[System prompt — nunca muda]
[Definições de ferramentas — raramente mudam]
[Documentos de referência — mudam de vez em quando]
[Histórico de conversa — cresce com cada mensagem]
[Última mensagem do usuário — sempre nova]
Se você coloca a mensagem do usuário antes dos documentos de referência, invalida o cache dos documentos toda vez. Uma gambiarra cara em cada requisição.
2. Use breakpoints de cache com sabedoria
A Anthropic te dá até 4 breakpoints (cache_control) por requisição. A tentação é colocar um em cada bloco. Mas cada breakpoint força um cache write mesmo se o conteúdo for idêntico ao que já estava em cache.
Minha recomendação: um breakpoint no final do system prompt e outro no final do histórico da conversa. Dois pontos de ancoragem, não quatro.
3. Respeite o mínimo cacheável
O cache só funciona se o bloco tiver pelo menos 1.024 tokens (2.048 para o Opus). Se seu system prompt tem 500 tokens, ele não será cacheado. Você pode conferir isso olhando a resposta da API: se cache_read_input_tokens for 0, o bloco não atingiu o mínimo.
O que você não pode controlar (e não deveria se preocupar)
O TTL do cache é de 5 minutos na VRAM (nível padrão). Se seu usuário demora 6 minutos para responder, ocorre um cache miss e tudo é recalculado. Não há nada que você possa fazer sem pagar pelo extended cache (1 hora de TTL, mas custa 2x o preço do input).
Para conversas interativas — alguém conversando com seu bot — 5 minutos normalmente é suficiente. Para processos em lote com pausas longas entre requisições, considere o extended cache se os prompts forem longos. Faça as contas: o 2x do write se paga com os reads?
O efeito psicológico
Há um efeito colateral que ninguém menciona: o cache te incentiva a fazer mais requisições, não menos. Porque você sabe que cada requisição adicional custa uma fração da primeira.
É o mesmo mecanismo dos planos de internet móvel. Quando você passou de pagar por MB para um plano ilimitado, começou a usar mais dados. Não porque precisasse de mais, mas porque o custo marginal era zero.
Com prompt caching, o custo marginal de uma requisição adicional (se o contexto já está em cache) é quase só o custo do output. E isso muda seu comportamento. Você começa a iterar mais rápido. A fazer perguntas menores. A usar o modelo como um rubber duck turbo.
Isso é ruim? Depende. Se você tem um limite de gastos ou usa um plano como o Claude Max, pode ser uma armadilha: o custo por requisição cai, mas o número de requisições aumenta. E o limite é medido pelo consumo total, não pelo custo marginal.
Em resumo
O prompt caching é uma daquelas otimizações que funcionam exatamente ao contrário do que sua intuição imagina:
- Você paga mais no começo (o cache write custa 1,25x).
- Você paga muito menos depois (o cache read custa 0,10x).
- O ponto de equilíbrio é ridiculamente baixo (1,4 leituras).
- Os números de consumo são enganosamente grandes (99% dos seus tokens são cache reads baratos).
- A ordem do seu prompt importa mais do que você pensa (prefixo estável = mais cache).
Se você usa a API da Anthropic e não está usando o prompt caching, está jogando dinheiro fora. Se já usa e não entende sua conta, agora sabe o porquê: o cache te cobra o dobro para te economizar 90%. E assim que você faz as contas, é o melhor negócio possível.
Relacionado: Se você quer entender a maquinaria interna (tensores KV, VRAM, hashing por prefixo), leia Por que 99% do que você envia para o Claude já está em cache. E se você se interessa em como estimo meus gastos sem acesso à API, confira Tokamak: estimando gastos do Claude sem API.