Claude Opus 4.8 no Synthorai: cache e TTL frente a 4.7/4.6

claude-opus-4-8 já está disponível no gateway do Synthorai. Se você já executa cache de prompts com a linha Opus, a notícia principal é tranquilizadora e um pouco entediante: nada no contrato de cache ou de TTL mudou em relação ao 4.7 ou 4.6. Os mesmos marcadores cache_control, os mesmos TTLs de 5 minutos e 1 hora, o mesmo desconto de leitura, os mesmos acréscimos de escrita. Seu código de cache é reaproveitado tal como está.

Há exatamente uma coisa que de fato mudou — e mudou no 4.7, não no 4.8 — que afeta seu orçamento de tokens. Este artigo a mede para que você não precise fazê-lo.

Todos os números abaixo foram medidos contra https://synthorai.io/ (/v1/messages nativo da Anthropic) em 2026-05-29 com um prompt de sistema em inglês de ~8 K caracteres, max_tokens pequeno, uma única execução sequencial. Reproduza-os com seu próprio prompt antes de citá-los.

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-opus-4-8",            # 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)   # cache_creation_input_tokens, cache_read_input_tokens, cost

Troque claude-opus-4-7 → claude-opus-4-8 e nada mais no seu caminho de cache precisa mudar. Os mecanismos por trás do cache_control são abordados no tutorial de cache; a arquitetura de por que o cache existe está na parte 1 da série.

Comportamento do cache: inalterado em relação ao 4.7/4.6

Executamos a mesma sequência de escrita de cache / leitura de cache / sem cache ao longo da linha Opus recente. A estrutura de desconto é idêntica de ponta a ponta.

Dois invariantes se mantêm nas quatro versões:

• Desconto de leitura ≈ 89%. Uma leitura de cache quente custa ~11% do preço de entrada sem cache. Essa é a taxa de leitura em cache de 10% documentada pela Anthropic, inalterada.
• Acréscimo de escrita ≈ 25%. A primeira chamada (a frio) custa ~1,25× o preço sem cache para popular o cache. O ponto de equilíbrio é atingido com um único acerto.

Os valores absolutos em dólares para 4.7 e 4.8 são mais altos que os de 4.5/4.6, mas, como veremos em instantes, isso é uma questão de contagem de tokens, não de economia do cache — os percentuais permanecem estáveis.

Comportamento do TTL: inalterado em relação ao 4.7/4.6

O Opus 4.8 respeita os mesmos dois TTLs do restante da linha: um padrão deslizante de 5 minutos e uma janela opcional de 1 hora. Isolamos o caminho do TTL com um prefixo único por chamada (para que nenhuma entrada de cache obsoleta pudesse contaminar o resultado) e medimos o acréscimo de escrita para cada TTL:

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

O objeto usage relata o intervalo de TTL exatamente como antes — cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens. A escrita de 1 hora custa ~2× sem cache (contra ~1,25× para a escrita de 5 minutos), e as leituras permanecem em ~11% independentemente do TTL. Idêntico ao 4.7. Se você escolheu 5m para chat ao vivo e 1h para agentes com pausas com humano no ciclo no 4.7, mantenha essas escolhas no 4.8.

Tempo até o primeiro token: estável em toda a linha

Medimos o TTFT de leitura quente com uma chamada em streaming (5 amostras por modelo após um aquecimento do gateway, mediana reportada). Neste prompt de ~8–11 K tokens, o TTFT fica em uma faixa de ~2,2–2,8 s sem tendência relevante por versão — as faixas de amostras se sobrepõem, então as diferenças são ruído, não um efeito de versão.

Duas ressalvas que vale a pena declarar com clareza:

• Não interprete isto como um ranking. As faixas se sobrepõem fortemente (a amostra alta do 4.8 foi um valor atípico de 4,38 s); neste tamanho de prompt, o TTFT é dominado pelo ruído de rede e de enfileiramento, não pela versão do modelo. Considere ~2,2–2,8 s como a faixa quente para as quatro.
• O ganho de TTFT do cache escala com o comprimento do prompt. Com ~8–11 K tokens, o prefill economizado por um acerto de cache é pequeno, então o TTFT a frio e a quente ficam próximos (ambos ~2–3 s em um gateway aquecido). A diferença aumenta substancialmente acima de 100 K tokens, onde o prefill domina — é aí que um cache quente transforma uma espera de vários segundos em um primeiro token rápido. Os mecanismos estão na parte 1: como funcionam o cache KV e o TTL.

A única mudança real: a tokenização (desde o 4.7)

Aqui está o que reverificar antes de migrar. O mesmo texto de sistema relata ~43% mais tokens de entrada no 4.7/4.8 do que no 4.5/4.6.

A contagem de tokens dá um salto na geração 4.7 e se transfere para o 4.8. O custo acompanha a contagem de tokens quase exatamente: a razão de custo (4.8 / 4.5) é 1,43, e a razão de tokens é 1,429. Em outras palavras, o preço por token é o mesmo em toda a linha — a conta mais alta no 4.7/4.8 vem inteiramente do fato de o mesmo texto contar como mais tokens.

