Taxa de acerto de cache do Codex

Principais conclusões

• O que é normal: 94.8%, mediana de 71 usuários em conversas em andamento; metade central 91.2%–96.9%
• Todas as requisições: 91.8%, inclui roteamento, expiração e chats novos
• Maior causa de falhas: conteúdo novo em turnos em andamento, 57% das falhas
• Entre interfaces: 4.6 pontos de diferença, App para desktop, Interface de terminal, codex exec (não interativo)

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): 94.8%
• Metade central dos usuários: 91.2%–96.9%
• Usuários qualificados: 71 (pelo menos 20 turnos de continuação na semana)
• Taxa de acerto em todas as requisições: 91.8%

Taxa de acerto do Codex 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: 95.3% (55)
• Interface de terminal: 95.8% (11)
• codex exec (não interativo): 91.2% (9)

Taxa de acerto do Codex 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.

• 0.167.0-alpha.3.2: 95.0% (27)
• 0.167.0: 93.3% (6)
• 0.166.0-alpha.6: 95.6% (29)
• 0.166.0-alpha.5.1: 96.4% (28)
• 0.166.0: 96.6% (5)

Mediana semanal

• 2026-09-29: 96.0% (38 usuários)
• 2026-10-06: 95.3% (54 usuários)
• 2026-10-13: 95.4% (62 usuários)
• 2026-10-20: 95.8% (49 usuários)
• 2026-10-27: 95.1% (72 usuários)
• 2026-11-03: 94.8% (71 usuários)

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

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

Conteúdo novo e mudanças de prefixo em uma conversa em andamento: 57% das falhas, cerca de 4.7% de toda a entrada

O cache da OpenAI exige que todo o prefixo seja igual. Mudar o reasoning effort, as ferramentas ou o formato de saída no meio da sessão, ou o Codex compactar o histórico (compaction), muda o prefixo. Essa é a maior fonte de falhas de cache no Codex.

Roteada para outra conta ou endpoint upstream: 19% das falhas, cerca de 1.6% 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.

Conversa nova ou ociosa por mais de uma hora: 16% das falhas, cerca de 1.3% 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.

Troca de modelo: 3% das falhas, cerca de 0.3% 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.

Mais de 5 minutos ocioso, cache expirado: 3% das falhas, cerca de 0.2% de toda a entrada

No GPT-5.6 e posteriores o cache dura 30 minutos por padrão, contados a partir da última gravação ou reutilização; modelos mais antigos costumam descartá-lo após 5–10 minutos de ociosidade.

Requisição em paralelo (a anterior ainda em andamento): 2% das falhas, cerca de 0.2% 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.

TTL do cache do Codex: quanto dura e quanto custa

• A OpenAI faz cache dos prefixos de prompt automaticamente, sem breakpoints no cliente; o GPT-5.6 e posteriores fazem cache de prompts a partir de 1,024 tokens.
• O GPT-5.6 e posteriores mantêm o cache por 30 minutos por padrão, a partir da última gravação ou reutilização. Modelos mais antigos mantêm as entradas em memória por cerca de 5–10 minutos de ociosidade, até uma hora; alguns suportam retenção de 24 horas.
• A entrada em cache costuma ser cobrada a 0.1× o preço de entrada, 0.05× no GPT-6.1 Sol; o GPT-5.6 e posteriores cobram 1.25× pelas gravações de cache.
• O Codex envia o ID da sessão como prompt_cache_key (segundo o código-fonte), então as requisições de uma sessão são roteadas para o mesmo cache.

Cache de prompt da OpenAI · Diagnóstico de falhas de cache da OpenAI · Código-fonte do Codex (prompt_cache_key) · Codex issue #35416: falhas ao mudar o reasoning effort

Como conferir sua taxa de acerto de cache no Codex

• Ao sair, o Codex CLI imprime o uso de tokens da sessão; a parte "+ N cached" é a entrada lida do cache (comportamento atual, não documentado).
• Pela API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; o GPT-5.6 e posteriores também informam as gravações de cache.
• A métrica do OpenTelemetry turn.token_usage inclui um tipo cached_input.
• Na Wokey, cada requisição no registro de requisições do console mostra suas leituras e gravações de cache.

Diagnóstico de falhas de cache da OpenAI

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