Gestión de la ventana de contexto: Lo que 50 sesiones me enseñaron sobre el desarrollo con IA

Medí el consumo de tokens en 50 sesiones de desarrollo con Claude Code. El patrón fue consistente: la calidad del resultado se degrada aproximadamente al 60% de utilización del contexto, mucho antes de que el límite duro active la compactación.¹

TL;DR

El agotamiento de la ventana de contexto degrada silenciosamente la calidad de la programación con IA. Después de rastrear 50 sesiones construyendo mi infraestructura de Claude Code y sistema de calidad del blog, encontré tres patrones que mantienen la calidad del resultado durante sesiones de varias horas: compactación proactiva después de cada subtarea, memoria basada en el sistema de archivos que persiste a través de los límites del contexto, y delegación a subagentes que mantiene el contexto principal ligero. La idea clave: trate la ventana de contexto como un recurso escaso, no como un hilo de conversación sin fondo.

Cómo se ve realmente la degradación

Cada lectura de archivo, salida de herramienta y turno de conversación consume tokens. Una sola lectura de un archivo grande (2.000 líneas) puede consumir entre 15.000 y 20.000 tokens. Después de leer 10 archivos y ejecutar varios comandos, la ventana de contexto contiene más salidas de herramientas que instrucciones reales.²

La degradación es sutil. Claude no anuncia “mi contexto está al 80%.” En su lugar, el modelo comienza a: - Olvidar instrucciones anteriores establecidas hace 20 minutos - Repetir sugerencias ya rechazadas tres turnos antes - Pasar por alto patrones establecidos anteriormente en la conversación - Producir cambios multi-archivo menos coherentes

Noté este patrón mientras construía mi sistema de deliberación. Una sesión que comenzó con ediciones multi-archivo precisas en 8 módulos de Python se degradó a una visión de túnel en un solo archivo para la marca de los 90 minutos. El agente dejó de hacer referencia a la arquitectura que había leído antes porque ese contexto había sido comprimido.

Estrategia 1: Compactación proactiva

El comando /compact de Claude Code resume la conversación y libera espacio de contexto. El sistema preserva las decisiones clave, el contenido de los archivos y el estado de la tarea mientras descarta la salida verbosa de las herramientas.³

Cuándo compactar: - Después de completar una subtarea distinta (función implementada, error corregido) - Antes de comenzar una nueva área del código base - Cuando Claude comience a repetirse u olvidar contexto anterior

Compacto aproximadamente cada 25-30 minutos durante sesiones intensivas. Durante la construcción de la infraestructura de deliberación (9 PRDs, 3.455 líneas de Python), compacté después de completar cada PRD. Cada compactación preservó las decisiones arquitectónicas mientras liberaba contexto para la siguiente fase de implementación.

Estrategia 2: El sistema de archivos como memoria

La memoria más confiable a través de los límites del contexto reside en el sistema de archivos. Claude Code lee CLAUDE.md y los archivos de memoria al inicio de cada sesión y después de cada compactación.⁴

Mi directorio .claude/ sirve como un palacio de la memoria estructurado:

~/.claude/
├── configs/           # 14 JSON configs (thresholds, rules, budgets)
│   ├── deliberation-config.json
│   ├── recursion-limits.json
│   └── consensus-profiles.json
├── hooks/             # 95 lifecycle event handlers
├── skills/            # 44 reusable knowledge modules
├── state/             # Runtime state (recursion depth, agent lineage)
├── handoffs/          # 49 multi-session context documents
├── docs/              # 40+ system documentation files
└── projects/          # Per-project memory directories
    └── {project}/memory/
        └── MEMORY.md  # Always loaded into context

El archivo MEMORY.md captura errores, decisiones y patrones a través de las sesiones. Actualmente contiene 54 fallas documentadas con patrones de aprendizaje entre dominios. Cuando descubro que ((VAR++)) falla con set -e en bash cuando VAR es 0, lo registro. Tres sesiones después, cuando encuentro un caso límite similar con enteros en Python, la entrada de MEMORY.md revela el patrón.⁵

El efecto compuesto entre dominios: Un error de escape en bash durante el desarrollo de hooks informó una mejora de regex en mi linter de blog en Python. Un vacío en los tokens de CSS (--spacing-2xs no existe) desencadenó una auditoría sistemática de todas las referencias a propiedades personalizadas. Cada entrada conecta dominios que de otro modo permanecerían aislados dentro de los contextos de sesiones individuales.

