Recorta tokens del agente sin romper tu cache hit rate

TL;DR: La factura de tu agente de código no la fija el precio por token, la fija tu cache hit rate. Comprimir el output de comandos (con un proxy tipo rtk o un hook) ahorra tokens sin riesgo porque toca la cola volátil del contexto. Reescribir el prefijo estable (system prompt, CLAUDE.md a mitad de sesión, reordenar el historial) invalida la caché de prompts, y un cache miss cuesta hasta 12,5 veces más que un hit. Aquí tienes la tabla de palancas, el árbol de decisión y qué mirar en /cost.

El instinto: instalo rtk y ya ahorro

Ves la factura del agente subir, alguien menciona que rtk reduce el consumo de tokens un 60-90% y ya tienes el dedo encima del brew install. Bien. Pero si tu plan mental es "recorto todo lo que pueda del contexto y cuanto menos texto viaje, menos pago", vas a optimizar la palanca equivocada y, en el peor caso, a subir la factura mientras crees que la bajas.

El motivo es técnico y concreto: no todos los tokens de entrada cuestan lo mismo. Un token que se reprocesa desde cero cuesta el precio de entrada completo. Uno que se recupera de la caché de prompts cuesta la décima parte. Según la documentación de prompt caching de Anthropic, un cache read se factura a 0,1x del precio base de entrada, un cache write de 5 minutos a 1,25x y uno de 1 hora a 2x. Traducido: cachear no es un detalle de infra, es la variable que decide tu gasto.

El cache hit rate es el porcentaje de tokens de entrada que tu agente recupera de la caché en lugar de reprocesar; como un hit cuesta el 10% del precio de entrada, ese ratio, y no el precio por token, decide tu factura mensual.

Por qué el recorte agresivo puede salir caro

Claude Code y la mayoría de CLIs de código reenvían un prefijo estable en cada turno: system prompt, tu CLAUDE.md, instrucciones, historial temprano. Ese prefijo es exactamente lo que se cachea. Y el cache exige coincidencia exacta del prefijo: si modificas aunque sea una coma antes del último bloque marcado con cache_control, no hay hit y toca reescribir toda la caché desde ese punto.

Haz la cuenta con Opus 4.8 (5 $/MTok de entrada). Un cache read sale a 0,50 $/MTok; reestablecer esa caché con un write de 5 minutos, a 6,25 $/MTok. Eso son 12,5 veces más caro por los mismos tokens. Si tu "optimización" consiste en resumir el historial o reordenar mensajes a mitad de sesión para ahorrar 300 tokens, y al hacerlo invalidas un prefijo cacheado de 25.000 tokens, acabas de cambiar un ahorro de céntimos por un recargo de varios euros repetido en cada turno posterior.

La distinción que casi nadie hace: recortar hacia la cola es seguro, reescribir hacia la cabeza es caro. rtk no rompe nada porque comprime el output de los comandos (un cargo test de 155 líneas reducido a 3) que entra al final del contexto. El peligro no es rtk: es la compactación manual del prefijo estable.

La regla de decisión y las tres palancas

La regla, mojada: comprime todo lo que viva en la cola volátil del contexto y no toques nunca el prefijo cacheado. Si el texto que ibas a recortar está antes del último punto de caché, déjalo; lo que ahorras en tokens lo pagas multiplicado en cache misses.

Palanca	Qué toca	Impacto en factura	Riesgo
Comprimir output de tools (rtk, hook de Bash)	Cola volátil (resultados de git, tests, logs)	Medio-alto	Bajo: no toca la caché. Vigila que no borre la línea de error que importa
Maximizar cache hit rate (prefijo estable)	System prompt, CLAUDE.md, historial temprano	Alto	Romperlo cuesta hasta 12,5x. No edites CLAUDE.md ni reordenes a mitad de sesión
Compactación agresiva del historial (auto-compact, resumir)	Todo el contexto, incluido el prefijo	Alto en tokens brutos	Alto: invalida caché y puede perder contexto, degradando correctness
Enrutar por modelo (Haiku 4.5 para tareas triviales)	La petición entera	Alto en tareas simples	Bajo si evalúas: Haiku a 1 $/MTok vs Opus a 5 $/MTok

