Nota del editor: Muchos usuarios de Claude Code sienten que el consumo de tokens es demasiado rápido y que las conversaciones largas agotan fácilmente el límite. Sin embargo, desde la perspectiva de los ingenieros de Anthropic, lo que realmente afecta el costo no es cuánto código escribiste, sino si el sistema reutiliza continuamente el contexto ya procesado.

El núcleo de este artículo es cómo utilizar un mecanismo de caché para ahorrar Token. El autor reutilizó más de 300 millones de Token mediante caché en una semana, alcanzando un volumen diario de caché de 91 millones. Dado que el costo de los Token en caché es solo el 10% del costo de los Token de entrada normales, esto significa que los 91 millones de Token en caché equivalen aproximadamente a 9 millones de Token normales en términos de facturación. La capacidad de Claude Code para mantener sesiones largas parece más «duradera» no porque el modelo funcione gratuitamente, sino porque se reutilizan con éxito grandes cantidades de contexto repetitivo.

La clave del almacenamiento en caché de indicaciones es «no interrumpir la caché». Claude Code almacena en caché por capas la indicación del sistema, las definiciones de herramientas, CLAUDE.md, las reglas del proyecto y el historial de conversaciones; siempre que el prefijo de las solicitudes posteriores se mantenga consistente, Claude puede leer directamente la caché en lugar de volver a procesar todo el contexto. Anthropic también monitorea internamente la tasa de reutilización de la caché de indicaciones, ya que no solo afecta el límite del usuario, sino que también está directamente relacionada con el costo del servicio del modelo y su eficiencia operativa.

Para usuarios comunes, no es necesario comprender todos los detalles subyacentes; basta con adoptar algunos hábitos clave: no dejar la sesión inactiva por más de 1 hora; realizar correctamente el handoff de sesión al cambiar tareas; evitar cambiar frecuentemente de modelo; y colocar documentos grandes en Projects en lugar de pegarlos repetidamente en la conversación.

Este artículo más que hablar de una técnica para ahorrar tokens, ofrece un enfoque de uso de Claude Code más cercano al pensamiento de un ingeniero: tratar el contexto como gestión de activos, reutilizar continuamente la memoria caché y reducir los cálculos repetitivos en conversaciones largas.

The following is the original text:

Esta semana ahorré 300 millones de tokens, 91 millones en un solo día, más de 300 millones en una semana.

No he modificado ninguna configuración. Esto es simplemente la caché de prompt funcionando normalmente en segundo plano.

Pero cuando realmente entendí qué es el almacenamiento en caché y cómo evitar interrumpirlo, mi sesión duró mucho más con el mismo límite de uso. Por eso, aquí tienes una guía de introducción al 80/20 sobre el almacenamiento en caché de prompts de Claude Code, sin entrar en detalles profundos a nivel de API.

TL;DR

El costo de los tokens en caché es solo el 10% del costo de los tokens de entrada normales. 91 millones de tokens en caché equivalen aproximadamente a 9 millones de tokens facturados.

El TTL de la caché para la versión suscrita de Claude Code es de 1 hora; por defecto, la API es de 5 minutos; los sub-agentes siempre son de 5 minutos.

La caché se divide en tres niveles: nivel del sistema, nivel del proyecto y nivel de la conversación.

Cambiar de modelo durante la sesión interrumpe la caché, incluyendo el modo «opus plan».

¿Cómo se calcula exactamente el costo del almacenamiento en caché?

Cada token almacenado en caché tiene un costo equivalente al 10% de un token de entrada normal.

Entonces, cuando mi panel muestra que 91 millones de tokens se han encontrado en caché en un día, el costo real facturado es aproximadamente equivalente al procesamiento de 9 millones de tokens. Por eso, al usar Claude Code durante mucho tiempo en comparación con no tener caché, parece que las sesiones se extienden casi de forma «gratuita».

En el panel hay dos números que merecen atención especial:

