Tasa de aciertos de caché de Claude Code

En la semana del 2026-11-03, Claude Code con modelos Claude tuvo una tasa mediana de aciertos de caché en continuación del 98.1% (343 usuarios), y del 94.6% sobre todas las solicitudes. La mayoría de los fallos vino de: vencimiento de caché (37%), contenido nuevo en turnos en curso (23%), conversaciones nuevas (17%).

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

Puntos clave

  • Qué es normal: 98.1%, mediana de 343 usuarios en conversaciones en curso; mitad central 96.9%–98.8%
  • Todas las solicitudes: 94.6%, incluye enrutamiento, vencimiento y chats nuevos
  • Mayor causa de fallos: vencimiento de caché, 37% de los fallos
  • Entre interfaces: 1.7 puntos de diferencia, CLI (terminal), App de escritorio, Agente local de escritorio

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

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

  • CLI (terminal): 98.2% (147)
  • App de escritorio: 98.4% (114)
  • Agente local de escritorio: 98.0% (78)
  • Extensión de VS Code: 97.8% (50)
  • Agent SDK (CLI): 96.7% (43)
  • Agent SDK (TypeScript): 97.8% (16)
  • t3-code: 97.9% (5)

Tasa de aciertos de Claude Code 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.1.321: 97.6% (5)
  • 2.1.319: 98.4% (77)
  • 2.1.318: 98.3% (92)
  • 2.1.317: 97.9% (133)
  • 2.1.316: 98.4% (44)
  • 2.1.314: 98.5% (25)
  • 2.1.312: 98.0% (20)
  • 2.1.311: 98.4% (13)
  • 2.1.310: 97.4% (14)
  • 2.1.309: 98.3% (98)
  • 2.1.308: 98.0% (30)
  • 2.1.302: 96.4% (7)
  • 2.1.299: 97.6% (6)
  • 2.1.296: 98.0% (8)
  • 2.1.295: 97.6% (14)
  • 2.1.292: 99.0% (5)
  • 2.1.284: 97.0% (6)
  • 2.1.280: 98.2% (11)

Mediana semanal

  • 2026-09-29: 96.8% (120 usuarios)
  • 2026-10-06: 97.8% (220 usuarios)
  • 2026-10-13: 98.0% (256 usuarios)
  • 2026-10-20: 98.0% (250 usuarios)
  • 2026-10-27: 98.0% (259 usuarios)
  • 2026-11-03: 98.1% (343 usuarios)

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

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

Más de 5 minutos inactivo, caché vencida: 37% de los fallos, cerca del 2.0% de toda la entrada
La caché dura 5 minutos por defecto y cada acierto la renueva gratis. Si sueles hacer pausas más largas, define CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+); entonces las escrituras de caché cuestan 2× el precio de entrada en lugar de 1.25×.
Contenido nuevo y cambios de prefijo en una conversación en curso: 23% de los fallos, cerca del 1.2% de toda la entrada
El contenido nuevo de un turno solo se puede escribir, no leer. Conectar o quitar servidores MCP, o activar plugins que traen servidores MCP, cambia las definiciones de herramientas e invalida la caché.
Conversación nueva o inactiva por más de una hora: 17% de los fallos, cerca del 0.9% 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: 12% de los fallos, cerca del 0.6% de toda la entrada
Cada modelo tiene su propia caché. Después de /model, la siguiente solicitud lee todo el historial sin aciertos de caché, aunque el contenido sea idéntico.
Solicitud en paralelo (la anterior sigue en curso): 10% de los fallos, cerca del 0.5% de toda la entrada
Los subagentes y las llamadas a herramientas en paralelo envían la siguiente solicitud antes de que termine la anterior. Un fork de Claude Code lee la caché de la sesión padre; un subagente normal tiene su propio system prompt y sus herramientas, y construye su propia caché.
Enrutada a otra cuenta o endpoint upstream: 2% de los fallos, cerca del 0.1% 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.

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, 98.1%: $0.29 (×1.0)
  • 90%: $0.68 (×2.3)
  • 80%: $1.16 (×4.0)
  • 50%: $2.60 (×9.0)

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

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

  • Dura 5 minutos por defecto, y cada acierto la renueva sin costo.
  • Cámbiala a 1 hora con CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+; CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL para subagentes), o con ENABLE_PROMPT_CACHING_1H=1 en versiones anteriores.
  • Las escrituras de caché cuestan 1.25× el precio de entrada (5 minutos) o 2× (1 hora); las lecturas suelen ser 0.1×, y 0.05× en Opus 5.5 y Sonnet 5.5.
  • Los prompts por debajo de la longitud mínima no se guardan en caché, sin aviso: de 512 a 4,096 tokens según el modelo.