Estrategia 3: Traspaso de sesión

Para tareas que abarcan múltiples sesiones, creo documentos de traspaso que capturan el estado completo:

## Handoff: Deliberation Infrastructure PRD-7
**Status:** Hook wiring complete, 81 Python unit tests passing
**Files changed:** hooks/post-deliberation.sh, hooks/deliberation-pride-check.sh
**Decision:** Placed post-deliberation in PostToolUse:Task, pride-check in Stop
**Blocked:** Spawn budget model needs inheritance instead of depth increment
**Next:** PRD-8 integration tests in tests/test_deliberation_lib.py

Mi directorio ~/.claude/handoffs/ contiene 49 documentos de traspaso de tareas multi-sesión. Iniciar una nueva sesión con claude -c (continuar) o leer el documento de traspaso proporciona a la sesión sucesora el contexto completo con un costo mínimo de tokens.⁶

El patrón de traspaso me salvó durante la construcción de la deliberación. El PRD-4 (extensiones del guardia de recursión) requería comprender las decisiones de los PRDs 1-3. Sin el traspaso, la nueva sesión habría necesitado releer todos los archivos modificados. Con el traspaso, la sesión comenzó con el contexto arquitectónico y fue directamente a la implementación.

Estrategia 4: Delegación a subagentes

Los subagentes se ejecutan en ventanas de contexto independientes. Delegar tareas de investigación o revisión a subagentes preserva el contexto de la sesión principal para el trabajo de implementación.⁷

Mi sistema de guardia de recursión gestiona esto automáticamente:

# From recursion-guard.sh - spawn budget enforcement
MAX_DEPTH=2
MAX_CHILDREN=5
DELIB_SPAWN_BUDGET=2
DELIB_MAX_AGENTS=12

Cada subagente devuelve un resumen en lugar de la salida sin procesar, manteniendo el contexto principal ligero. Durante las reescrituras de publicaciones del blog, delego tareas de exploración (recopilar datos de CSS, leer código de hooks, examinar estructuras de directorios) a subagentes. El contexto principal se mantiene enfocado en la escritura mientras los subagentes manejan la investigación.

El presupuesto de generación se aprendió por las malas: una sesión temprana sin límites generó subagentes recursivos que a su vez generaron más subagentes. El hook de guardia de recursión ahora aplica límites de profundidad con validación segura de enteros y presupuestos configurables.⁸

Los anti-patrones que aprendí

Leer archivos completos cuando se necesitan 10 líneas. Al principio de mi uso de Claude Code, leía archivos completos de 2.000 líneas para una sola función. Use desplazamientos de línea: Read file.py offset=100 limit=20 ahorra más de 15.000 tokens por lectura.

Mantener salidas de error verbosas en el contexto. Después de depurar el problema del presupuesto de generación, mi contexto contenía más de 40 trazas de pila de iteraciones fallidas. Un solo /compact después de corregir el error liberó ese peso muerto.

Comenzar cada sesión leyendo todos los archivos. Mis primeras sesiones precargaban 8-10 archivos “para contexto.” Ahora dejo que las herramientas glob y grep de Claude Code encuentren los archivos relevantes bajo demanda, ahorrando más de 100.000 tokens de precarga innecesaria.

Conclusiones clave

Para desarrolladores individuales: - Compacte después de cada subtarea completada, no cuando Claude fuerce la compactación; la compactación proactiva en intervalos de 25-30 minutos mantiene la calidad del resultado - Escriba las decisiones clave en archivos de memoria del sistema de archivos a medida que avanza la sesión; mi MEMORY.md tiene 54 entradas que persisten a través de cientos de sesiones - Use subagentes para tareas de investigación que contaminarían el contexto principal; una consulta de investigación de 5 archivos cuesta más de 75.000 tokens en el contexto principal, pero solo un resumen de 500 tokens a través de un subagente

