Claude Code: cómo proteger la caché y gastar menos tokens

Anthropic publicó el 24 de septiembre de 2026 un artículo que parece de contabilidad y que en realidad es otra cosa.

Va de la caché. De por qué una sesión larga de Claude Code cuesta lo que cuesta y de qué han tocado ellos para que cueste menos.

Y de paso sueltan los datos de cómo ha cambiado la forma de trabajar con Claude Code entre marzo y septiembre de este año. Esa parte es la que me ha dejado tonto.

¿Qué es la caché y por qué se lleva la mayor parte de tu factura?

Cuando tienes una conversación larga con Claude, cada vez que le dices algo nuevo el modelo tiene que releerse todo lo anterior. Tu petición de ahora no flota sola. Va pegada a las cincuenta cosas que has hablado antes.

La caché es el apaño para que ese "releerse todo" no se pague a precio completo cada vez. Es lo mismo que ya te conté en qué es el contexto en una IA, solo que mirándolo desde la factura.

Y aquí viene la frase del anuncio que conviene grabarse a fuego: las lecturas de caché son la mayor parte del coste del trabajo con agentes y de programar.

O sea, que lo que te cuesta dinero no es lo que escribes. Es lo que Claude se relee.

Los números de marzo a septiembre

Anthropic ha sacado datos agregados de cómo han estado usando Claude Code entre marzo y septiembre de 2026. El número de prompts por sesión se ha mantenido estable. Lo demás no.

• Claude trabaja 3,3 veces más tiempo en cada prompt, con más de un 40% más de llamadas al modelo por prompt.
• Un 68% menos de interrupciones.
• El contexto por petición se ha multiplicado por 2,6.
• La proporción entre tokens de entrada y de salida ha pasado de 189:1 a 324:1.
• Es el doble de probable que haya un servidor de herramientas conectado o que se use una skill.
• Es un tercio menos probable que alguien pegue texto dentro del prompt.

Léelo otra vez. Mismos prompts por sesión, pero cada prompt hace 3,3 veces más trabajo y se interrumpe un 68% menos.

Eso no es "la gente escribe mejores prompts". Eso es que la gente ha dejado de pegarle texto a mano y ha empezado a conectarle herramientas y skills para que se busque la vida solo. Justo lo que te contaba en por qué los CLI gastan menos tokens que los MCP: el trabajo se ha movido de la ventana de chat al contexto que la máquina se trae sola.

Y una proporción de 324 a 1 entre entrada y salida significa una cosa muy concreta. Que por cada palabra que Claude escribe, se ha leído una montaña. Por eso la caché es donde está el dinero.

Los tres precios que bajan

Estos son los cambios de tarifa que anuncian para quien paga por token, a fecha de septiembre de 2026:

Ese 60% de las lecturas de caché es el que importa, porque es justo el concepto que acaban de decir que se lleva la mayor parte del coste.

Ellos lo resumen así: calculan que Opus 5.5 cuesta alrededor de un 40% menos de ejecutar que Opus 5 en cargas de trabajo típicas facturadas por token. Y añaden que genera respuesta más de un 30% más rápido, que no te ahorra tokens pero sí ratos mirando la pantalla.

También dicen que, a fecha de publicación, un token en caché en Opus 5.5 cuesta una quinta parte de lo que cuesta en los modelos de la competencia. No nombran a ninguno, así que ahí ya decides tú cuánto te lo crees.

De la parte de tarifas y límites ya te hablé cuando subieron los límites de uso de Pro y Max con Opus 5.5. Esto de hoy es lo otro: no cuánto cuesta, sino por qué se te va.

¿Qué han cambiado dentro de Claude Code?

Aquí está la parte que no es de precios y que a mí me parece la buena. Con sesiones más largas y más contexto, lo lógico sería que la caché fallara más. Pues ha pasado lo contrario: el contexto que falla la caché ha bajado más de un 50%.

Y lo han conseguido tapando fugas. Estas son las que nombran:

• Refrescar un login ya no te rompe la caché. Eso es una de esas tonterías que te comían dinero sin que te enteraras.
• Meter instrucciones a mitad de conversación o cargar herramientas sobre la marcha tampoco la rompe como antes.
• En los modelos nuevos, Opus 5.5 y Fable 5.1, puedes cambiar el nivel de esfuerzo a mitad de sesión sin reiniciar la caché.
• Los subagentes bifurcados arrancan desde la caché del padre en lugar de pagar otra vez por el mismo contexto. Si trabajas con subagentes en Claude Code, esto solo ya te cambia la cuenta.
• Quien va con clave de API o proveedor en la nube ya puede poner una vida de caché de una hora. Los de suscripción eso ya lo tenían.

¿Y compensa de verdad cambiar de modelo?

Aquí el anuncio es más honesto de lo que esperaba.

Cuentan el caso de Zeta Labs, que con Opus 5.5 vieron menos turnos y menos llamadas a herramientas por tarea que con Opus 5, a casi la mitad de coste, y completaron el doble de sus tareas más difíciles.

Pero acto seguido meten el matiz. En una tarea bien acotada, los dos modelos terminan más o menos en el mismo número de turnos y lo único que te llevas es la bajada de precio. La diferencia grande aparece en las tareas abiertas, donde un modelo puede tirarse muchos turnos por el camino equivocado. Y rematan diciendo que no hay un número único que valga para todos los proyectos, que lo midas en el tuyo.

Me gusta que lo digan. Un turno que te ahorras sale más rentable que un token cacheado, pero solo te lo ahorras si la tarea daba para perderse.

Los tres hábitos que recomiendan

Del anuncio salen tres cosas concretas que puedes hacer hoy.

Primero, ejecuta /usage dentro de Claude Code y mira qué porcentaje de tu uso son lecturas de caché. Ese número es tu termómetro.

Segundo, elige el modelo al principio de la sesión en vez de cambiarlo a mitad.

Tercero, compacta antes de levantarte de la silla, no después. Y si vas con clave de API o proveedor en la nube, pon la vida de caché de una hora para las sesiones largas.

Todo esto encaja con lo que ya hago para no quedarme sin contexto en un proyecto grande: la caché premia al que planifica la sesión y castiga al que va dando bandazos.

Lo que el anuncio no dice

Un aviso antes de que te emociones.

Las bajadas de precio que cuentan son para el uso facturado por token. Si tú pagas una suscripción Pro o Max, el anuncio no dice cómo se traduce eso en tu caso concreto. Habla de caché, de turnos y de velocidad, y esos sí te tocan, pero los porcentajes de tarifa están puestos para quien paga por token.

Tampoco dan cifras absolutas en este artículo. Dan porcentajes de bajada y un cálculo estimado del 40%. Lo dicen ellos mismos: "estimamos".

Puedes leerlo entero en el blog de Claude.

Yo me quedo con la idea de fondo. Durante dos años la conversación ha sido "qué prompt le pongo". Y resulta que la factura la decide otra cosa: cuánto contexto se relee la máquina y cuántas veces le obligas tú a releerlo desde cero.

Si quieres aprender a usar Claude Code de verdad y no solo a pedirle cosas sueltas, tengo una formación entera sobre ello: crea tu web con Claude Code.