Cache do Claude Fable 5: mesmo contrato, conta 2,9x maior que no Opus 4.6
Conteúdo
O claude-fable-5 já está disponível no gateway da Synthorai. Para quem usa cache com a linha Claude, a boa notícia é que o contrato de cache e TTL continua igual: mesmos marcadores cache_control, mesmos TTLs de 5 minutos e 1 hora, mesmos adicionais de escrita e o mesmo desconto alto nas leituras. Para migrar o código de cache, basta trocar uma string.
O ponto que exige planejamento não é o funcionamento do cache, mas a conta. O preço por token do Fable 5 é 2x o do Opus, e o mesmo texto em inglês gera ~45% mais tokens que no Opus 4.6 (ele usa o tokenizer posterior ao 4.6, idêntico ao do Opus 4.8). Os dois multiplicadores se acumulam. Este post traz todas as medições.
Antes de migrar, verifique também uma restrição que não envolve cache: o Fable 5 não pode operar com retenção zero de dados. A retenção de dados por 30 dias é obrigatória em todas as clouds em que ele está disponível.
TL;DR
- O Claude Fable 5 mantém inalterado o contrato de cache da Anthropic: mesmos marcadores
cache_control, TTLs de 5 minutos e 1 hora, adicionais de escrita de aproximadamente 1,25x/2x e leitura com cache aquecido medida em cerca de 6% do preço sem cache. - Um texto idêntico gera 9,619 tokens no Fable 5 e no Opus 4.8, contra 6,614 no Opus 4.6: 45% a mais.
- O preço do Fable 5 é $10/M para input e $50/M para output, 2x a faixa do Opus.
- Portanto, o mesmo prompt custa 2,9x o valor do Opus 4.6 (1,45 em tokens x 2,0 no preço), conforme medição de 2026-06-10.
Todos os números abaixo foram medidos em
https://synthorai.io/(endpoint Anthropic-native/v1/messages) em 2026-06-10, com um system prompt estável em inglês de ~6,6–9,6K tokens,max_tokensbaixo e uma única execução sequencial. Os custos vêm do campousage.costdo gateway. As proporções (contagem de tokens, adicional de escrita, desconto de leitura e custo entre modelos) são a parte generalizável; os valores absolutos em dólares variam conforme o prompt. Faça a medição com seu próprio prompt antes de citar esses números.
Disponibilidade
import os
from anthropic import Anthropic
anth = Anthropic(
api_key=os.environ["SYNTHORAI_KEY"],
base_url="https://synthorai.io/", # SDK appends /v1/messages
)
msg = anth.messages.create(
model="claude-fable-5", # the only line that changes
max_tokens=512,
system=[
{"type": "text", "text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}},
],
messages=[{"role": "user", "content": question}],
)
print(msg.usage) # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost
Troque claude-opus-4-6 → claude-fable-5 e nada mais precisa mudar no fluxo de cache. O Fable 5 é um modelo Anthropic-native com context window de 1M tokens. Há uma diferença de comportamento: ele é um modelo de reasoning e gera thinking tokens por padrão. Em nossas execuções, até um simples “reply OK” retornou output_tokens_details.thinking_tokens > 0, enquanto o Opus 4.6/4.8 retornou zero. Inclua esses tokens no orçamento de output. O funcionamento do cache_control está explicado no tutorial de cache; a arquitetura que justifica a existência desse cache está na Parte 1 da série.
Principal conclusão: o Fable 5 usa o novo tokenizer
A contagem de tokens da linha Opus aumentou na geração 4.7: o mesmo texto em inglês que gerava ~6,6K tokens no 4.6 passou a gerar ~9,6K no 4.8. O Fable 5 usa o tokenizer novo: para um texto idêntico, ele informa exatamente a mesma contagem do Opus 4.8.
| Modelo | Tokens de input (texto idêntico) | Geração do tokenizer |
|---|---|---|
claude-opus-4-6 | 6,614 | anterior ao 4.7 |
claude-opus-4-8 | 9,619 | posterior ao 4.7 |
claude-fable-5 | 9,619 | posterior ao 4.7 (idêntico ao 4.8) |
O mesmo system prompt tem ~45% mais tokens no Fable 5 que no Opus 4.6 (9,619 / 6,614 = 1,45). Esse é o número mais importante antes da migração, porque todos os cálculos seguintes — custo, mínimo de 1,024 tokens para uso do cache e orçamento por chamada — dependem da quantidade de tokens.
Trata-se de uma observação medida: com o mesmo texto, Fable 5 e Opus 4.8 retornaram contagens idênticas, ~45% acima do Opus 4.6. O resultado é compatível com a atualização de tokenizer/vocabulário lançada na geração 4.7. Se você usa o 4.6 ou uma versão anterior, refaça a medição. Se usa o 4.7/4.8, espere a mesma contagem.
Comportamento do cache: o contrato não mudou
Executamos em cada modelo a mesma sequência: sem cache, escrita a frio e leitura com cache aquecido. A estrutura de descontos é idêntica em todo o fluxo. O Fable 5 respeita cache_control e informa os mesmos campos de uso (cache_creation_input_tokens, cache_read_input_tokens e os buckets ephemeral_5m / ephemeral_1h).
| Modelo | Escrita em cache de 5m | Escrita em cache de 1h | Leitura com cache aquecido |
|---|---|---|---|
claude-opus-4-6 | 1,25x | 2,00x | ~9% do custo sem cache |
claude-opus-4-8 | 1,25x | 2,00x | ~6% do custo sem cache |
claude-fable-5 | 1,24x | 1,99x | ~6% do custo sem cache |
Duas características se mantêm nos três modelos:
- Adicional de escrita ≈ 1,25x (5m), ≈ 2x (1h). A primeira chamada, com cache frio, custa ~1,25x o preço sem cache para criar uma entrada de 5 minutos, ou ~2x para uma entrada de 1 hora. Uma única leitura já compensa esse adicional.
- Desconto de leitura ≈ 90%+. No Fable 5, uma leitura com cache aquecido custou ~6% da chamada sem cache, um desconto de ~94%. O resultado está alinhado e é ligeiramente melhor que a economia de ~90% documentada pela Anthropic para leituras em cache. As leituras continuam muito mais baratas independentemente do TTL.
Os percentuais são estáveis em toda a linha. Assim como na mudança do Opus 4.7 para o 4.8, a conta absoluta mais alta no Fable 5 vem do preço e da quantidade de tokens, não da economia do cache. A próxima seção detalha esse ponto.
Comportamento do TTL: as duas janelas funcionam
O Fable 5 aceita os mesmos dois TTLs do restante da linha: uma janela deslizante padrão de 5 minutos e uma janela opcional de 1 hora. Isolamos cada TTL usando um prefixo exclusivo por chamada, para impedir que uma entrada antiga afetasse o resultado, e confirmamos que o objeto de uso informa o bucket correto: cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens.
# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}
A escrita de 1 hora custa ~2x o valor sem cache, contra ~1,25x para a escrita de 5 minutos. As leituras mantêm o desconto alto independentemente do TTL, assim como no Opus 4.6/4.8. Se você escolheu 5m para chats ao vivo e 1h para agents com pausas para intervenção humana no Opus, mantenha essas escolhas no Fable 5.
O custo: preço 2x x 1,45x mais tokens
É no custo que o Fable 5 realmente difere. Dois fatores aumentam a conta, e seus efeitos se multiplicam.
1. O preço de tabela é 2x o da faixa Opus.
| Modelo | Input ($/M) | Output ($/M) | Leitura de cache ($/M) |
|---|---|---|---|
claude-opus-4-6 / 4-8 | 5 | 25 | 0.5 |
claude-fable-5 | 10 | 50 | 1 |
2. O mesmo texto tem ~45% mais tokens que no 4.6 (devido à mudança de tokenizer descrita acima).
Combinando os dois fatores, o mesmo prompt em inglês custa bem mais. Fizemos a medição com o mesmo system prompt em cada modelo, usando o usage.cost do gateway e uma única execução:
| Comparação | Proporção de tokens | Proporção de preço | Proporção de custo para o mesmo prompt (medida) |
|---|---|---|---|
| Fable 5 vs Opus 4.8 | 1,00x | 2,0x | 2,0x |
| Fable 5 vs Opus 4.6 | 1,45x | 2,0x | 2,9x |
Em relação ao Opus 4.8, que usa o mesmo tokenizer, o Fable 5 custa exatamente 2x: a diferença vem apenas do preço. Em relação ao Opus 4.6, a mudança de tokenizer se soma à mudança de preço, elevando o custo do mesmo prompt para aproximadamente 2,9x. O desconto do cache continua igual, mas a base absoluta sobre a qual ele incide é ~2,9x maior que no 4.6. Se o seu orçamento por chamada foi calculado com base no 4.6, recalcule-o.
Há uma consequência prática: revise o mínimo de 1,024 tokens para uso do cache. A Anthropic só armazena em cache prefixos que atingem um tamanho mínimo. Um prompt que ficava pouco abaixo desse limite no 4.6, considerando os tokens do tokenizer antigo, pode ultrapassá-lo no Fable 5, que gera ~45% mais tokens. O mesmo cuidado vale para estimativas de tamanho calculadas com a contagem antiga. Em vez de estimar com um tokenizer local que talvez não corresponda ao do modelo, consulte sempre cache_creation_input_tokens / cache_read_input_tokens na resposta real.
Checklist de migração (Opus → Fable 5)
- ✅ O código de cache pode ser mantido sem alterações. Marcadores
cache_control, quantidade de breakpoints (até 4),ttl: "1h"e nomes dos campos de uso são idênticos. - ✅ As escolhas de TTL continuam válidas. 5m para cargas de trabalho ao vivo ou por sessão; 1h para workloads intermitentes ou agents com pausas.
- ✅ A economia do cache continua igual. Desconto de ~90%+ na leitura, adicional de ~1,25x na escrita de 5m e ~2x na escrita de 1h.
- ⚠️ Recalcule o custo absoluto. O Fable 5 custa ~2x o Opus por token e ~2,9x o custo do mesmo prompt no Opus 4.6. O percentual de desconto não mudou, mas a base sobre a qual ele incide mudou.
- ⚠️ Refaça a medição da quantidade de tokens se estiver migrando do 4.6 ou de uma versão anterior. Espere ~45% a mais para o mesmo texto. Em relação ao 4.7/4.8, espere a mesma contagem.
- ⚠️ Inclua os thinking tokens gerados por padrão. O Fable 5 gera reasoning tokens por padrão, cobrados pela tarifa de output ($50/M). Limite ou desative o thinking se não precisar dele.
Conclusão
Para uma equipe que já usa cache com o Claude, a integração com o claude-fable-5 é simples: toda a interface de cache e TTL permanece estável, sem novos conceitos ou mudanças de código. No orçamento, porém, ele não substitui o Opus 4.6 sem impacto. Com o preço por token 2x maior e a inflação de ~45% causada pelo tokenizer, o mesmo prompt custa ~2,9x mais. Confirme os números no objeto usage real, decida se precisa dos thinking tokens gerados por padrão e dimensione os breakpoints de cache com base nas novas contagens de tokens.
Para um guia completo de cache, incluindo estrutura de prompts, diagnóstico da taxa de acerto e padrões que consideram o TTL, consulte o guia completo de cache de prompts, o primeiro texto da série, Como funcionam o KV Cache e o TTL, e o tutorial prático em Python.
Perguntas frequentes
Preciso alterar meu código de cache_control para usar o Fable 5?
Não. A sintaxe dos marcadores, o limite de breakpoints e as opções de TTL são idênticos aos da linha Opus. Altere apenas o campo model; o restante do fluxo de cache permanece igual.
O desconto de leitura do cache mudou no Fable 5? Não. Uma leitura com cache aquecido custa uma pequena fração de um dígito do preço de input sem cache, com desconto de ~90%+. Medimos ~94% no Fable 5, resultado compatível com a economia documentada pela Anthropic para leituras em cache.
O Fable 5 aceita TTL de 1 hora?
Sim. {"type": "ephemeral", "ttl": "1h"} funciona exatamente como no Opus. A escrita de 1 hora custa ~2x o valor sem cache, e a de 5 minutos, ~1,25x. As leituras mantêm um desconto alto nos dois casos.
Por que o mesmo prompt custa muito mais no Fable 5 que no Opus 4.6? Há dois multiplicadores: o preço por token do Fable 5 é 2x maior, e o mesmo texto em inglês gera ~45% mais tokens porque ele usa o tokenizer posterior ao 4.6. Combinados, esses fatores elevam o custo do mesmo prompt em ~2,9x. O desconto do cache não mudou.
O Fable 5 substitui diretamente o Opus 4.8? Quanto à interface de cache/TTL e à quantidade de tokens, sim. As contagens são idênticas, então as únicas diferenças são o preço 2x maior e os thinking tokens gerados por padrão pelo Fable 5. Não publicamos benchmarks de capacidade que não executamos. Para informações sobre qualidade e reasoning, consulte o model card da Anthropic.
Verificação: todas as contagens de tokens e métricas de custo, adicional de escrita e desconto de leitura foram medidas em https://synthorai.io/ em 2026-06-10, usando o SDK oficial anthropic, um único tenant e uma única execução sequencial. O custo foi obtido do campo usage.cost do gateway. As proporções entre modelos, adicionais e descontos foram calculadas com base nesses custos medidos e não dependem de promoções específicas da conta. As proporções de desconto e adicional foram comparadas com a documentação da Anthropic sobre cache de prompts. Em nossa execução, a latência de leitura com cache aquecido (TTFT) foi dominada pela variação da rede e, por isso, foi omitida por não ser confiável. Seus números variam conforme o prompt, a região e a carga.