Tasa de aciertos de caché de Codex

Puntos clave

• Qué es normal: 94.8%, mediana de 71 usuarios en conversaciones en curso; mitad central 91.2%–96.9%
• Todas las solicitudes: 91.8%, incluye enrutamiento, vencimiento y chats nuevos
• Mayor causa de fallos: contenido nuevo en turnos en curso, 57% de los fallos
• Entre interfaces: 4.6 puntos de diferencia, App de escritorio, Interfaz de terminal, codex exec (no interactivo)

Qué tasa de aciertos de caché es normal en cada cliente

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

• Tasa de aciertos en continuación (usuario mediano): 94.8%
• Mitad central de los usuarios: 91.2%–96.9%
• Usuarios que califican: 71 (al menos 20 turnos de continuación en la semana)
• Tasa de aciertos en todas las solicitudes: 91.8%

Tasa de aciertos de Codex por interfaz

La CLI, la extensión del IDE y la app de escritorio de un mismo cliente envían solicitudes casi idénticas, así que sus tasas de aciertos deberían ser parecidas.

• App de escritorio: 95.3% (55)
• Interfaz de terminal: 95.8% (11)
• codex exec (no interactivo): 91.2% (9)

Tasa de aciertos de Codex por versión

Una versión que cambia el prefijo de la solicitud muestra una tasa de aciertos claramente más baja que las demás, en la misma semana en que sale.

• 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 usuarios)
• 2026-10-06: 95.3% (54 usuarios)
• 2026-10-13: 95.4% (62 usuarios)
• 2026-10-20: 95.8% (49 usuarios)
• 2026-10-27: 95.1% (72 usuarios)
• 2026-11-03: 94.8% (71 usuarios)

¿Por qué mi tasa de aciertos de caché en Codex es baja? Fallos por causa

El 8.2% de la entrada de esta semana no se leyó de la caché. Aquí está por causa, con lo que puedes hacer en cada caso.

Contenido nuevo y cambios de prefijo en una conversación en curso: 57% de los fallos, cerca del 4.7% de toda la entrada

La caché de OpenAI necesita que todo el prefijo coincida. Cambiar el reasoning effort, las herramientas o el formato de salida a mitad de sesión, o que Codex compacte el historial (compaction), cambia el prefijo. Esta es la mayor fuente de fallos de caché en Codex.

Enrutada a otra cuenta o endpoint upstream: 19% de los fallos, cerca del 1.6% de toda la entrada

La caché de prompts vive en la cuenta upstream que atendió la solicitud. Cuando un relay o un gateway con varias cuentas envía el siguiente turno a otra cuenta, todo el contexto se escribe de nuevo. Las conexiones directas con el proveedor nunca muestran esta causa.

Conversación nueva o inactiva por más de una hora: 16% de los fallos, cerca del 1.3% de toda la entrada

La primera solicitud de una conversación nueva, o una después de una hora inactiva, tiene que volver a escribir la caché.

Cambio de modelo: 3% de los fallos, cerca del 0.3% de toda la entrada

Cada modelo tiene su propia caché, así que la primera solicitud después de cambiar de modelo vuelve a leer todo el historial.

Más de 5 minutos inactivo, caché vencida: 3% de los fallos, cerca del 0.2% de toda la entrada

En GPT-5.6 y posteriores la caché dura 30 minutos por defecto, contados desde la última escritura o reutilización; los modelos anteriores suelen descartarla tras 5–10 minutos de inactividad.

Solicitud en paralelo (la anterior sigue en curso): 2% de los fallos, cerca del 0.2% de toda la entrada

Una solicitud enviada antes de que termine la anterior (subagentes, llamadas a herramientas en paralelo) no puede leer la caché que la anterior todavía está escribiendo.

TTL de la caché de Codex: cuánto dura y cuánto cuesta

