Claude Code 1M contexto: context rot y gestión de sesiones

Mi sesión más larga de Claude Code duró 24 días, 8 horas y 46 minutos.

No lo sabía hasta esta mañana. Ejecuté el slash command /usage que Anthropic acaba de sacar y, entre las métricas, apareció ese dato. Junto a él, 578 sesiones en esa cuenta y 88,9M tokens procesados. Sumando las 350 de mi cuenta personal, son 928 sesiones auditadas sin solape entre ellas.

Y lo incómodo: la sesión de 24 días es, literalmente, el ejemplo que Thariq Shihipar pone en el artículo que acaba de publicar el equipo de Claude Code en Anthropic. Un aviso sobre lo que llaman context rot. El artículo se titula Using Claude Code: Session Management & 1M Context y ha cambiado cómo gestiono mis sesiones.

La idea choca: tener 1 millón de tokens de contexto no es un regalo. Cuando el contexto crece, la calidad baja. Si no gestionas sesiones de forma deliberada, Claude Code trabaja peor cuanto más lo usas.

De eso va este artículo. De cómo separar el vibe coding del AI engineering cuando tu herramienta principal es un agente con contexto casi infinito.

/usage: el slash command que te deja medir tus sesiones de Claude Code

Anthropic tiene el slash command /usage dentro de Claude Code. Lo ejecutas dentro de una sesión y te devuelve un panel con tu consumo real: sesiones totales, días activos, racha actual, tokens acumulados, modelo más usado, y la joya del dato — tu sesión más larga.

En mi caso salen casi 1.000 sesiones, unos 140 millones de tokens procesados, Opus 4.6 como modelo más usado, y esa sesión de 24 días, 8 horas y 46 minutos que se quedó abierta no sé muy bien en qué momento. El panel te mete también la racha actual, los días activos del último periodo y lo más y menos usado.

Ejecuta /usage hoy. Te apuesto lo que quieras a que tu sesión más larga te sorprende. A partir de ese número este artículo te va a doler, o a iluminar, según se mire.

Context rot en Claude Code: por qué una sesión larga rinde peor que dos cortas

El concepto que usa el equipo de Claude Code es context rot. Lo definen así:

“Context rot: performance degrades as context grows because attention gets spread across more tokens, and older, irrelevant content starts to distract from the current task.”

Traducción: cuando una sesión crece y crece, el modelo empieza a perderse. La atención es un recurso finito, y cuanto más grande es el contexto menos se fija en lo que importa ahora. Si en la misma sesión hiciste un refactor de autenticación, luego un bug de formularios, luego una migración de base de datos y ahora pides un test unitario, el contexto de todo lo anterior no ayuda. Estorba.

1M de tokens no arregla esto. Lo empeora, porque te da la falsa sensación de que puedes meter todo dentro y seguir tirando.

Aquí conviene separar dos cosas que suelen mezclarse y que no son la misma:

• Context rot es un problema de calidad. Se produce por longitud del contexto. A más tokens acumulados, peor atención del modelo.
• Cache expiry es un problema de coste. Se produce por tiempo. El prompt cache de Anthropic caduca a los 5 minutos de inactividad, da igual si tu sesión es corta o larga.

En mi auditoría sobre optimización de tokens medí lo segundo: el 54% de los turnos perdían cache por pausas de más de 5 minutos. Eso es dinero. Pero no dice nada sobre calidad. El context rot es otro eje, y mucho más difícil de medir porque no hay un contador que te diga “a partir de aquí el modelo responde peor”.

Conviene también un matiz. 1M de tokens sí es útil en escenarios concretos: auditar un repositorio entero de una vez, trabajar sobre un corpus grande cacheado en la primera llamada, prompts one-shot donde metes todo de entrada. El problema no es la capacidad. Es usarla como excusa para no cerrar nunca una sesión.

Las 5 decisiones de gestión de contexto en cada turno

Thariq lo plantea así: en cada turno de tu conversación con Claude Code, implícitamente tomas una decisión entre cinco opciones. La mayoría de devs solo usa una (continuar) y dejan que Claude Code maneje el resto automáticamente. Error.

Las cinco opciones son:

1. Continuar en la misma sesión: lo que haces por defecto. Válido si la tarea sigue siendo la misma.
2. /rewind (o doble Escape): retroceder a un mensaje anterior, normalmente antes de que algo se torciera.
3. /clear: limpiar la sesión y empezar de cero decidiendo manualmente qué conservar como contexto.
4. Compact: dejar que Claude Code resuma la sesión cuando se acerca al límite y siga trabajando con ese resumen.
5. Subagent: delegar una parte ruidosa del trabajo para que no contamine la sesión principal.

