La ventana de contexto es una característica central de todo modelo de frontera. Medido en tokens, generalmente se compone del aviso del sistema y un historial creciente de avisos, respuestas y llamadas a herramientas que se remontan hasta donde el límite lo permite.
Para cada token que genera el modelo, primero mira hacia atrás en toda la ventana de contexto. Este es el único mecanismo por el cual tiene memoria de una sesión de chat. El modelo no mantiene ningún estado interno persistente de un turno al siguiente. Y como veremos, la ventana contextual no es almacenamiento pasivo. Todo lo que contiene tiene el potencial de dar forma a los resultados del modelo, para bien o para mal.
Esta es una experiencia común: una sesión que empieza fuerte y poco a poco va perdiendo el hilo. La disminución gradual en la calidad de salida de un modelo impulsada por el contenido de la ventana de contexto se conoce comúnmente como deterioro del contexto.
Podemos separar las fuentes de deterioro del contexto en dos categorías. La primera es la descomposición intrínseca: una propiedad de cómo un modelo aplica la atención a través de la ventana de contexto a medida que genera resultados. Entraremos en más detalles a continuación, pero por ahora la conclusión clave es la siguiente: por perfectamente relevante que sea el contexto, la capacidad del modelo para recordar y distinguir información es imperfecta.
La segunda categoría la llamamos deterioro del contenido. Se trata de la acumulación de información obsoleta, errónea y contradictoria a lo largo de una sesión. El enfoque fallido al que el modelo sigue recurriendo, o la docena de llamadas a herramientas tangenciales que no llegaron a ninguna parte. Todo ello reprocesado repetidamente, moldeando lentamente el resultado de la sesión.
Afortunadamente, a diferencia de la descomposición intrínseca, la descomposición del contenido es nuestra y podemos gestionarla, y aprender a controlarla transforma herramientas como Claude Code, que pasan de ser ocasionalmente frustrantes a ser constantemente afiladas.
Podredumbre intrínseca: el suelo modelo
La descomposición intrínseca se refiere a las limitaciones de rendimiento inherentes a la arquitectura del modelo. No nos corresponde a nosotros incitarnos o mejorar; es el suelo sobre el que descansa todo lo demás. Pero vale la pena entender el mecanismo por dos razones: explica la motivación detrás de algunas de las prácticas que se describen más adelante en esta publicación y ayuda a disolver la ilusión de que hay un pequeño ingeniero ahí atrás acumulando silenciosamente una comprensión de su proyecto. (Para un recorrido completo de atención, la lección de 3Blue1Brown es excelente).
En cada turno, toda su sesión (solicitudes, respuestas, lecturas de archivos, resultados de herramientas) se aplana en una larga secuencia de tokens y se pasa a través del modelo. La arquitectura del LLM es compleja, pero los centros de atención son el componente más importante para el contexto. Cada cabeza responde a una única pregunta: ¿cuánto debe extraer cada ficha de cada ficha anterior? Un token relevante contribuye en gran medida a la próxima predicción; uno irrelevante aporta poco, pero nunca nada.
Ese “nunca nada” es el quid. Las puntuaciones de relevancia de cada cabeza pasan a través de softmax, una función que obliga a las puntuaciones a sumar uno. Esto significa que hay un presupuesto fijo de atención. Debido a que softmax se basa en exponenciales, la parte del presupuesto de ningún token puede llegar exactamente a cero. Cada token en su ventana, por irrelevante que sea, compite por el mismo presupuesto fijo. Esto no es un accidente de implementación; softmax es fundamental para llamar la atención precisamente porque convierte las puntuaciones competitivas en una distribución fluida y fácil de aprender. Pero esa propiedad útil refleja una compensación: el contexto irrelevante nunca es gratuito. Para ser claros, la dilución es sólo una de varias explicaciones principales de la degradación a largo plazo. Y los modelos aprenden soluciones parciales, descargando la atención sobrante en posiciones desechables, pero se trata de mitigaciones, no de escapes.
La consecuencia de esto es sutil. A medida que crece el contexto, el modelo aún puede clasificar los tokens correctos en la posición más alta; el orden sobrevive. Lo que se erosiona es el margen: la brecha entre el token que importa y la masa difusa de todo lo demás. Incluso cuando el modelo “sabe” dónde mirar, la lectura llega borrosa, mezclada con miles de débiles contribuciones de la ventana circundante. Piense en ello como una dilución: un presupuesto fijo distribuido cada vez menos, empeorando la relación señal-ruido.
El límite de contexto establecido no es un precipicio de rendimiento; la erosión es gradual y comienza temprano.
La posición también importa. El orden de las palabras es fundamental para el lenguaje, por lo que los modelos codifican dónde se ubican los tokens (los modelos abiertos generalmente mediante codificación posicional rotativa; los sistemas cerrados rara vez lo revelan). El mecanismo exacto importa menos que la consecuencia medida: coloque un hecho en diferentes posiciones a lo largo de un contexto largo y la precisión de la recuperación traza una U, más alta al principio y al final, y más baja en el medio (Liu et al., 2024). La causa exacta todavía se debate. Lo que nos importa es la caída: en una sesión de horas, el medio amplio es donde reside la mayor parte del contenido real, y no es un almacenamiento seguro.
Estos se conocen como puntos de referencia de la aguja en un pajar. Para el caso simple, las curvas de proveedores son relativamente planas y esencialmente resueltas. Haga que la recuperación sea solo un poco más difícil, eliminando la fácil superposición de palabras entre pregunta y respuesta para que el modelo tenga que coincidir en significado (NoLiMa, Modarressi et al., 2025), y la caída llega mucho antes de lo que sugiere el límite del título. Cuando se sostienen varias piezas a la vez y se razona sobre ellas: el rendimiento se degrada mucho dentro de la ventana indicada, incluso con una recuperación perfecta y se eliminan todos los distractores (Du et al., 2025). Un modelo que puede encontrar un hecho en 100.000 tokens no necesariamente puede pensar con él allí.
Por lo tanto, el supuesto de trabajo para cualquiera que intente realizar un trabajo: su presupuesto de contexto útil se encuentra muy por debajo de cualquier límite establecido.
Pudrición del contenido: cómo se degradan las sesiones
Esta sección trata sobre el contenido cargado en contexto durante una sesión. Anteriormente describimos la descomposición del contenido como nuestro dominio de control. Si bien esto es cierto, en la práctica una sesión tiene múltiples actores: nosotros, el modelo y cualquier subagente que se genere a lo largo del camino.
El grado de autonomía que permitimos generalmente se rige por un conjunto de comandos permitidos: grep un espacio de trabajo de proyecto, extracción de un repositorio git remoto, acceso MCP a una base de conocimiento de la empresa. El objetivo de estas herramientas es tener autonomía; de ahí proviene la productividad. A medida que recorremos los diversos modos de falla que conducen a la descomposición del contenido, el objetivo no es acortar la correa, sino reconocer que todavía somos la mejor corrección de errores en el ciclo: detectar el archivo leído demasiado amplio, el error marcado con un círculo que en realidad es una configuración faltante, y detener el ciclo antes de que el daño esté hecho.
Su sesión es un circuito de retroalimentación. Con cada turno, todo lo que está en la ventana contextual del modelo, cada archivo leído, salida de herramienta e intento fallido, se retroalimenta a través del modelo, dando forma a lo que produce antes de incorporarse al siguiente token. La salida se convierte en entrada. Un paso limpio añade una línea limpia; un paso confuso añade otro confuso, mientras el modelo sigue condicionando su propia confusión. El error persiste y avanza.
Los cuatro modos de falla que siguen son la taxonomía de fallas de contexto de Drew Breunig (confusión, choque, distracción y envenenamiento), de su publicación How Long Contexts Fail, aquí basada en el día a día de las sesiones de codificación agente:
Cargar demasiado en el alcance (confusión).
Cada vez es más común cargar cada sesión con una lista cada vez mayor de herramientas, habilidades y servidores MCP. Esto tiene sentido de forma aislada: las herramientas dedicadas con conjuntos de instrucciones especializadas pueden ser muy eficientes y funcionar bien. Pero, ¿alguna vez has notado a un modelo buscando una herramienta para realizar las tareas más insignificantes, o incluso la herramienta equivocada? Peor aún, un aparato inflado no solo confunde la selección de herramientas (Kate et al., 2025), sino que agrega información en cada turno, donde ya mostramos que el razonamiento se degrada con una longitud de entrada muy por debajo del límite establecido (Levy et al., 2024; Du et al., 2025).
Ante una tarea, un modelo con muchas herramientas tiende a recurrir a ellas de todos modos, incluso cuando su propio conocimiento sería suficiente: una tendencia mesurada a invocar herramientas para tapar lagunas de razonamiento (Zeng et al., 2026). En términos más sencillos, incluso la herramienta inactiva no es gratuita: su definición se encuentra en la ventana en todo momento, tomando una porción del presupuesto de atención, ya sea que la llames o no.
Dejar que un desvío de depuración fije la teoría (choque).
¿Alguna vez se ha encontrado trabajando duro para convencer a un modelo de que su diagnóstico es erróneo, mientras éste inclina nuevas observaciones contradictorias hacia una suposición que ya no tiene sentido, sólo para volver al mismo punto una vez que la tarea ya está resuelta? El efecto se ha medido: los modelos se comprometen temprano con una lectura y luchan por dejarla. Tareas que resuelven limpiamente cuando se les entrega todo de una sola vez, pero fallan una vez que la misma información llega confusa en cada turno (Laban et al., 2025). El diagnóstico aquí es que el camino en sí puede volverse difícil.
Buscar personas amplias y atraer personas parecidas (distracción).
Cuando el agente busca o descarga un directorio para encontrar lo que necesita, extrae dispositivos de prueba, implementaciones inactivas, simulacros y funciones con nombres similares de módulos no relacionados, todos los cuales parecen plausibles. El problema es que los modelos pesan mucho sobre la ventana: no tratan el contexto como material de referencia opcional, sino que lo incorporan de manera confiable, incluso cuando es irrelevante (Shi et al., 2023). Un solo distractor relacionado con un tema es suficiente para reducir de manera mensurable el rendimiento (Mirzadeh et al., GSM-Symbolic, 2024), y una base de código está llena de ellos. El modelo se centra demasiado en lo que arrastró la búsqueda, a expensas del razonamiento que habría funcionado limpiamente sin ella. Esto nos conecta directamente con el suelo: el margen entre el objetivo y sus vecinos cercanos colapsa, y una búsqueda destinada a aclarar llena la ventana con alternativas convincentes que el modelo no puede dejar de atender.
Dejar que una nota equivocada se endurezca hasta convertirse en verdad (envenenamiento).
Esto es particularmente frecuente en tareas de larga duración. A menudo esto se debe a una buena intención: a medida que el proyecto crece y las decisiones se acumulan, el agente registra lo que ha encontrado en un NOTAS.md, o una serie de archivos con nombre que rastrean los pasos dados y el trabajo realizado, con el fin de proporcionar un contexto futuro útil. Más tarde, detectas una de esas suposiciones en el chat en vivo y es incorrecta. Interrumpes, corriges, sigues adelante. Pero la nota nunca fue actualizada. Se almacena en el archivo, se vuelve a leer más tarde y puede sobrevivir a la corrección del chat. Una vez que la corrección sale de la ventana, el archivo obsoleto es la versión que queda. Una nota que escribió el modelo no es evidencia; es un reclamo pendiente de confirmación. El modo de falla es el estado obsoleto, no el estado en sí.
A los cuatro modos de Breunig yo añadiría la combinación. Cada uno alimenta al siguiente: una nota incorrecta en un archivo envía al agente a buscar una solución que nunca fue necesaria, la búsqueda arrastra un montón de imitaciones plausibles, que lo confunden hacia una nueva teoría equivocada, y se genera un desvío de depuración para resolverlo que establece otra. Cada turno condiciona el desorden acumulado del último, y los errores no acaban de sumar; hacen que lo siguiente sea más probable.
Esto lleva a un punto más sutil: el modelo rara vez se protege cuando se degrada. Después de un giro equivocado, se basa en el error en lugar de señalarlo. (Laban et al., 2025), y una sesión profundamente podrida puede parecer saludable hasta que se rompe el resultado. No se puede confiar en que el modelo se decida a sí mismo, por lo que aún se necesita un observador externo para obtener los mejores resultados.
Si el límite real es la calidad del contenido, entonces la gestión del contexto se reduce menos a guardar tokens y más a reconocer el patrón y cambiar el comportamiento futuro.
Gestión del contexto: la práctica cotidiana
La regla práctica es simple: el contexto no es almacenamiento. Es una entrada activa. Todo lo que aparece a continuación se enmarca en torno a Claude Code, la herramienta que mejor conozco, pero cada práctica es primero un principio: la guía se traslada a cualquier herramienta agente, incluso cuando los nombres de los comandos difieren.
Antes del primer mensaje: curar
Si aún no está claro, un nuevo comienzo vale más que cualquier camino de recuperación posterior. Esto es lo que hace que el trabajo inicial valga la pena: un proyecto bien seleccionado (un CLAUDE.md ajustado, las habilidades y los ganchos adecuados) hace que sea barato iniciar una nueva sesión. El costo se paga una vez, deliberadamente, de modo que cada reinicio posterior sea casi gratuito.
La mayoría de la gente estará familiarizada con el archivo CLAUDE.md. Cada sesión comienza leyendo este archivo y se lleva a cabo en cada turno. Por eso vale la pena ser implacable al editar: cada línea gana su lugar y se elimina la hinchazón. Un marco útil es tratarlo como la lectura mínima requerida para un nuevo ingeniero el primer día. Específicamente, ¿qué es lo que no podrían resolver leyendo solo el código: los comandos de compilación y prueba, la forma del proyecto, las convenciones que realmente cumples, las trampas? Omita todo lo que el modelo pueda inferir, cualquier cosa que cambie con frecuencia y cualquier cosa que sólo sea relevante a veces. /init le brinda un punto de partida útil para podar agresivamente.
Mantenga el contexto que siempre está cargado con señal mínima y alta. El modelo recuerda fácilmente el conocimiento general y se desperdicia como contexto, donde sólo se suma a la dilución que vimos anteriormente. Mantenga la ventana para lo que es específico, novedoso o cambiado desde la capacitación y apóyese en el conocimiento del propio modelo para el resto.
No es necesario desperdiciar lo que corte; muévalo a algún lugar que se cargue solo cuando sea necesario. Los procedimientos y el conocimiento del dominio se convierten en habilidades, cuyo contenido permanece latente hasta que se invoca. Las reglas que deben cumplirse siempre (formateo, un comando bloqueado) se convierten en ganchos, que se ejecutan fuera del contexto de su sesión principal. Haga de capturarlos un hábito: notar información útil cuesta mucho menos en el momento que reconstruirla después del hecho.
Audita lo que pones en el alcance. Hemos visto cómo un espacio de herramientas abarrotado reduce el rendimiento. Ejecute /mcp o /skills y desactive los servidores o habilidades que no necesita una nueva tarea.
Semilla con lo que estrecha, no con lo que se relaciona. Si conoce los archivos relevantes, asígneles el nombre @path/to/file.
Déjelo planificar antes de escribir. Un plan equivocado cuesta un párrafo y es una solución barata. Mayús+Tab en modo de plan, o /plan, para cualquier cosa que toque más de un par de archivos.
Mientras trabajas: mantenlo limpio
Mantenga el objetivo reciente. Sabemos que en la mitad de una ventana de contexto larga es donde la recuperación del modelo es menos confiable. En tareas más largas, actualice los objetivos de la sesión en cada hito: reformule el objetivo actual, las restricciones en vivo y una breve lista de tareas en ejecución para que el agente las reescriba.
Envíe un trabajo detallado a los subagentes. Una ejecución de prueba, un rastreo de registros, una auditoría de dependencia: cualquier cosa que genere un muro de resultados que no necesite conservar. Sólo necesitamos la conclusión.
Exteriorizar el estado duradero y mantenerlo verdadero. Un archivo de notas que mantiene el agente vive fuera de la ventana y sobrevive a un reinicio; cualquier cosa que deba persistir a lo largo de las sesiones puede vivir aquí. Pero sea intencional: un recuerdo obsoleto es peor que ninguno. Puede sobrevivir a la corrección que realizó en el chat y volver a ingresar más tarde como una verdad aparente.
Vuelva a la verdad básica y conviértala en un hábito. Verifique el archivo, la prueba, el error real, no la memoria del modelo sobre ellos. El ! prefix ejecuta un comando de shell y coloca su salida real directamente en contexto, por lo que !git status o !npm test fundamentan la sesión nuevamente en lo que es realmente cierto en lugar de lo que recuerda el modelo. Si te encuentras haciendo esto con frecuencia, hazlo tuyo: una pequeña habilidad que inyecta el estado real de tu proyecto (el estado de git, el resultado de la prueba, la verificación de tipo) de una sola vez.
Cuando gira: reinicie, no presione
Esta es la guía más difícil de seguir; En este punto, tu historial de turnos parece un progreso que estarías desperdiciando. Ésa es la falacia del coste hundido: esas fichas se gastan tanto si mantienes la ventana como si la limpias, y la única pregunta es si el siguiente turno comienza en un contexto podrido o saludable.
Dos correcciones en el mismo punto es la señal. Cuando le haya dicho dos veces que el error no está en la capa de autenticación y siga dando vueltas hacia atrás, deténgase. Reiniciar.
Atrápalo a mitad de paso si puedes. Si ve que va en la dirección equivocada, presione Ctrl+C y redirija en lugar de permitir que un cambio incorrecto aterrice y se acumule. Si ya lo ha hecho, Esc+Esc abre el rebobinado: revierte la conversación, el código o ambos a un punto de control anterior.
Regenerate, no lleves adelante. Para un trabajo autónomo y re-derivable, regenerar el resultado en una sesión limpia a menudo es mejor que una historia resumida. El efecto es más agudo cuando un intento ya ha salido mal. En el Banco de Recuperación de Letta, los agentes a los que se les entregó el historial completo de sus intentos fallidos obtuvieron peores resultados que los que empezaron de cero, y el contexto podrido frenó activamente la recuperación en lugar de informarla.
Cuándo actuar y qué llevar adelante depende del estado actual de la sesión:
Nueva tarea no relacionada → /clear. No quieres nada del viejo contexto. Siguiente fase del trabajo relacionado, sesión saludable → entrega del estado (ver más abajo). El límite de contexto se alcanzó a mitad de la tarea, sesión saludable → /compact. Quieres la historia destilada de lo que ha sucedido. La sesión ha cambiado → toma una instantánea del estado a mano y de forma clara. No puede confiar en que el modelo resuma un contexto que ya no puede leer bien, por lo que extrae lo que importa usted mismo, de archivos, diferencias, pruebas y decisiones conocidas, antes de restablecerlo.
Estado de transferencia, no la transcripción. En un límite saludable, haga que el agente escriba un informe de transferencia.
Los fracasos instructivos son útiles aquí, y la forma en que los mantienes es importante: resume cada uno en una lección de una sola línea (“intenté X, fallé porque Y”).
Abra la próxima sesión sobre la verdad breve y sobre el terreno. Una ventana nueva es más rápida cuando su primer acto es orientar, no adivinar. Apunte al resumen de transferencia, luego establezca la realidad directamente: lea los archivos relevantes, ejecute las pruebas, verifique el estado de git. El informe le dice dónde estaban las cosas; los controles en vivo le dicen dónde están realmente las cosas.
Para trabajos largos o paralelos
Descomponerse en costuras verificables. Divida una tarea cuyo resultado sea barato de verificar (una prueba que pasa, una compilación que compila, un número que concilia), no en la unidad más pequeña posible.
Distribuya los subagentes solo cuando las partes sean independientes. Un contexto limpio por subtarea, cada una de las cuales devuelve un resumen resumido, funciona bien para lograr amplitud: investigación paralela, búsquedas independientes. Para la codificación, donde las subtareas suelen estar acopladas, los agentes aislados hacen suposiciones contradictorias y usted hereda la tarea de conciliarlas. Mantenga el trabajo estrechamente acoplado en un subproceso y, cuando desee aislarlo sin el riesgo de coordinación, un árbol de trabajo de git (claude -w) le da a una tarea paralela su propia rama para trabajar.
Aislar la depuración. Un error es el caso en el que la bifurcación se amortiza sola. Envía la investigación a una bifurcación o comienza una sesión desde cero, deja que se forme y descarta teorías erróneas en un contexto que desecharás, y recupera solo la causa y la solución.
Trae ojos nuevos. Una /code-review, o un subagente revisor dedicado que lee desde un contexto limpio, puede captar lo que una sesión podrida no puede ver por sí misma.
Uniéndolo todo: una sesión como un árbol de git
Esta sección describe mi propio flujo de trabajo, moldeado por los hallazgos anteriores. Su objetivo es hacer que esos principios sean automáticos y eliminar la fatiga de tomar decisiones al ejecutar muchas sesiones a la vez. No tiene un punto de referencia, así que trátelo como la síntesis de un profesional.
Encuadre una sesión como una rama de git. Su principal hilo de conversación es el orquestador de la tarea y el objetivo es que su contexto se mantenga limpio y enfocado en la tarea. Cuando surge un desvío (del tipo que quemará ciclos de investigación, callejones sin salida o búsqueda de datos), lo separas en su propia sesión con la historia hasta el momento (claude –continue –fork-session) y haces el trabajo desordenado allí. Aquí es donde la bifurcación se diferencia de un subagente. Los subagentes ya manejan trabajo paralelo e independiente: generan, exploran y devuelven un resumen. La bifurcación es para el desvío secuencial de su hilo principal: la investigación desordenada que necesita su historial de sesión completo para tener sentido, donde no hay un camino automático de regreso y desea elegir qué regresa.
Esto le da a la gestión del contexto una forma simple y familiar: ramificar, explorar, destilar, fusionar. El tenedor es un contexto desechable por diseño. Puede acumular toda la podredumbre que necesite, porque vas a desechar la ventana de contexto y conservar solo el resultado. Nada de lo que ocurra en la sucursal debe contaminar a la principal.
Cuando la rama tiene una respuesta, la destilas y la fusionas nuevamente. Las dos mitades de este proceso son habilidades que he desarrollado sobre la bifurcación nativa. Una habilidad /conclude escribe la rama en un solo archivo en una carpeta dedicada (yo uso ./cc-branches); un argumento de tipo selecciona entre una serie de plantillas que describen diferentes métodos para concluir una rama, coincidiendo con el tipo de trabajo realizado. De vuelta en la sesión principal, una habilidad /merge carga ese archivo, agregando al contexto la conclusión y nada del ruido que lo produjo.
Más allá de la higiene del contexto, el marco git ha aportado claridad a mi flujo de trabajo y ha reducido la fatiga de cambiar entre muchas tareas a la vez. Proporciona un modelo mental limpio: cada rama nombrada se convierte en una pregunta discreta con una respuesta limpia, almacenada para referencia futura.
Hasta ahora todo supone que hay un corrector en el bucle, y la mayoría de las veces es una persona. No porque la gente sea mejor que el modelo en el trabajo, sino porque el modelo no tiene freno interno. No puede ver su propia podredumbre, por lo que la corrección tiene que llegar desde fuera. A eso se reduce el contexto gobernante: alguien fuera de la ventana que decide qué entra, qué queda fuera y qué sobrevive.
Contexto gobernado
Pase cualquier tiempo con Claude Code, observándolo leer archivos, ejecutar comandos, escribir parches, generar subagentes y mantener notas, y rápidamente comenzará a sentirse como un pequeño ingeniero allí: interiorizando su código base, entendiendo el límite entre tareas y errores, y continuando solucionando los problemas.
No del todo, y no en la forma que importa aquí.
El modelo no experimenta su proyecto como un proyecto. Experimenta el contexto actual: las instrucciones, los archivos visibles, los resultados de la herramienta, la conversación reciente. Todo ello, en conjunto, como insumo de trabajo. Parte de esto es señal. Algo de eso es ruido. Algo de eso solía ser cierto. Algo de eso nunca fue cierto. El modelo tiene que actuar de todos modos. Cuando tratamos la sesión como comprensión acumulada, nuestros comportamientos cambian, nuestro resultado empeora y, a veces, terminamos culpando al modelo.
Por eso la gestión del contexto no es una preocupación secundaria. Claude Code es una superficie de control para el contexto que llega al modelo, y sus comandos principales (borrar, compactar, rebobinar, bifurcar, subagentes, habilidades y ganchos) no son solo características de conveniencia. Son controles sobre lo que entra en contexto, lo que queda fuera y lo que sobrevive entre sesiones.
El contexto que gobierna no es el que domina el modelo. Es atender la mitad del problema que es tuyo, el contenido, encima de un piso la arquitectura se pone y no te puedes mover. El piso mejora según el cronograma de los laboratorios. La capa de contenido mejora contigo.
Ésta es la forma del trabajo exitoso con estas herramientas: no un contexto máximo, sino un contexto gobernado.