Cache create: Costo único generado al escribir el contenido en la memoria caché. Entrará en funcionamiento en la próxima conversación.
Lectura de caché: Tokens reutilizados desde la caché de Claude, como tus archivos CLAUDE.md, definiciones de herramientas, mensajes anteriores, etc. Es 10 veces más económico que procesarlos nuevamente como entrada.

Si tu número de lecturas de caché es alto, significa que estás aprovechando eficazmente la caché; si este número es bajo, significa que estás pagando repetidamente por el mismo contexto.

Thariq de Anthropic dijo una frase que me impresionó mucho: «En realidad monitoreamos la tasa de aciertos del prompt cache, y cuando la tasa es demasiado baja, se activa una alerta e incluso se declara un incidente de nivel SEV».

También escribió un excelente artículo X. Cuando la tasa de aciertos en la caché es alta, ocurren cuatro cosas simultáneamente: Claude Code se siente más rápido, los costos del servicio de Anthropic disminuyen, tu cuota de suscripción parece más duradera y las sesiones de codificación prolongadas se vuelven más realistas.

Pero si la tasa de aciertos es muy baja, todos saldrán perdiendo.

Entonces, los incentivos de ambas partes son en realidad los mismos: Anthropic quiere que tu tasa de aciertos en la caché sea más alta, y tú también deseas que sea más alta. Lo único que realmente te puede retrasar son algunos hábitos aparentemente insignificantes que reinician la caché silenciosamente.

¿Cómo crece la caché en cada conversación?

The cache relies on prefix matching, that is, "prefix matching".

No necesitas profundizar en detalles técnicos; solo necesitas entender esto: siempre que el contenido anterior a una posición sea idéntico al contenido ya almacenado en caché, Claude puede reutilizar esos tokens en caché.

Una nueva sesión, más o menos así se desarrolla:

Según la documentación de Claude Code, una nueva sesión generalmente se ejecuta así:

Primera conversación: aún no hay caché. El mensaje del sistema, el contexto del proyecto (por ejemplo, CLAUDE.md, memoria, reglas) y tu primer mensaje se volverán a procesar y se guardarán en la caché.

Segunda conversación: Todo el contenido de la primera conversación ya ha sido almacenado en caché. Claude solo necesita procesar tu nueva respuesta y el siguiente mensaje. Este ciclo tendrá un costo mucho más bajo.

Tercera conversación: lógica similar. Las conversaciones anteriores siguen guardadas en la memoria caché; solo se necesita procesar nuevamente la interacción más reciente.

La caché en sí misma puede dividirse en tres niveles:

Artículo de X de Thariq:

Capa del sistema (System layer): incluye instrucciones básicas, definiciones de herramientas (read, write, bash, grep, glob) y estilo de salida. Esta capa está en caché global.

Capa de proyecto (Project layer): incluye CLAUDE.md, memory, reglas del proyecto. Esta capa se almacena en caché por proyecto.

Capa de conversación (Conversation): incluye respuestas y mensajes que crecen con cada ronda de conversación.

Si durante la sesión cambia cualquier contenido a nivel de sistema o de proyecto, todo debe volverse a cachear desde el principio. Esta es la operación más «costosa». Imagínalo: ya has llegado al mensaje 16, y de repente se modifica el prompt del sistema o se detiene la sesión durante una hora; entonces, todos los tokens desde el mensaje 1 deben procesarse nuevamente.

Confusión de 1 hora y 5 minutos

Este es el lugar más fácil de malinterpretar.

Suscripción a Claude Code: el TTL predeterminado es de 1 hora.

Claude API: El TTL predeterminado es de 5 minutos. Puedes pagar un costo mayor para aumentarlo a 1 hora.
Sub-agent bajo cualquier plan: siempre 5 minutos.

Chat en la web de Claude.ai: No hay registro oficial. Podría ser igual que la versión suscrita, pero aún no lo he confirmado.

Hace varios meses, muchas personas se quejaron de que los créditos de suscripción de Claude se agotaban demasiado rápido. En ese momento, algunos creyeron que Anthropic había reducido silenciosamente el TTL de 1 hora a 5 minutos sin notificar a los usuarios. Pero eso no es cierto; el TTL de Claude Code sigue siendo de 1 hora.

