Claude Opus 4.8 na Synthorai: cache e TTL em comparação com 4.7/4.6

claude-opus-4-8 já está disponível no gateway da Synthorai. Para quem já usa prompt caching com a linha Opus, a principal notícia é tranquilizadora e até um pouco sem graça: o contrato de cache e TTL não mudou em relação ao 4.7 ou 4.6. Os marcadores cache_control são os mesmos, assim como os TTLs de 5 minutos e 1 hora, o desconto de leitura e os adicionais de escrita. Você pode reaproveitar o código de cache sem alterações.

Só houve uma mudança que afeta seu orçamento de tokens. Ela aconteceu no 4.7, não no 4.8. Este post traz as medições para que você não precise fazê-las.

TL;DR

• Claude Opus 4.8 mantém inalterado o contrato de cache do 4.7/4.6: desconto de leitura medido em 89%, adicional de escrita de cerca de 1.25x no TTL de 5 minutos e de cerca de 2x no TTL de 1 hora.
• O mesmo texto de system contabiliza cerca de 43% mais tokens de entrada no Opus 4.7/4.8 do que no 4.5/4.6 (11,394 contra 7,976 tokens).
• O preço por token é idêntico em toda a linha Opus: a proporção de custo entre 4.8 e 4.5, de 1.43, corresponde à proporção de tokens, de 1.429.
• O TTFT de leituras com cache aquecido fica entre 2.2 e 2.8s no Opus 4.5-4.8; as diferenças são apenas variação das medições.

Todos os números abaixo foram medidos em https://synthorai.io/ (endpoint /v1/messages nativo da Anthropic) em 2026-05-29, com um system prompt em inglês de aproximadamente 8K caracteres, max_tokens baixo e uma única execução sequencial. Antes de citar esses números, reproduza o teste com seu próprio prompt.

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; nenhuma outra parte do fluxo de cache precisa mudar. O funcionamento do cache_control está detalhado no tutorial de cache. A arquitetura que explica por que esse cache existe está na Parte 1 da série.

Comportamento do cache: igual ao 4.7/4.6

Executamos a mesma sequência de escrita no cache, leitura do cache e chamada sem cache nas versões recentes da linha Opus. A estrutura de descontos é idêntica em todos os casos.

Duas propriedades permanecem constantes nas quatro versões:

• Desconto de leitura ≈ 89%. Uma leitura com cache aquecido custa aproximadamente 11% do preço de entrada sem cache. É a tarifa documentada pela Anthropic, de 10% para leituras em cache, sem alterações.
• Adicional de escrita ≈ 25%. A primeira chamada, com cache frio, custa aproximadamente 1.25× o preço sem cache para preencher o cache. Basta um cache hit para atingir o ponto de equilíbrio.

Os valores absolutos em dólares do 4.7 e 4.8 são maiores que os do 4.5/4.6. Como veremos a seguir, isso vem da contagem de tokens, não da economia do cache: os percentuais permanecem iguais.

Comportamento do TTL: igual ao 4.7/4.6

O Opus 4.8 aceita os mesmos dois TTLs das demais versões da linha: 5 minutos por padrão, com renovação a cada acesso, ou uma janela opcional de 1 hora. Isolamos o fluxo de TTL usando um prefixo exclusivo em cada chamada, impedindo que uma entrada antiga do cache contaminasse o resultado, e medimos o adicional de escrita de 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 de usage informa a faixa de TTL exatamente como antes: cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens. A escrita com TTL de 1 hora custa aproximadamente 2× o valor sem cache, contra cerca de 1.25× na escrita de 5 minutos. As leituras continuam em aproximadamente 11%, independentemente do TTL. O comportamento é idêntico ao 4.7. Se você usava 5m em chats ao vivo e 1h em agentes com pausas para intervenção humana no 4.7, mantenha essas escolhas no 4.8.

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

Medimos o TTFT de leituras com cache aquecido usando uma chamada em streaming, com 5 amostras por modelo após o aquecimento do gateway, e registramos a mediana. Neste prompt de aproximadamente 8–11K tokens, o TTFT ficou entre cerca de 2.2 e 2.8 s, sem tendência relevante entre versões. Como os intervalos das amostras se sobrepõem, as diferenças são variações das medições, não um efeito da versão.

Duas ressalvas precisam ficar claras:

• Não interprete esses dados como um ranking. Os intervalos têm grande sobreposição; a maior amostra do 4.8, de 4.38 s, foi um outlier. Para prompts desse tamanho, o TTFT é determinado principalmente pela variação da rede e das filas, não pela versão do modelo. Considere aproximadamente 2.2–2.8 s como a faixa com cache aquecido para os quatro modelos.
• O ganho de TTFT com cache cresce com o tamanho do prompt. Em prompts de aproximadamente 8–11K tokens, a economia de prefill gerada por um cache hit é pequena. Por isso, o TTFT com cache frio e aquecido fica próximo, em torno de 2–3 s em um gateway já aquecido. A diferença aumenta bastante acima de 100K tokens, quando o prefill passa a dominar. Nesse cenário, um cache aquecido reduz uma espera de vários segundos e entrega rapidamente o primeiro token. O funcionamento está explicado na Parte 1: como funcionam KV Cache e TTL.

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

