Título original: How Anthropic Engineers Actually Save Tokens
Autor original: Nate Herk
Traducción: Peggy, BlockBeats

Prólogo del editor: Muchas personas al usar Claude Code tienen la sensación más inmediata de que el consumo de tokens es demasiado rápido y que las sesiones largas fácilmente agotan el límite. Pero desde la perspectiva de los ingenieros de Anthropic, lo que realmente afecta el costo no suele ser cuánto código escribes, sino si el sistema puede reutilizar continuamente el contexto ya procesado.

El núcleo de este artículo es cómo ahorrar tokens mediante mecanismos de caché. El autor ha reutilizado más de 300 millones de tokens en una semana a través de caché, alcanzando un máximo de 91 millones en un solo día. Dado que el costo de caché de tokens es solo el 10% del de los tokens de entrada normales, esto significa que 91 millones de tokens en caché equivalen en realidad a aproximadamente 9 millones de tokens en facturación. La razón por la que las sesiones largas con Claude Code parecen más «duraderas» no es porque el modelo funcione gratis, sino porque una gran cantidad de contextos repetidos se reutilizan con éxito.

La clave del prompt caching es «no interrumpir la caché». Claude Code almacena en capas las instrucciones del sistema, definiciones de herramientas, CLAUDE.md, reglas del proyecto y diálogos históricos; siempre que el prefijo de la solicitud posterior se mantenga consistente, Claude puede leer directamente la caché en lugar de volver a procesar todo el contexto. Internamente, Anthropic también monitorea la tasa de reutilización del prompt cache, ya que no solo afecta el límite del usuario, sino que también influye directamente en los costos del servicio del modelo y en la eficiencia operativa.

Para los usuarios comunes, no es necesario entender todos los detalles subyacentes, solo dominar algunos hábitos clave: no dejar que la sesión quede inactiva por más de una hora; hacer una transferencia clara de sesión al cambiar de tarea; evitar cambiar de modelo con frecuencia; y en documentos largos, preferir guardarlos en Projects en lugar de pegarlos repetidamente en el diálogo.

Este artículo, más que ofrecer un truco para ahorrar tokens, propone un método de uso de Claude Code con una mentalidad más cercana a la ingeniería: tratar el contexto como un activo, mantener la caché en uso continuo, y reducir los cálculos repetidos en sesiones largas.

A continuación, el texto original:

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

No he cambiado ninguna configuración. Solo es que el prompt caching funciona normalmente en segundo plano.

Pero cuando realmente entendí qué es la caché y cómo evitar «interrumpirla», en el mismo límite de uso, mis sesiones pueden durar más tiempo. Por eso, aquí comparto una guía de introducción al prompt caching en Claude Code, enfocada en el 80/20, sin profundizar en detalles de la API.

TL;DR

El costo de caché de tokens es solo el 10% del de los tokens de entrada normales. 91 millones de tokens en caché, en realidad, equivalen a unos 9 millones de tokens en facturación.

La versión suscrita de Claude Code tiene un TTL de caché de 1 hora; la API por defecto, 5 minutos; y el Sub-agent siempre, 5 minutos.

La caché se divide en tres capas: capa del sistema, capa del proyecto y capa del diálogo.

Cambiar de modelo en medio de una sesión rompe la caché, incluyendo activar el modo «opus plan».

¿Cómo se calcula el costo de la caché?

Cada token en caché cuesta solo el 10% del de un token de entrada normal.

Por eso, cuando en mi panel de control aparece que un día se usaron 91 millones de tokens en caché, en realidad, la facturación equivale a unos 9 millones de tokens. Esto explica por qué, en uso prolongado de Claude Code sin caché, la sesión parece casi «gratuita» y se puede extender mucho más.

En el panel, hay dos números que vale la pena destacar:

Cache create: costo único al escribir contenido en la caché. Comienza a usarse en la siguiente interacción.
Cache read: tokens reutilizados por Claude desde la caché, como tu CLAUDE.md, definiciones de herramientas, mensajes anteriores, etc. Comparado con volver a procesarlos como entrada, cuesta 10 veces menos.

Si tu número de Cache read es alto, indica que estás aprovechando eficazmente la caché; si 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; si esta tasa es demasiado baja, activamos alertas, e incluso podemos declarar una emergencia de nivel SEV.»

También escribió un buen artículo en X. Cuando la tasa de aciertos del caché es alta, suceden simultáneamente cuatro cosas: Claude Code se siente más rápido, los costos de servicio de Anthropic bajan, tu límite de suscripción dura más y las sesiones largas de codificación se vuelven más factibles.

Pero si la tasa de aciertos es baja, todos salen perdiendo.

Por eso, los incentivos de ambas partes son en realidad iguales: Anthropic quiere que tu tasa de aciertos sea más alta, y tú también quieres que sea así. Lo que realmente puede retrasar el proceso son pequeños hábitos que parecen insignificantes pero que silenciosamente reinician la caché.

¿Cómo crece la caché en cada ronda de diálogo?

La caché depende del «prefix matching», es decir, «coincidencia de prefijos».

No necesitas profundizar en detalles técnicos; solo entender que: mientras el contenido antes de cierta posición sea exactamente igual al contenido en caché, Claude puede reutilizar esa parte de tokens.

Una sesión completamente nueva generalmente funciona así:

Según la documentación de Claude Code, una sesión nueva suele seguir este flujo:

Primera ronda: no hay caché todavía. Las instrucciones del sistema, el contexto del proyecto (como CLAUDE.md, memoria, reglas), y tu primer mensaje, se vuelven a procesar y se almacenan en caché.

