↔️ Dos ejes diferentes
Caché optimiza el precio por token del contexto. Compactar optimiza cuántos tokens tú cargas. Son dos ejes que no compiten en el mismo lugar, y por eso quieres ambos.
Compactar = resumir el historial en una versión más corta; en Claude Code, el comando es /compact. No cambia el precio por token; cambia el tamaño de lo que vuelves a enviar.
Leyenda: la caché solo baja (precio); la compactación solo avanza hacia la izquierda (cantidad). Una no hace el trabajo de la otra.
Cambia el precio por token
Cambia la cantidad de tokens
Resume el historial en Claude Code
Ejes ortogonales, no rivales
💰 Un contexto grande cacheado sigue siendo caro
El descuento de la caché engaña. La caché abarata por token, pero 400k tokens leídos a 0,1× todavía equivalen a ~40k de input completo por turno, y eso cada turno, mientras el contexto siga teniendo este tamaño.
El cálculo que asusta
400.000 tokens × 0,1× = 40.000 tokens equivalentes de input completo, pagados en cada mensaje. El hit alto (99%) no cambia eso: el volumen es grande.
× cada turno de la conversación = suma que crece sin parar
Leyenda: una décima parte de mucho sigue siendo mucho. La caché reduce el precio; no achica el contexto.
Lee la suma, no el campo
Si input_tokens muestra poco, pero el cálculo dio alto; la mayor parte está en cache_read_input_tokens a 0,1×. Es barato por token, pero el total del prompt es la suma de los tres campos.
El factor de lectura de la caché
400k leídos, en cada turno
El costo se repite, no desaparece
Barato ≠ pequeño
🧱 El límite del contexto (1M)
Aquí el caché no ayuda. Deja 900k tokens baratos, pero todavía ocupan 900k de 1M. En algún momento no puedes continuar la conversación sin compactar o /clear. El límite se refiere a la cantidad, y solo compactar/limpiar libera espacio.
Leyenda: barato ≠ pequeño. El límite de 1M cuenta lugares ocupados, no el precio: solo compactar abre espacio.
El error común
Confiar en que el caché "aguante" un contexto que solo crece. Mantiene bajo el costo, no el tamaño. Cerca del límite, la conversación se traba, y entonces es /compact o /clear, ya no más caché.
Límite de lugares en la ventana
La caché no libera espacio
Reduce la ocupación
Se reinicia cuando ya no necesitas el historial
📉 Las cifras de la compactación
Compactar cambia un write frío único por turnos mucho más ligeros. Sin compactar, pagas el contexto grande cada mensaje. Al compactar, pagas una sola escritura y todos los turnos siguientes salen baratos. Compara los cálculos lado a lado.
| Escenario | Costo inicial (una vez) | Costo por turno | Payback |
|---|---|---|---|
| Sin compactar 400k en el contexto |
— | 400k @ 0,1× ≈ 40k-equiv · para siempre | nunca mejora |
| Compactando para 20k |
1 write en frío 20k @ 1,25× ≈ 25k | 20k @ 0,1× ≈ 2k-equiv · por turno | ~1 turno |
Leyenda: el único pico cian (turno 0) es la escritura en frío de la compactación; después de él, cada turno es ~20× más ligero que la barra morada.
Consejo práctico
Piensa en los turnos que vienen: si aún faltan muchos mensajes, la escritura fría de 25k se diluye y queda en nada frente a ahorrar 38k por turno. Si la conversación termina ahora, la escritura fría no compensa.
20k @ 1,25× ≈ 25k, una vez
Después de compactar
Payback
Más ligero por turno
🧠 Calidad y latencia
Compactar no es solo cuestión de costo. Un contexto inflado dispersa la atención del modelo (el "context rot") — se equivoca y da más rodeos. E incluso leído desde el caché, 400k tardan más que 20k para el primer token (TTFT mayor). Compactar mejora la precisión e velocidad.
Leyenda: menos tokens = atención concentrada + primer token más rápido. Compactar es una mejora de calidad, no solo de costos.
✓ Contexto compacto
- ✓Atención concentrada en lo que importa
- ✓Menos «context rot», menos errores
- ✓Primer token más rápido (TTFT menor)
✗ Contexto inflado
- ✗Atención dispersa, respuestas que dan vueltas
- ✗Errores por perder el hilo de lo que importa
- ✗Más lento incluso leído de la caché
Atención demasiado dispersa
Tiempo hasta el 1.er token
Leído, pero todavía grande
Precisión + velocidad
🎯 Cuándo compactar / cuándo NO
El criterio es simple. Conversación pequeña → NO compactes: simplemente pierdes el caché caliente sin obtener ningún beneficio (esa intuición es correcta). Contexto grande, cerca del límite o con la calidad en descenso → compacta: cambias 1 write en frío por turnos mucho más ligeros.
Leyenda: la rama verde conserva la caché; la rama morado acepta 1 write en frío para ganar en todos los turnos siguientes.
✓ Compacta cuando
- ✓El contexto es grande y aún faltan muchos turnos
- ✓Estás cerca del límite de 1M
- ✓La calidad bajó / el modelo está dando vueltas
✗ No compactes cuando
- ✗La conversación es corta y el caché ya está caliente
- ✗Está por terminar (no hay turnos para amortizar la escritura en frío)
- ✗Por costumbre, sin revisar el tamaño ni la calidad
Regla práctica
Compacta por estado (tamaño, límite, calidad), no por reloj. Y recuerda: la caché y la compactación trabajan juntas; después de compactar, el nuevo contexto pequeño también se guarda en caché y vuelve a estar activo.
Conserva el caché caliente
Turnos mucho más ligeros
No por costumbre
Compacto también se guarda en caché
Resumen del módulo
/clear libera espacio.Siguiente módulo
3.2 — Arquitectura pro caché y auditoría: diseñar el prefijo para que nunca se invalide por accidente.