Tasa de aciertos de caché de OpenCode con modelos Claude

Puntos clave

• Qué es normal: 97.6%, mediana de 20 usuarios en conversaciones en curso; mitad central 97.1%–98.9%
• Todas las solicitudes: 95.1%, incluye enrutamiento, vencimiento y chats nuevos
• Mayor causa de fallos: conversaciones nuevas, 34% de los fallos
• Entre interfaces: 0.6 puntos de diferencia, App de escritorio, CLI (terminal)

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): 97.6%
• Mitad central de los usuarios: 97.1%–98.9%
• Usuarios que califican: 20 (al menos 20 turnos de continuación en la semana)
• Tasa de aciertos en todas las solicitudes: 95.1%

Tasa de aciertos de OpenCode 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: 98.0% (7)
• CLI (terminal): 97.4% (6)

Tasa de aciertos de OpenCode 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.

• 2.2.5: 97.5% (10)

Mediana semanal

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

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

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

Conversación nueva o inactiva por más de una hora: 34% de los fallos, cerca del 1.7% 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é.

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

El contenido nuevo de un turno solo se puede escribir, no leer, y eso es inevitable; un system prompt o una lista de herramientas modificados, o un historial reescrito, también invalidan el prefijo.

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

Pasaron más de 5 minutos entre solicitudes, así que la entrada de caché anterior pudo haber vencido.

Enrutada a otra cuenta o endpoint upstream: 3% de los fallos, cerca del 0.2% 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.

Solicitud en paralelo (la anterior sigue en curso): 0% de los fallos, cerca del 0.0% 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.

Cambio de modelo: 0% de los fallos, cerca del 0.0% 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.

Unos puntos de tasa de aciertos, varias veces la factura

A precios oficiales de Claude Opus 5.5, con los fallos escritos en la caché de 5 minutos, el costo efectivo por millón de tokens de entrada:

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

Calcula con tus propios números en la calculadora de costos de la API de Claude

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

• Formato de Anthropic: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
• Formato de OpenAI: cached_tokens (en prompt_tokens_details o input_tokens_details) ÷ prompt_tokens / input_tokens.
• En Wokey, cada solicitud del registro de solicitudes de la consola muestra sus lecturas y escrituras de caché.

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