Taxa de acerto de cache do OpenCode com modelos Claude

Na semana de 2026-11-03, o OpenCode com modelos Claude teve taxa mediana de acerto de cache na continuação de 97.6% (20 usuários), e 95.1% sobre todas as requisições. A maioria das falhas veio de: conversas novas (34%), conteúdo novo em turnos em andamento (31%), expiração do cache (31%).

Semana de 2026-11-03 – 2026-11-09 (UTC)

Principais conclusões

  • O que é normal: 97.6%, mediana de 20 usuários em conversas em andamento; metade central 97.1%–98.9%
  • Todas as requisições: 95.1%, inclui roteamento, expiração e chats novos
  • Maior causa de falhas: conversas novas, 34% das falhas
  • Entre interfaces: 0.6 pontos de diferença, App para desktop, CLI (terminal)

Qual taxa de acerto de cache é normal em cada cliente

Semana de 2026-11-03 – 2026-11-09 (UTC)

  • Taxa de acerto na continuação (usuário mediano): 97.6%
  • Metade central dos usuários: 97.1%–98.9%
  • Usuários qualificados: 20 (pelo menos 20 turnos de continuação na semana)
  • Taxa de acerto em todas as requisições: 95.1%

Taxa de acerto do OpenCode por interface

A CLI, a extensão do IDE e o app desktop de um mesmo cliente enviam requisições quase idênticas, então as taxas de acerto deveriam ser próximas.

  • App para desktop: 98.0% (7)
  • CLI (terminal): 97.4% (6)

Taxa de acerto do OpenCode por versão

Uma versão que muda o prefixo da requisição mostra uma taxa de acerto claramente menor que as outras, já na semana em que sai.

  • 2.2.5: 97.5% (10)

Mediana semanal

  • 2026-09-29: 96.5% (7 usuários)
  • 2026-10-06: 97.6% (8 usuários)
  • 2026-10-13: 98.8% (11 usuários)
  • 2026-10-20: 97.4% (10 usuários)
  • 2026-10-27: 96.4% (13 usuários)
  • 2026-11-03: 97.6% (20 usuários)

Por que minha taxa de acerto de cache no OpenCode está baixa? Falhas por causa

4.9% da entrada desta semana não foi lido do cache. Aqui está por causa, com o que você pode fazer em cada caso.

Conversa nova ou ociosa por mais de uma hora: 34% das falhas, cerca de 1.7% de toda a entrada
A primeira requisição de uma conversa nova, ou uma depois de uma hora ociosa, precisa gravar o cache de novo.
Conteúdo novo e mudanças de prefixo em uma conversa em andamento: 31% das falhas, cerca de 1.5% de toda a entrada
O conteúdo novo de um turno só pode ser gravado, não lido, e isso é inevitável; um system prompt ou uma lista de ferramentas alterados, ou um histórico reescrito, também invalidam o prefixo.
Mais de 5 minutos ocioso, cache expirado: 31% das falhas, cerca de 1.5% de toda a entrada
Passaram mais de 5 minutos entre as requisições, então a entrada de cache anterior pode ter expirado.
Roteada para outra conta ou endpoint upstream: 3% das falhas, cerca de 0.2% de toda a entrada
O cache de prompt fica na conta upstream que atendeu a requisição. Quando um relay ou um gateway com várias contas envia o turno seguinte para outra conta, todo o contexto é gravado de novo. Conexões diretas com o fornecedor nunca mostram essa causa.
Requisição em paralelo (a anterior ainda em andamento): 0% das falhas, cerca de 0.0% de toda a entrada
Uma requisição enviada antes de a anterior terminar (subagentes, chamadas de ferramentas em paralelo) não consegue ler o cache que a anterior ainda está gravando.
Troca de modelo: 0% das falhas, cerca de 0.0% de toda a entrada
Cada modelo tem seu próprio cache, então a primeira requisição depois de trocar de modelo lê todo o histórico de novo.

Alguns pontos de taxa de acerto, várias vezes a conta