• OpenAI guarda en caché los prefijos de prompt automáticamente, sin breakpoints del cliente; GPT-5.6 y posteriores cachean prompts desde 1,024 tokens.
• GPT-5.6 y posteriores la conservan 30 minutos por defecto, desde la última escritura o reutilización. Los modelos anteriores mantienen las entradas en memoria unos 5–10 minutos de inactividad, hasta una hora; algunos admiten retención de 24 horas.
• La entrada en caché suele cobrarse a 0.1× el precio de entrada, 0.05× en GPT-6.1 Sol; GPT-5.6 y posteriores cobran 1.25× por las escrituras de caché.
• Codex envía el ID de sesión como prompt_cache_key (según su código fuente), así que las solicitudes de una sesión se enrutan a la misma caché.

Caché de prompts de OpenAI · Diagnóstico de fallos de caché de OpenAI · Código fuente de Codex (prompt_cache_key) · Codex issue #35416: fallos al cambiar el reasoning effort

Cómo revisar tu tasa de aciertos de caché en Codex

• Al salir, Codex CLI imprime el uso de tokens de la sesión; la parte "+ N cached" es la entrada leída de la caché (comportamiento actual, no documentado).
• Desde la API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 y posteriores también reportan las escrituras de caché.
• La métrica de OpenTelemetry turn.token_usage incluye un tipo cached_input.
• En Wokey, cada solicitud del registro de solicitudes de la consola muestra sus lecturas y escrituras de caché.

Diagnóstico de fallos de caché de OpenAI

Por qué baja la tasa de aciertos detrás de un relay

• Cambio de cuenta: la caché pertenece a la cuenta upstream, así que un turno enviado a otra cuenta reescribe todo. Es la causa más común en los relays; las conexiones directas nunca la tienen.
• Conversión de formato: traducir entre los formatos de Anthropic y OpenAI puede cambiar el prefijo o eliminar los breakpoints de cache_control.
• Claude Code antes de v2.1.181, con un base URL personalizado, ponía un token distinto en cada solicitud dentro del bloque de atribución al inicio del system prompt, lo que anula a los gateways que cachean por el cuerpo de la solicitud; actualiza o define CLAUDE_CODE_ATTRIBUTION_HEADER=0.
• Prueba tú mismo: envía dos solicitudes con el mismo prefijo por encima de la longitud mínima de caché; las lecturas de caché de la segunda deberían acercarse a la longitud del prefijo.

Wokey enruta las solicitudes posteriores de una conversación a la misma cuenta upstream siempre que puede. Del 2026-10-04 al 2026-10-10, los usuarios comunes de Wokey lograron 92.8% de aciertos en Claude Opus 5.5 sobre todas las solicitudes, frente al 87.8% de OpenRouter en general.

Comparar con las tasas de aciertos de caché de OpenRouter · En vivo: API pública de tasa de aciertos de caché de Wokey (últimos 7 días)

Cómo medimos

• Solicitudes reales de usuarios a través del gateway de Wokey; cada lunes a las 05:00 UTC calculamos la semana anterior, de lunes a domingo.
• Los clientes se identifican por el User-Agent de la solicitud. Las solicitudes de SDKs, bibliotecas HTTP y relays intermedios, cuyo cliente real se desconoce, quedan fuera, igual que las cuentas empresariales.
• Un turno de continuación tiene el mismo modelo y la misma cuenta upstream que la solicitud anterior de su conversación y empieza dentro de los 5 minutos posteriores a que esta termine. La tasa de cada usuario es lecturas de caché ÷ entrada en esos turnos (la entrada incluye lecturas y escrituras de caché); publicamos la mediana de los usuarios con al menos 20 turnos así en la semana.
• Una celda se publica con al menos 5 usuarios que califican; un cambio de más de 3 puntos respecto a la semana anterior se revisa a mano primero.
• Sesgos conocidos: solo usuarios de Wokey; los hábitos de uso varían mucho; la tasa sobre todas las solicitudes incluye la pérdida por enrutamiento del propio gateway (la causa "enrutada a otra cuenta upstream").

Preguntas frecuentes