Este é o ponto que você precisa revisar antes da migração. O mesmo texto de system contabiliza aproximadamente 43% mais tokens de entrada no 4.7/4.8 do que no 4.5/4.6.

A contagem de tokens aumenta na geração 4.7 e permanece nesse patamar no 4.8. O custo acompanha a contagem quase exatamente: a proporção de custo (4.8 / 4.5) é 1.43, enquanto a proporção de tokens é 1.429. O preço por token é o mesmo em toda a linha; a conta maior no 4.7/4.8 ocorre exclusivamente porque o mesmo texto passa a ser contabilizado como mais tokens.

Isso traz duas consequências práticas:

1. Refaça o orçamento pelo custo absoluto, não pelo desconto. O desconto do cache continua igual, com aproximadamente 89% na leitura, mas o mesmo prompt em inglês custa cerca de 43% mais em termos absolutos no 4.7/4.8 do que custava no 4.6. Se o orçamento por chamada foi dimensionado com base na contagem de tokens do 4.6, ele estará incorreto.
2. Revise o mínimo de 1,024 tokens exigido para 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 pode ultrapassá-lo no 4.7/4.8 por passar a ter mais tokens. Prompts dimensionados em tokens com o tokenizer antigo também precisam ser medidos novamente. Leia sempre cache_creation_input_tokens / cache_read_input_tokens na resposta real, em vez de fazer estimativas com um tokenizer local que pode não corresponder ao usado pelo modelo.

Esta é uma observação baseada nas medições: textos idênticos geraram aproximadamente 43% mais tokens de entrada reportados no 4.7/4.8. A explicação mais provável é uma atualização do tokenizer ou do vocabulário na geração 4.7. A recomendação independe da causa: meça novamente a contagem de tokens ao migrar, pois os cálculos de cache são feitos com base em tokens.

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

• ✅ O código de cache pode ser reaproveitado sem alterações. Marcadores cache_control, quantidade de breakpoints, até 4, ttl: "1h" e nomes dos campos de usage são idênticos.
• ✅ As escolhas de TTL continuam válidas. 5m para workloads de sessão ou em tempo real; 1h para cargas em rajadas ou agentes com pausas.
• ✅ A economia do desconto permanece igual. Aproximadamente 89% na leitura, ~1.25× na escrita de 5m e ~2× na escrita de 1h.
• ⚠️ Meça novamente a contagem de tokens. Se você está migrando do 4.5/4.6, espere mais de 40% de tokens de entrada para o mesmo texto; essa mudança ocorreu no 4.7. Ao migrar do 4.7, espere números equivalentes.
• ⚠️ Valide novamente os dashboards de custo. Use usage.cost e os campos *_input_tokens da resposta real, não uma estimativa em cache feita para a geração anterior.

Resumo

Para uma equipe de engenharia que já usa cache com o Opus, claude-opus-4-8 é uma atualização simples: toda a interface de cache e TTL permanece estável. Não há nada novo para aprender nem código para reescrever. Se você está migrando do 4.6 ou de uma versão anterior, ajuste o orçamento por causa da mudança de tokenizer. Confirme os números no objeto usage real e faça o deploy.

O guia completo de cache, incluindo estrutura de prompts, diagnóstico de cache hits e padrões que consideram TTL, está na série sobre prompt caching. Comece por Como funcionam KV Cache e TTL e pelo tutorial prático em Python.

Perguntas frequentes

Preciso alterar meu código de cache_control para usar o Opus 4.8? Não. A sintaxe dos marcadores, o limite de breakpoints e as opções de TTL são idênticos aos do 4.7/4.6. Altere apenas o campo model.

O desconto de leitura do cache mudou no 4.8? Não. Do 4.5 ao 4.8, uma leitura com cache aquecido custa aproximadamente 11% do preço de entrada sem cache, um desconto de cerca de 89%, conforme a tarifa documentada pela Anthropic.

O adicional do TTL de 1 hora mudou? Não. A escrita de 1 hora custa aproximadamente 2× o preço de entrada sem cache; a escrita de 5 minutos custa cerca de 1.25×. As leituras ficam em aproximadamente 11%, independentemente do TTL. É o mesmo comportamento do 4.7.

Por que o mesmo prompt custa mais no 4.8 do que no 4.6? O preço por token é o mesmo; o prompt apenas passa a contabilizar mais tokens. Em nossas medições, um texto idêntico gerou aproximadamente 8.0K tokens no 4.5/4.6 e aproximadamente 11.4K no 4.7/4.8, um aumento de cerca de 43%. A explicação mais provável é uma mudança de tokenizer na geração 4.7. O desconto do cache não mudou.

O 4.8 substitui diretamente o 4.7? Na interface de cache e TTL, sim. A contagem de tokens e a economia já estavam nesse patamar no 4.7, portanto a migração do 4.7 mantém os mesmos números. 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: todos os números de cache, TTL, contagem de tokens, custo e TTFT foram medidos em https://synthorai.io/ em 2026-05-29, usando o SDK oficial anthropic e um único tenant. Os valores de custo e tokens vêm de uma única execução sequencial; o TTFT é a mediana de 5 amostras por modelo após o aquecimento do gateway. As proporções de desconto e adicional foram conferidas com a documentação da Anthropic sobre prompt caching. Seus números variam conforme o prompt, a região e a carga.

← Voltar ao blog