Para equipos: - Estandarice el formato de documentos de traspaso para tareas multi-sesión; mis 49 traspasos siguen la misma estructura de Estado/Archivos/Decisión/Bloqueado/Siguiente - Configure archivos CLAUDE.md a nivel de proyecto con contexto arquitectónico que se carga en cada sesión automáticamente; consulte El contexto es arquitectura para la jerarquía de 7 capas que surgió de estos principios de gestión de tokens

Preguntas frecuentes

¿Qué ocurre cuando se llena la ventana de contexto de un LLM?

Cuando la ventana de contexto se acerca a su capacidad (alrededor del 95% de utilización), Claude Code activa la compactación automática: un proceso de resumen que condensa el historial de la conversación para liberar espacio. Sin embargo, la calidad del resultado se degrada mucho antes de que se dispare la compactación. En mis mediciones sobre 50 sesiones, la degradación empieza cerca del 60% de utilización del contexto: el modelo olvida instrucciones anteriores, repite sugerencias ya descartadas y produce cambios multiarchivo menos coherentes. Además, cada compactación descarta contexto que pudo contener decisiones importantes, así que cuantas menos compactaciones haya, más coherente será la sesión.

¿Cómo se gestiona el contexto de un LLM durante sesiones largas?

Cuatro estrategias mantienen la calidad del resultado en sesiones de varias horas. La compactación proactiva tras cada subtarea terminada (cada 25 o 30 minutos) evita la degradación silenciosa. La memoria basada en el sistema de archivos (CLAUDE.md, MEMORY.md, documentos de traspaso) conserva el estado crítico más allá de los límites del contexto. La delegación a subagentes traslada las tareas de investigación a ventanas de contexto independientes y devuelve resúmenes en lugar de salidas en bruto. Y las lecturas dirigidas con desplazamiento de líneas (Read file.py offset=100 limit=20) ahorran más de 15.000 tokens por lectura frente a cargar el archivo completo. Si quieres el marco de compresión en tres capas, consulta El contexto es la nueva memoria.

¿Qué es la compactación de contexto en Claude Code?

La compactación de contexto es el mecanismo integrado en Claude Code que resume el historial de la conversación cuando la ventana de contexto se aproxima a su capacidad. El comando /compact la lanza de forma manual y la compactación automática se activa en torno al 95% de utilización. El proceso conserva las decisiones clave, el contenido de los archivos y el estado de las tareas, y descarta las salidas de herramientas más verbosas. Un cortacircuitos detiene el proceso tras tres fallos consecutivos de compactación para evitar bucles infinitos de reintento. Antes de que existiera esa salvaguarda, 1.279 sesiones encadenaron más de 50 fallos consecutivos y desperdiciaron unas 250.000 llamadas a la API al día, tal como documenta el análisis de la filtración del código fuente.

¿Cuántos tokens bastan para desarrollar con IA de forma productiva?

Una ventana de contexto de 200K tokens es suficiente si se gestiona bien. Mi configuración comprimida mantiene disponible cerca del 78% de la ventana (156.000 tokens) para el razonamiento, lo que permite entre 40 y 60 turnos productivos antes de alcanzar el umbral de compactación. Una configuración sin comprimir deja solo el 26% (53.000 tokens) para razonar y llega a la compactación a los 15 o 20 turnos. El tamaño útil de una ventana depende más de lo que la llena que de su capacidad: una ventana de 200K bien comprimida rinde mejor que una hipotética de 500K atiborrada de salidas de herramientas sin comprimir. Comprimir el prompt del sistema, diseñar las herramientas pensando primero en la CLI y lanzar agentes nuevos son las optimizaciones de mayor impacto.

¿Cómo ayudan los documentos de traspaso en el desarrollo con IA a lo largo de varias sesiones?

Un documento de traspaso recoge el estado completo de una tarea para la siguiente sesión: situación actual, archivos modificados, decisiones tomadas, bloqueos y próximos pasos. Empezar una sesión leyendo ese documento aporta todo el contexto arquitectónico con un costo mínimo en tokens (por lo general, menos de 500) en lugar de obligar al agente a releer todos los archivos modificados. Mis 49 documentos de traspaso siguen la misma estructura Status/Files/Decision/Blocked/Next. Durante la construcción del sistema de deliberación, los traspasos permitieron que cada sesión dedicada a un PRD arrancara con las decisiones de arquitectura ya cargadas, sin arrastrar el historial de conversación de los PRD anteriores.

Referencias