La diferencia entre un dev que hace vibe coding y uno que hace AI engineering es que el segundo decide conscientemente cuál de las cinco usa en cada momento.

Compact vs /clear: la trampa del automático

Compact es automático y sucio. /clear es manual y limpio.

Cuando el contexto de tu sesión se acerca al límite, Claude Code te ofrece hacer compact: toma todo lo que hay y lo resume para seguir trabajando. Parece genial. Pero el resumen lo hace el propio modelo, y puede dejar fuera cosas que querías conservar, o arrastrar cosas que ya no necesitas.

Thariq lo dice directamente: /clear te da cero context rot, compact no. Con /clear decides tú qué meter en la nueva sesión (pegando el fragmento que importa, o reabriendo el archivo que necesitas). Compact decide por ti.

Esto no es nuevo en mi flujo. Desde que Anthropic activó la ventana de 1M y empecé a trabajar con Agent Teams en paralelo, ya era obvio que con contexto limpio el modelo trabaja mucho mejor y deja de alucinar. Lo que ha cambiado con el artículo de Thariq es que ahora tengo nombre técnico (context rot) y justificación oficial para algo que ya hacía por intuición. Mi regla firme: antes de llegar al compact automático, cierro la sesión manualmente con /clear y arranco otra con el contexto mínimo que necesito.

Dicho esto, compact tiene un caso donde sí gana. Si estás en una tarea coherente larga, con una línea argumental que cortar rompería (por ejemplo, una depuración donde llevas veinte pasos de hipótesis encadenadas y perder el hilo te obligaría a reconstruirlo), el resumen automático conserva la narrativa mejor de lo que tú vas a reconstruir a mano. En ese caso concreto, acéptalo. En el resto, no.

Si te suena a micro-management de la herramienta, es precisamente el punto. AI engineering es micro-management consciente.

/rewind: corregir a Claude Code sin contaminar el contexto

Esta técnica es la más elegante de todo el artículo de Thariq.

Le pides a Claude Code que refactorice una función, y lo hace mal. Tu reflejo automático es escribir “no, no era eso, quería que X en vez de Y, corrígelo tomando en cuenta que…”. El modelo responde, intenta corregir, a veces acierta, a veces no.

En esa segunda respuesta, el contexto ya incluye tu corrección + su error + tu explicación. Contaminación.

La alternativa:

“Rewind to successful file reads and re-prompt with learnings rather than explaining failures.”

Haces /rewind (o doble Escape) hasta el punto antes de que el modelo se equivocara. Y le vuelves a pedir la tarea desde ahí, pero con la información que aprendiste de por qué falló. Como si nunca hubiera ocurrido.

Llevo un par de días aplicándolo de forma consciente y la diferencia se nota. Menos ping-pong de “no, así no”, más acierto a la primera.

El coste de /rewind que no suele contarse: al retroceder pierdes trabajo real hecho después del punto al que vuelves. Ediciones en archivos, commits, archivos creados. Si el modelo se equivocó en el paso 3 pero en los pasos 4 y 5 escribió código bueno que todavía está en disco, ese código se queda (el retroceso es en el contexto de la conversación, no en el filesystem), pero la conversación ya no “sabe” que existe. Úsalo pronto, cuando el error es fresco y no hay mucho trabajo útil encima.

Subagents para aislar ruido del contexto principal

Esta sección es corta porque ya escribí largo sobre ella. Si leíste mi artículo sobre Agent Teams de Claude Code o la continuación sobre el pipeline de 9 agentes, ya sabes de qué va.

La idea de Thariq: cuando una parte del trabajo va a producir mucho output intermedio que no vas a necesitar después (un grep masivo, una exploración de carpetas enorme, una ronda de verificación automática), delégalo a un subagente. El subagente hace el trabajo y te devuelve el resumen. El ruido se queda fuera de tu sesión principal.

Agent Teams lleva esto al extremo: en vez de un subagente puntual, montas un equipo con roles fijos y el ruido se reparte entre ellos. Cuando lo haces bien, tu sesión principal pasa a ser un panel de control, no un vertedero de contexto.

Subagents es la primera opción que debes considerar cuando veas que una tarea va a llenar tu contexto de basura útil pero irrelevante después.

