Los modelos de IA tienen un límite práctico que no sale en los benchmarks: la degradación de contexto. Cuando una conversación larga o un workflow agentivo se acerca al límite de la ventana de contexto, la calidad del modelo decae antes de que se agoten los tokens. Eso no es un bug — es la física del transformer. La compactación de contexto es la respuesta de la industria a ese problema.
Un thread reciente del desarrollador @jlehman_ describe el patrón “lossless-claw”: sesiones de agente que alcanzan tasas de caché del 90–94% gracias a resúmenes de contexto que se comprimen incrementalmente. El resultado práctico es que el modelo casi nunca opera sobre más de 80k tokens antes de volver a reducirse a 30–40k. Menos contexto activo = más rápido, más barato, y según los datos, mejor.
¿Qué es la compactación de contexto y por qué importa ahora?
Anthropic introdujo su API de compactación en enero de 2026 (beta, disponible en Claude Opus 4.6 y Sonnet 4.6). El mecanismo es simple: cuando la conversación supera un umbral configurable (por ejemplo 150k tokens), el modelo genera automáticamente un resumen del historial anterior, lo encapsula en un bloque especial, y reemplaza el historial completo con ese resumen comprimido.
IA para el Resto de Nosotros
La nueva versión de mi curso estrella para aprender a usar la IA de forma práctica, simple y útil en tu día a día. Comienza el 24 de marzo.
→ Inscríbete hoy 🚀La crítica obvia: “¿no se pierde contexto?”. Sí, algo se pierde. Pero el tradeoff es más sutil de lo que parece. Anthropic llama al fenómeno context rot — la degradación de rendimiento que ocurre cuando el modelo tiene que “prestar atención” a cientos de miles de tokens de historia, la mayoría irrelevante para la tarea actual. El MRCR v2 benchmark (multi-needle retrieval a 1M tokens) muestra que Claude Opus 4.6 alcanza 76% de precisión — contra 18.5% de Sonnet 4.5. Cuatro veces mejor. Pero esa mejora viene precisamente porque el modelo ha aprendido a gestionar lo que es relevante, no a retener todo.
El problema de las sesiones largas en agentes reales
El patrón descrito por @jlehman_ no es una curiosidad de power-user — es el modelo de uso típico en agentes de código como Cursor Automations o en flujos agenticos donde Claude opera en sesiones de 60–90 minutos resolviendo tareas complejas.
El problema clásico era “amnesia al final de la sesión”: el agente llegaba al límite, todo se perdía, había que empezar desde cero. Claude Code tenía ese comportamiento desde su lanzamiento en febrero 2025, con la compactación automática activándose alrededor de los 90 minutos sin aviso previo. Para proyectos donde el agente había “aprendido” las preferencias del usuario durante 30 turnos, eso era catastrófico.
La solución no es solo “más contexto”. Extender la ventana a 1M tokens (disponible en beta para Opus 4.6 y Sonnet 4.6) ayuda, pero no elimina el problema de context rot. La compactación incremental, diseñada como parte de la arquitectura del agente, es la respuesta real.
¿Qué hace exactamente el patrón “lossless”?
El nombre es aspiracional más que literal. “Lossless” en este contexto significa que los resúmenes preservan los elementos que importan para continuar la tarea: decisiones tomadas, archivos en progreso, preferencias del usuario, estado de herramientas. Lo que se descarta es el ruido: intentos fallidos, exploraciones abandonadas, historial de mensajes de sistema repetitivo.
La eficiencia de caché (90–94%) viene de que el prompt siempre empieza por el mismo bloque de contexto compacto — y los LLMs pueden reutilizar los cálculos ya hechos sobre ese bloque si no cambió. Anthropic usa prompt caching a nivel de prefijo: si el contexto base no cambia, el modelo no necesita recomputarlo en cada llamada. El ahorro es real y medible en producción.
Para proyectos que hacen docenas o cientos de llamadas a la API en una sesión de agente, esto es la diferencia entre viabilidad económica y no serlo.
Por qué importa para los builders
La tendencia de 2026 es clara: los agentes de IA dejan de ser herramientas puntuales y pasan a ser procesos que corren en el tiempo. Claude Cowork ya permite gestionar archivos a lo largo de sesiones extendidas; los sistemas de coding como Cursor, Windsurf y Void dependen de mantener estado coherente entre llamadas.
En ese escenario, el diseño del contexto se vuelve ingeniería real. No alcanza con elegir el modelo más grande — hay que decidir: ¿cuándo comprimir?, ¿qué preservar?, ¿qué umbral configurar en la Compaction API? El developer que lo haga bien tendrá agentes que mejoran con el tiempo en lugar de degradarse.
El framing habitual es “más tokens = mejor”. La evidencia apunta a lo contrario: el contexto más útil no es el más grande, sino el más relevante. Ese principio — no el benchmark de 1M tokens — es el que va a definir cómo se construyen los agentes útiles de aquí en adelante.