Segunda ronda: todo lo de la primera ronda ya está en caché. Claude solo necesita procesar tu nueva respuesta y el siguiente mensaje. El costo de esta ronda será mucho menor.

Tercera ronda: igual. La conversación previa permanece en caché, solo la interacción más reciente requiere procesamiento.

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

De un artículo de Thariq en X:

Capa del sistema (System layer): incluye instrucciones básicas, definiciones de herramientas (read, write, bash, grep, glob) y estilos de salida. Es la caché global.

Capa del proyecto (Project layer): incluye CLAUDE.md, memoria, reglas del proyecto. Se cachea por proyecto.

Capa del diálogo (Conversation): incluye respuestas y mensajes, que crecen con cada ronda.

Si en medio de la sesión, cambian contenidos en la capa del sistema o del proyecto, todo debe volver a cachearse desde cero. Esa es la operación más «costosa». Imagina: ya llevas 16 mensajes, y de repente cambias las instrucciones del sistema o pasas una hora sin interactuar; entonces, todos los tokens desde el primero deben volver a procesarse.

Confusión entre 1 hora y 5 minutos

Este es el punto más fácil de malentender.

Claude Code suscripción: TTL por defecto de 1 hora.

API de Claude: TTL por defecto de 5 minutos. Puedes pagar más para aumentarlo a 1 hora.
Cualquier plan de Sub-agent: siempre 5 minutos.

Chat en la web de Claude.ai: no hay una documentación oficial clara. Podría ser igual que la suscripción, pero no lo he confirmado.

Hace unos meses, muchos se quejaron de que el límite de uso de Claude se agotaba muy rápido. Algunos pensaron que Anthropic había reducido silenciosamente el TTL de 1 hora a 5 minutos sin notificación. Pero no, el TTL de Claude Code sigue siendo 1 hora.

El problema es que la documentación de Claude Code y la API están separadas, y en realidad son cosas completamente distintas, lo que genera confusión.

Si usas mucho Sub-agent o la API directamente, ese número de 5 minutos importa mucho. Pero para el 95% de usuarios de Claude Code, lo que realmente importa es esa ventana de 1 hora.

Tres hábitos para cubrir al 95%

Estas son las prácticas que considero realmente útiles en el uso diario.

No pauses demasiado tiempo

Si dejas la sesión inactiva por más de una hora, la mayoría del contenido en caché ya habrá expirado. La próxima respuesta que envíes reconstruirá la caché. En ese caso, en lugar de continuar con una sesión «enfriada», es mejor hacer una transferencia clara y comenzar una nueva, que suele ser más económica.

Al cambiar de tarea, simplemente reinicia

/compact o /clear ya rompen la caché, así que es mejor usarlos en ese momento para resetearla.

Yo mismo desarrollé una técnica de transferencia de sesión, para reemplazar /compact. Resume lo que hemos hecho, las decisiones pendientes, los archivos más importantes y dónde continuar. Luego, ejecuto /clear y pego ese resumen, y puedo seguir sin interrupciones aparentes.

A veces, el comando compact funciona lentamente. Esta técnica de transferencia suele completarse en menos de un minuto.

En el chat de Claude, para documentos largos, mejor guardarlos en Projects

El mecanismo de caché en Claude.ai no está muy documentado oficialmente, pero Projects claramente usa una optimización diferente a los diálogos normales. Por eso, si quieres pegar documentos muy grandes, es mejor ponerlo en un Project, no en el diálogo.

¿Qué acciones pueden romper la caché sin aviso?

Varias cosas pueden reiniciar toda la caché sin aviso previo.

Cambio de modelo: porque la caché depende del prefijo, y cada modelo tiene su propia caché. Al cambiar de modelo, la próxima solicitud no tendrá caché y se leerá todo el historial desde cero.

Modo «Opus plan»: este modo usa Opus en la planificación y Sonnet en la ejecución. Lo recomendé en algunos videos de optimización de tokens, y tiene su razón. Pero hay que entender que cada cambio de plan en realidad es un cambio de modelo, que requiere reconstruir la caché. A largo plazo, ayuda a extender el límite, pero es importante entender qué pasa en el fondo.

Editar CLAUDE.md en medio de la sesión es posible: ese cambio no se aplica inmediatamente, sino en el próximo reinicio. La caché en curso no se ve afectada.

Mi panel de tokens gratuito

La captura que mostré antes proviene de un panel de control de tokens local.

https://github.com/nateherkai/token-dashboard

Es un repositorio simple en GitHub. Le das el enlace a Claude Code, y él despliega localmente en localhost, leyendo todos tus diálogos pasados en lugar de empezar desde cero. Así, puedes ver datos diarios de input, output, creación de caché y lectura de caché.

Pero ojo: ese panel solo muestra datos en tu dispositivo local. Si cambias de PC a portátil, los números no coincidirán exactamente. Cada dispositivo tiene su propia vista de estadísticas.

Resumen

El prompt caching es un tema muy profundo. La publicación de Thariq es más completa, si quieres una visión global, vale la pena leerla.

Pero no necesitas entender todos los detalles para beneficiarte. Solo dominar el 80/20: la caché de tokens cuesta 10 veces menos que los tokens normales; el TTL de Claude Code es 1 hora; cambiar de modelo rompe la caché; y hacer transferencias claras entre tareas suele ser más barato que dejar que una sesión vieja «expira» y seguir usándola.

[Enlace al original]

Haz clic para conocer las vacantes en Rhythm BlockBeats

Únete a la comunidad oficial de Rhythm BlockBeats:

Telegram suscripción: https://t.me/theblockbeats

Telegram grupo: https://t.me/BlockBeats_App

Cuenta oficial en Twitter: https://twitter.com/BlockBeatsAsia