Caché de prompts de Anthropic · Caché de prompts en Claude Code · Variables de entorno de Claude Code

Cómo revisar tu tasa de aciertos de caché en Claude Code

  • Ejecuta /usage en Claude Code: la línea Prompt cache (main) del bloque Session muestra el número de solicitudes, la parte de la entrada servida desde caché, los fallos de caché y si la caché sigue activa.
  • Los scripts de la línea de estado pueden leer los campos prompt_cache; el exportador de OpenTelemetry reporta tokens de lectura y creación de caché por usuario y sesión.
  • Desde la API: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
  • En Wokey, cada solicitud del registro de solicitudes de la consola muestra sus lecturas y escrituras de caché.

Costos y uso de Claude Code

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

¿Cuál es una tasa de aciertos de caché normal en Claude Code?

Esta semana la mediana de 343 usuarios fue del 98.1% en conversaciones en curso, con la mitad central entre 96.9% y 98.8%; sobre todas las solicitudes fue del 94.6%.

¿Por qué mi tasa de aciertos de caché en Claude Code es baja?

Esta semana la mayoría de los fallos vino de: vencimiento de caché (37%), contenido nuevo en turnos en curso (23%), conversaciones nuevas (17%). La página indica qué hacer con cada causa.

¿Una tasa de aciertos de caché baja consume más rápido el límite de mi plan de Claude?

Sí. En nuestras mediciones de los límites de los planes de Claude, las lecturas de caché casi no consumen límite, mientras que las escrituras cuentan más o menos como entrada sin caché. Un contexto en caché casi no cuesta nada; uno que falla vuelve a contar completo. Los límites de cada plan están en la página de límites de uso de Claude (/claude-usage-limits).

¿Qué son los cache read tokens en Claude Code?

La parte de la entrada servida desde la caché, reportada como cache_read_input_tokens. En sesiones largas suele ser más del 90% de la entrada y se cobra a 0.1× el precio de entrada (0.05× en Opus 5.5 y Sonnet 5.5); cache_creation_input_tokens es lo que esta solicitud escribió nuevo en la caché.

¿Vale la pena la caché de 1 hora?

Por lo general, no. Al reproducir un día de tráfico real de Claude en Wokey, pasar todo a la caché de 1 hora subió el gasto total cerca de un 15–25% neto: las escrituras pasan de 1.25× a 2× el precio de entrada, lo que cuesta más de lo que se ahorra con menos vencimientos. Solo conviene con contextos largos y pausas frecuentes de 5–60 minutos.

¿Cuánto dura la caché de Claude Code?

Cinco minutos por defecto, renovados gratis con cada acierto. CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+) la lleva a una hora, con escrituras de caché a 2× el precio de entrada en lugar de 1.25×.

¿Cambiar de modelo o usar subagentes rompe la caché?

Sí. Cada modelo tiene su propia caché, así que la solicitud después de /model vuelve a leer todo; un subagente normal tiene su propio system prompt y sus herramientas y construye su propia caché, mientras que un fork reutiliza la de la sesión padre.

¿Por qué la cache creation es tan cara?

Las escrituras de caché cuestan 1.25× (5 minutos) o 2× (1 hora) el precio de entrada. La primera solicitud de una conversación larga, y cualquier solicitud después de un cambio de cuenta o un vencimiento, escribe todo el contexto una vez y cuesta claramente más que un turno normal.

¿Funciona la caché cuando Claude Code pasa por un relay?

Sí, si el relay deja pasar cache_control y mantiene la conversación en una sola cuenta upstream. Las versiones anteriores a v2.1.181 con un base URL personalizado necesitan actualizarse o definir CLAUDE_CODE_ATTRIBUTION_HEADER=0.