Duas consequências práticas:

1. Reorçamente com base no custo absoluto, não no desconto. Seu desconto de cache está inalterado (~89% em leitura), mas o mesmo prompt em inglês é ~43% mais caro em termos absolutos no 4.7/4.8 do que era no 4.6. Se você dimensionou um orçamento por chamada com base nas contagens de tokens do 4.6, ele ficará incorreto.
2. Reverifique o limiar de elegibilidade de cache de 1.024 tokens. A Anthropic só armazena em cache prefixos com tamanho igual ou superior a um mínimo. Um prompt que ficava logo abaixo do limiar no 4.6 pode ultrapassá-lo no 4.7/4.8 (mais tokens), e um prompt dimensionado em tokens para o tokenizador antigo precisa ser remedido. Sempre leia cache_creation_input_tokens / cache_read_input_tokens a partir da resposta ao vivo em vez de estimar a partir de um tokenizador local que pode não corresponder.

Descrevemos uma observação medida — texto idêntico, ~43% mais tokens de entrada relatados no 4.7/4.8 — que é mais consistente com uma atualização do tokenizador/vocabulário na geração 4.7. A conclusão não depende da causa-raiz: remeça as contagens de tokens ao migrar, porque o cálculo do cache é baseado em tokens.

Lista de verificação de migração (4.6/4.7 → 4.8)

• ✅ O código de cache é reaproveitado ao pé da letra. Marcadores cache_control, número de pontos de quebra (até 4), ttl: "1h", nomes dos campos usage — todos idênticos.
• ✅ As escolhas de TTL são reaproveitadas. 5 min para cargas ao vivo/de sessão, 1 h para cargas em rajada/agentes com pausas.
• ✅ A economia do desconto é reaproveitada. ~89% em leitura, ~1,25× em escrita (5 min), ~2× em escrita (1 h).
• ⚠️ Remeça as contagens de tokens. Se você vem do 4.5/4.6, espere ~40%+ mais tokens de entrada para o mesmo texto (isso aconteceu no 4.7). Vindo do 4.7, espere paridade.
• ⚠️ Revalide os painéis de custo. Confie em usage.cost e nos campos *_input_tokens da resposta ao vivo, não em uma estimativa em cache da geração antiga.

Conclusão

Para uma equipe de engenharia que já usa cache contra o Opus, claude-opus-4-8 é o tipo de atualização fácil: toda a superfície de cache e TTL é estável, então não há nada a reaprender nem código a reescrever. Orce a mudança do tokenizador se você está saltando do 4.6 ou anterior, confirme seus números com o objeto usage ao vivo e publique.

Para o manual completo de cache — estrutura do prompt, depuração da taxa de acertos, padrões que consideram o TTL — veja a série de quatro partes começando por Como funcionam o cache KV e o TTL e o tutorial funcional em Python.

Perguntas frequentes

Preciso mudar meu código de cache_control para usar o Opus 4.8? Não. A sintaxe dos marcadores, o limite de pontos de quebra e as opções de TTL são idênticos ao 4.7/4.6. Mude o campo model e nada mais.

O desconto de leitura de cache mudou no 4.8? Não. Uma leitura quente é ~11% do preço de entrada sem cache (~89% de desconto) do 4.5 ao 4.8, correspondendo à taxa documentada pela Anthropic.

O acréscimo do TTL de 1 hora mudou? Não. A escrita de 1 hora custa ~2× o preço de entrada sem cache; a escrita de 5 minutos custa ~1,25×. As leituras são ~11% independentemente do TTL. Igual ao 4.7.

Por que o mesmo prompt é mais caro no 4.8 do que no 4.6? O preço por token é o mesmo — o prompt simplesmente conta como mais tokens. Um texto idêntico relatou ~8,0 K tokens no 4.5/4.6 e ~11,4 K no 4.7/4.8 em nossas medições (um aumento de ~43%), o mais consistente com uma mudança de tokenizador na geração 4.7. O desconto de cache está inalterado.

O 4.8 é um substituto direto do 4.7? Na superfície de cache/TTL, sim — as contagens de tokens e a economia já estavam no nível do 4.7, então a migração do 4.7 é de paridade. Não publicamos benchmarks de capacidade que não executamos; para afirmações sobre qualidade e raciocínio, consulte a ficha do modelo da Anthropic.

Verificação: todos os números de cache, TTL, contagem de tokens, custo e TTFT foram medidos contra https://synthorai.io/ em 2026-05-29 usando o SDK oficial anthropic, inquilino único. Os números de custo/token são de uma única execução sequencial; o TTFT é uma mediana de 5 amostras por modelo após o aquecimento do gateway. As razões de desconto/acréscimo foram cruzadas com a documentação de cache de prompts da Anthropic. Seus números variarão conforme o prompt, a região e a carga.

← Voltar ao blog