El problema es que la documentación de Claude Code y la API están separadas, y como son dos cosas completamente diferentes, esto ha generado mucha confusión.

Si estás ejecutando flujos de trabajo de Sub-agent en gran escala o utilizando directamente la API, entonces el número de 5 minutos es importante. Pero para el 95% de los usuarios de Claude Code, lo que realmente necesitas considerar es solo esa ventana de 1 hora.

Tres hábitos que cubren al 95% de los usuarios

Estas son las partes que considero realmente útiles para el uso diario.

Si has estado inactivo durante más de una hora, el contenido anterior ya ha expirado en la caché. Tu siguiente mensaje volverá a construir la caché. En este caso, en lugar de continuar recuperando una sesión antigua ya «fría», es más económico realizar un cambio claro y comenzar una nueva sesión.

/compact o /clear ya destruyen la caché, así que es mejor aprovechar este momento para reiniciarla realmente.

Creé una habilidad de transferencia de sesión para reemplazar /compact. Resume qué hemos completado, qué decisiones aún están pendientes, qué archivos son más importantes y por dónde deberíamos continuar. Luego ejecuto /clear y pego este resumen, lo que nos permite continuar como si no hubiera habido interrupción.

El comando compact a veces también se ejecuta lentamente. Sin embargo, esta habilidad de handoff generalmente se completa en menos de un minuto.

Claude.ai no ofrece una explicación oficial detallada sobre su mecanismo de caché, pero los Proyectos claramente utilizan una optimización diferente a las conversaciones normales. Por lo tanto, si vas a pegar documentos grandes, es mejor colocarlos dentro de un Proyecto en lugar de insertarlos directamente en la conversación.

¿Qué operaciones destruyen silenciosamente la caché?

Hay algunas cosas que reiniciarán la caché por completo sin advertencia clara.

Cambiar modelo: debido a que la memoria caché depende de la coincidencia de prefijos y cada modelo tiene su propia memoria caché, al cambiar de modelo, la próxima solicitud volverá a leer el historial completo sin ningún acierto en la memoria caché.

Modo «Opus plan»: Esta configuración utiliza Opus durante la fase de planificación y Sonnet durante la fase de ejecución. Lo recomendé anteriormente en algunos videos de optimización de tokens, y hay una razón para ello. Sin embargo, es importante entender que cada cambio de plan equivale a un cambio de modelo, lo que implica la necesidad de volver a construir la caché. A largo plazo, aún así ayuda a extender el límite de sesión, pero debes saber qué ocurre en el nivel subyacente.

Es posible editar CLAUDE.md durante la sesión: este cambio no entrará en vigor inmediatamente, sino que se aplicará en el próximo reinicio. Por lo tanto, la caché actual en ejecución no se verá afectada.

La captura de pantalla que mostré anteriormente proviene de un panel de token.

Este es un repositorio de GitHub muy sencillo. Le das el enlace a Claude Code, y él lo implementa localmente en localhost; así leerá todos tus historiales de sesiones anteriores en lugar de comenzar desde cero. Inmediatamente podrás ver los datos diarios de input, output, cache create y cache read.

Sin embargo, hay un punto a tener en cuenta: este panel estadístico recopila los datos de Token de tu dispositivo local. Si cambias de computadora de escritorio a portátil, los números no serán exactamente los mismos. Cada dispositivo tiene su propia vista estadística.

Resumen

El almacenamiento en caché de indicaciones es algo que se puede investigar profundamente. El artículo de Thariq lo explica de forma más completa; si deseas ver la imagen completa, vale la pena leerlo.

Pero no necesitas comprender todos los detalles para beneficiarte. Solo necesitas dominar el 80/20 más clave: los tokens en caché son 10 veces más baratos que los tokens normales; el TTL de Claude Code es de 1 hora; cambiar el modelo destruye la caché; realizar una transición clara entre tareas suele ser más rentable que continuar usando una sesión antigua hasta que «expire».