Com os preços oficiais do Claude Opus 5.5, e as falhas gravadas no cache de 5 minutos, o custo efetivo por milhão de tokens de entrada:

  • Mediana desta semana, 97.6%: $0.32 (×1.0)
  • 90%: $0.68 (×2.1)
  • 80%: $1.16 (×3.7)
  • 50%: $2.60 (×8.2)

Calcule com seus próprios números na calculadora de custos da API do Claude

Como conferir sua taxa de acerto de cache no OpenCode

  • Formato da Anthropic: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
  • Formato da OpenAI: cached_tokens (em prompt_tokens_details ou input_tokens_details) ÷ prompt_tokens / input_tokens.
  • Na Wokey, cada requisição no registro de requisições do console mostra suas leituras e gravações de cache.

Por que a taxa de acerto cai atrás de um relay

  • Troca de conta: o cache pertence à conta upstream, então um turno enviado para outra conta regrava tudo. É a causa mais comum nos relays; conexões diretas nunca têm isso.
  • Conversão de formato: traduzir entre os formatos da Anthropic e da OpenAI pode mudar o prefixo ou descartar os breakpoints de cache_control.
  • O Claude Code anterior à v2.1.181, com base URL personalizado, colocava um token diferente a cada requisição no bloco de atribuição no início do system prompt, o que anula gateways que fazem cache pelo corpo da requisição; atualize ou defina CLAUDE_CODE_ATTRIBUTION_HEADER=0.
  • Teste você mesmo: envie duas requisições com o mesmo prefixo acima do tamanho mínimo de cache; as leituras de cache da segunda devem ficar perto do tamanho do prefixo.

A Wokey roteia as requisições seguintes de uma conversa para a mesma conta upstream sempre que pode. De 2026-10-04 a 2026-10-10, usuários comuns da Wokey tiveram 92.8% de acerto no Claude Opus 5.5 sobre todas as requisições, contra 87.8% do OpenRouter no geral.

Comparar com as taxas de acerto de cache do OpenRouter · Ao vivo: API pública de taxa de acerto de cache da Wokey (últimos 7 dias)

Como medimos

  • Requisições reais de usuários pelo gateway da Wokey; toda segunda-feira às 05:00 UTC calculamos a semana anterior, de segunda a domingo.
  • Os clientes são identificados pelo User-Agent da requisição. Requisições de SDKs, bibliotecas HTTP e relays intermediários, cujo cliente real é desconhecido, ficam de fora, assim como as contas empresariais.
  • Um turno de continuação tem o mesmo modelo e a mesma conta upstream que a requisição anterior da conversa e começa até 5 minutos depois de ela terminar. A taxa de cada usuário é leituras de cache ÷ entrada nesses turnos (a entrada inclui leituras e gravações de cache); publicamos a mediana dos usuários com pelo menos 20 turnos assim na semana.
  • Uma célula é publicada com pelo menos 5 usuários qualificados; uma mudança de mais de 3 pontos em relação à semana anterior é conferida manualmente antes.
  • Vieses conhecidos: só usuários da Wokey; os hábitos de uso variam muito; a taxa sobre todas as requisições inclui a perda de roteamento do próprio gateway (a causa "roteada para outra conta upstream").

Perguntas frequentes

Qual é uma taxa de acerto de cache normal no OpenCode?

Nesta semana a mediana de 20 usuários foi de 97.6% em conversas em andamento, com a metade central entre 97.1% e 98.9%; sobre todas as requisições foi de 95.1%.

Por que minha taxa de acerto de cache no OpenCode está baixa?

Nesta semana a maioria das falhas veio de: conversas novas (34%), conteúdo novo em turnos em andamento (31%), expiração do cache (31%). A página mostra o que fazer em cada causa.

Uma taxa de acerto de cache baixa consome o limite do meu plano do Claude mais rápido?

Sim. Nas nossas medições dos limites dos planos do Claude, as leituras de cache quase não consomem limite, enquanto as gravações contam mais ou menos como entrada sem cache. Um contexto em cache quase não custa nada; um que falha volta a contar inteiro. Os limites de cada plano estão na página de limites de uso do Claude (/claude-usage-limits).