Árbol de decisión rápido

• ¿El texto está antes del último bloque de caché? No lo toques. Recortarlo rompe el hit.
• ¿Es output volátil de un comando o tool? Comprímelo con rtk o un hook. Suma seguro.
• ¿Estás cruzando los 200.000 tokens de entrada? El problema ya no es el recorte de output: por encima de ese umbral se disparan las tarifas de contexto largo. Ahí toca dividir la tarea o dar memoria persistente al agente sin inflar el contexto, no exprimir un git status.

Cómo medir tu gasto real (antes de tocar nada)

No optimices a ciegas. En Claude Code, /cost desglosa cache read, cache creation e input por sesión. La señal que importa:

• Cache read debe dominar sobre cache creation. Si la creación de caché sube turno a turno en vez de estabilizarse, algo está invalidando tu prefijo (probablemente una edición o un reordenamiento).
• Compara antes/después. rtk expone rtk gain para ver el ahorro real de output. Un número concreto vale más que la sensación de "va más ligero".
• Blinda correctness. Todo recorte es una apuesta a que no borras nada útil. Pasa un eval mínimo en producción con y sin compresión antes de dejarlo fijo. Si el agente empieza a pedir el mismo comando dos veces porque la salida comprimida le quitó contexto, has ahorrado tokens y perdido dinero en reintentos.

Cuándo NO aplica

Esta lección es sobre facturación por token, así que hay contextos donde no se sostiene:

• Suscripción plana (Claude Pro/Max). Si pagas 20 $ fijos no facturas por token; ahí rtk no te ahorra euros, te alarga sesiones y te aleja del rate limit. El cálculo de 12,5x deja de importar.
• Tareas cortas de una sola pasada. Un cache de 5 minutos no se amortiza si no repites el prefijo. No te compliques con caching manual para un one-shot.
• Tu cuello de botella es el output. El prompt caching no toca los tokens de salida. Si generas respuestas largas, la palanca no es cachear sino elegir el modelo por coste real y ajustar el nivel de esfuerzo.

Y un matiz sobre agentes de larga duración: en tareas de horas, la tentación de compactar el historial es enorme, pero es justo cuando más caro sale romper la caché. Ahí la respuesta es gestionar el estado fuera del contexto, no aplastarlo dentro. Es el mismo problema de fondo que hace que los agentes long-horizon se pierdan en tareas largas.

Preguntas frecuentes

¿rtk rompe el cache hit rate de Claude Code?

No, porque comprime el output de comandos que entra al final del contexto, no el prefijo estable que se cachea. El hook de rtk solo actúa sobre llamadas de la herramienta Bash; el system prompt y tu CLAUDE.md quedan intactos, así que los cache hits se mantienen. El riesgo de romper la caché viene de reescribir manualmente el prefijo, no de rtk.

¿Cuánto ahorro de verdad con prompt caching?

Un cache read cuesta 0,1x el precio de entrada base, así que un prefijo repetido baja un 90% en la parte cacheada. Con un 70% de cache hit rate, la mayoría de tus tokens reenviados cuestan una décima parte. El caching se amortiza tras un solo hit con el cache de 5 minutos, o dos hits con el de 1 hora.

¿Qué miro primero para bajar la factura de mi agente?

El cache hit rate en /cost, no el precio por token del modelo. Si tu cache creation crece cada turno, estás invalidando el prefijo y pagando writes repetidos: eso pesa más que cualquier compresión de output. Estabiliza el prefijo primero, comprime la cola después.

El takeaway

La factura de un agente de código se decide en un sitio contraintuitivo: no en el precio por token que anuncia el modelo, sino en qué porcentaje de tu contexto viaja por la vía barata de la caché. Recortar output volátil es dinero gratis. Reescribir el prefijo estable para ahorrar unos tokens es cambiar céntimos por euros, turno tras turno. La pregunta útil no es "¿cómo mando menos texto?", sino "¿qué de lo que mando puedo recuperar de la caché en vez de reprocesar?".