Mi flujo actual de gestión de sesiones tras casi 1.000 sesiones auditadas

Después de auditar las sesiones y leer el artículo, así trabajo ahora. Algunos puntos son reglas firmes. Otros son hábitos todavía en construcción.

1. Una tarea = una sesión. Antes dejaba que una sesión se alargara dos o tres días mientras saltaba de tema. Ahora si termino un bug y voy a otra cosa, cierro y abro. El momento exacto en que lo decidí: viendo el “24d 8h 46m” en pantalla.

2. /usage cada lunes. Ritual de comienzo de semana. Miro la sesión más larga de los últimos siete días. Si el número me incomoda, me pregunto por qué.

3. /clear antes de que compact salte solo. Cuando noto que la sesión responde peor, cierro. Pego los 2-3 fragmentos de código que necesito y arranco limpio.

4. /rewind antes que “no, así no”.

5. Subagentes para todo lo ruidoso. Cualquier auditoría, verificación o exploración grande se delega. Mi sesión principal queda para decisiones y código final. Muchas de las rutinas diarias que cuento en mis consejos del día a día con Claude Code se aplican tal cual aquí.

6. Para trabajo largo (>4 horas), Agent Teams desde el inicio. No entro en modo maratón con la sesión principal nunca más.

7. Los viernes, revisión con la herramienta de insights. Claude Code tiene una vista de insights que te sugiere ajustes para optimizar tu uso — qué skills estás infrautilizando, qué comandos repites, dónde pierdes tokens. Los viernes por la tarde la abro, anoto una o dos acciones concretas y las aplico la semana siguiente. Es la parte del flujo que más me ha sorprendido: casi siempre encuentra algo.

Con este flujo los números han cambiado. Donde antes necesitaba dos o tres turnos de “no, así no” por tarea de refactor, ahora acierto a la primera en unas 8 de cada 10. El tiempo por tarea ha bajado alrededor de un 30% porque me ahorro el ping-pong de correcciones, y las facturas mensuales se han estabilizado en un rango más estrecho. Son estimaciones — llevo pocas semanas midiendo esto con rigor — pero el cambio es notable.

AI engineering vs vibe coding

Dejo para el final la parte más opinada.

Hay dos formas de usar Claude Code. Vibe coding es dejar que la herramienta corra. Sesiones largas, compact automático, correcciones en conversación, pidiendo al modelo que adivine qué quieres. El contexto crece, la calidad baja, el coste sube, y cuando algo sale mal se culpa al modelo. “Claude está peor esta semana.”

AI engineering es tratar el contexto como un recurso escaso. Decidir conscientemente cuándo abrir y cerrar sesiones, cuándo retroceder, cuándo delegar. Medirse.

Para mí AI engineering son unas cuantas prácticas muy concretas:

1. Medirte con /usage y logs propios. Si no sabes tu sesión más larga, no estás gestionando nada.
2. Decidir conscientemente entre las 5 opciones de contexto en cada turno. Continuar no es la respuesta por defecto — es una de cinco.
3. Tratar el ruido como residuo a delegar. Output intermedio que no necesitas después va a un subagente o a una sesión separada.
4. Documentar decisiones con ADRs. No para enseñárselo al equipo — para que la versión futura de ti mismo, y los agentes que trabajan contigo, entiendan el porqué de cada cosa sin reconstruirlo desde cero.
5. Especificar antes de ejecutar con Spec Driven Development. El prompt no es la unidad de trabajo: la spec lo es. El agente implementa contra una especificación clara, no contra una idea vaga que vas ajustando por conversación.

Sin esto, “AI engineering” es una buzzword. Con ello, es una práctica que se nota en la calidad del output y en la factura. Esta es la misma frontera que dibujé en Cursor vs Claude Code: la herramienta importa menos que cómo la usas.

Lo siguiente que cambiará en Claude Code

1M de tokens no es una mejora. Es más cuerda para que te cuelgues tú solo si no gestionas las sesiones. El artículo de Thariq es una toma de postura del equipo de Claude Code: el contexto infinito no es la solución, la gestión deliberada sí lo es.

Ejecuta /usage. Mira tu sesión más larga. Si el número te incomoda, el problema no es el modelo.

---

P.D.: si estáis probando técnicas de gestión de sesiones distintas o tenéis rutinas que os funcionan, me encontráis en Twitter o por email. Me interesa genuinamente cómo organizáis vuestras sesiones de Claude Code — el espacio de ideas aquí está muy abierto todavía.