No confíes en las ventanas de contexto grandes

• La ventana de contexto de un LLM puede dividirse en una zona inteligente donde el modelo funciona con precisión y una zona torpe donde su atención cae y empieza a olvidar instrucciones previas
• El punto de quiebre está cerca de los 100k tokens, y aunque se anuncien ventanas de contexto más grandes, eso no significa el rango real de trabajo utilizable
• Los agentes de código pueden consumir tokens rápidamente solo con leer archivos, depurar durante mucho tiempo y ejecutar pruebas grandes, alcanzando pronto los 100k tokens
• El informe de RULER y el reporte de context rot de Chroma muestran que el contexto efectivo es solo una parte de la cifra anunciada, y que el rendimiento se degrada gradualmente a medida que se llena la ventana
• En vez de depender de resúmenes automáticos para sesiones largas, dejar la información fuera de la sesión mediante especificaciones y artefactos pequeños escritos manualmente ayuda a mantener el trabajo dentro de la zona inteligente

---

Los límites reales de la ventana de contexto

• La ventana de contexto de un LLM puede dividirse en una zona inteligente donde el modelo está afinado y una zona torpe donde su atención disminuye
  • En la zona torpe, el modelo empieza a olvidar lo que se le dijo hace apenas unos minutos
  • El punto de separación está cerca de los 100k tokens
  • Aunque se anuncien ventanas de contexto más grandes, ese punto de separación no desaparece
• Los agentes de código consumen tokens rápidamente en el uso moderno
  • Con unas cuantas lecturas de archivos, una sesión larga de depuración y una ejecución amplia de pruebas, se puede llegar a 100k tokens
  • Los proveedores anuncian ventanas de contexto de 200k, 1M y 2M, pero esos números no representan el conjunto de trabajo realmente utilizable
• Las ventanas de contexto grandes se parecen más a números de marketing
  • La arquitectura detrás funciona, pero tapa problemas que el mecanismo básico de atención no resuelve en la práctica
  • La cifra mostrada en el producto crece con cada versión, pero la parte realmente útil no avanza al mismo ritmo
• RULER y el reporte de context rot de Chroma muestran que el contexto efectivo es solo una parte de la cifra anunciada
  • El rendimiento se degrada gradualmente conforme se llena la ventana de contexto

Una forma de trabajar manteniendo las sesiones cortas

• Los agentes más recientes han empezado a incorporar funciones de compresión automática para manejar sesiones largas
  • Claude Code hace auto-compact: resume el historial y reinicia cuando la sesión se vuelve larga
  • Este enfoque ayuda, pero actúa después de haber pasado tiempo en la zona torpe
  • Además, el resumen lo genera un modelo cuyo rendimiento ya viene degradado
• Una mejor forma de traspaso es abrir una sesión nueva y pasarle una especificación escrita directamente por una persona
  • Una especificación escrita a mano se convierte en un material de traspaso con una señal más fuerte que un resumen automático
  • Porque una persona puede decidir directamente qué será importante hacia adelante
  • Este enfoque corresponde al método de breadcrumb, que deja artefactos para que la siguiente sesión o la siguiente persona pueda continuar de forma limpia
• obra/superpowers y mattpocock/skills estructuran flujos de trabajo de agentes alrededor de artefactos pequeños con nombre
  • PRD, planes, skills y traspasos a subagentes son ejemplos de esos artefactos
  • Cada artefacto mueve información fuera de la sesión en vivo para que la siguiente sesión pueda leerla
  • Este enfoque ayuda a que las sesiones de trabajo se mantengan dentro de la zona inteligente
• La ventana de contexto debe tratarse como un presupuesto
  • Hay que asumir que la parte realmente útil son algunos chunks del inicio
  • La información que se mueve desde la sesión en vivo hacia un artefacto escrito reduce aquello por lo que debe competir la atención del modelo

[GN⁺]

Comentarios en Hacker News

• Aprender los fundamentos de la IA es bastante divertido, pero no estoy de acuerdo con la dirección que está tomando ahora
  Es difícil expresar con palabras lo inquietantes que se sienten los comentarios en hilos como este. Las anécdotas bien intencionadas de “a mí me pasó esto con XYZ” se ven como consejos en hilos de Facebook sobre cuidado de mascotas o cocina
  Los grupos de Facebook sobre impresión 3D son todavía peores; si imprimes pero también quieres entender qué está pasando realmente, creo que sabes a qué me refiero
  En el mundo de los LLM, especialmente en el de los LLM en la nube, el rigor compartido se ha derrumbado por completo, y al final da la impresión de reducirse a una imitación casi ritual. Nadie termina estando más en lo correcto o más equivocado que los demás
  Tiene una vibra de “¿ya intentaste limpiar el contexto con detergente Dawn, dejarlo secar y luego ponerle una capa de barra de pegamento?”
  No quiero sonar demasiado duro con la gente que intenta ayudar. Solo que se siente muy distinto de los hilos sobre otros temas. Normalmente, la sugerencia de alguien provoca discusión o refinamiento por parte de otros, y a veces alguien explica algo como la forma de selección del historial de bash y te cambia la vida; pero estos hilos terminan yéndose hacia algo como “¿no es raro que funcione si lo amenazas?”

  • La naturaleza arbitraria y no determinista del flujo de trabajo con LLM realmente me incomoda. Como alguien de la vieja escuela de embebidos/sistemas, siempre he priorizado la determinación y la reproducibilidad
    Aun así, los agentes son impresionantes, y también es divertido convertirse en un “diseñador del proceso de pensamiento”. No voy a volver atrás. Aunque el desarrollo de IA se detuviera hoy, siento que mi carrera ya no sería la misma que antes
  • En la industria tecnológica esto siempre ha existido, desde mucho antes de que aparecieran los LLM
    He pasado por demasiadas reuniones donde las decisiones se tomaban no con base en criterios objetivos y medibles, sino porque “una empresa un poco más famosa lo hace así”. Incluso cuando había pruebas de que esa empresa ni siquiera seguía ese enfoque de forma generalizada, sorprendentemente eso tenía muy poco peso
  • Los consejos de TI siempre han tenido algo de esto. Cuanto más complejos son los sistemas y los resultados, más difícil es definir con claridad qué es “mejor” y qué es “peor”
    Si además sumas el hecho de que los LLM son fuertemente no deterministas, entonces los consejos sobre LLM terminan siendo, en la práctica, como consejos de jardinería
    Incluso los “benchmarks” en su mayoría se parecen más a intentos de cristalizar con cierto éxito la intuición de alguien
  • Comparto mucho la frustración y, en general, estoy de acuerdo. Cada vez que intento formalizar un flujo de trabajo basado en LLM, vuelvo a desilusionarme porque parece que nadie sabe realmente por qué unas cosas funcionan y otras no
    Así que al final termino regresando a /plan y le digo que deje todo escrito en un documento Markdown para más adelante, antes de iterar sobre la implementación, con la esperanza de que para el próximo mes aparezca algo más riguroso y con una base más razonable
    Yo no uso para nada barra de pegamento porque no me hace falta. Pero Dawn sí parece bastante efectivo para lograr que la placa de impresión de Bambu vuelva a agarrar bien. No lo busqué a propósito; ya lo tenía para lavar los platos. Como el IPA no funcionó, probé con Dawn, y varias veces hizo que las impresiones volvieran a adherirse bien. Todavía no he llegado a N=30
  • Puede que la idea misma de “rigor compartido” en nuestra cabeza sea una ilusión, y que los LLM y su problema de contexto simplemente lo estén dejando al descubierto
    En décadas viviendo en la industria tecnológica, no he visto mucho rigor. Las herramientas se acumulan, los paradigmas nacen, mueren y reaparecen, y para cualquier vara con la que midas algo siempre hay otra vara competidora con unidades distintas. Más allá de la física de potencia y señal, y del costo dominante de las obleas de silicio, comparados con unas pocas disciplinas mucho más antiguas, casi todos somos poco más que improvisadores con distinto nivel de habilidad
    Los límites de contexto han sido relativamente fáciles de manejar. Basta con definir especificaciones y restringir el alcance. Para que un LLM dé buenos resultados, necesita especificaciones claras y una guía firme
    Pero incluso esto no deja de ser el sentido práctico parcheador de hoy. Tal vez dentro de 90 días hasta esa carga desaparezca, y con un solo prompt simple se puedan generar un sistema operativo de clase mundial, un lenguaje de programación y hasta las bases formales matemáticas para ambos

• Está evitando el problema del tamaño del contexto imponiendo una sola restricción simple en el bucle del agente. En el hilo principal de conversación con el usuario bloquea todas las llamadas a herramientas. El trabajo que requiere llamadas a herramientas solo ocurre dentro de invocaciones recursivas del agente, y solo devuelve el resultado al llamador
  Incluso en una base de código de más de 1 millón de LOC, pudo mantener durante todo el día la misma conversación de alto nivel sin acercarse a un límite de tokens significativo. No hacen falta trucos de compresión ni de resumen. Aunque una invocación recursiva queme 50 millones de tokens, el hilo raíz puede quedarse por debajo de los 100 mil
  Sí hace falta volver a “bootstrapear” cada vez que el agente baja otra vez a Narnia, pero aun así es mucho más eficiente que cargar siempre con un gran contexto plano que intente contenerlo todo
  La recursión es muy efectiva para controlar el uso de tokens, pero también tiene límites. Nunca he visto beneficios al pasar de una profundidad de recursión de 1. Vi al agente intentarlo algunas veces, pero el rendimiento real no apareció. Parece que la recursión simbólica externa no es algo para lo que los modelos de punta hayan sido entrenados. Son excelentes simulando recursión dentro del contexto, pero si el objetivo es reducir el uso de tokens, eso va en la dirección contraria

  • Si usas Claude Code, basta con decirle que haga todo el trabajo dentro de un workflow. Tiene herramientas para eso, es una función que salió junto con Opus 4.8, y parece que también maneja mejor las tareas largas
    En ese punto, la conversación principal solo queda como coordinadora de la tarea
  • Tiene sentido intuitivamente. Me da curiosidad qué harness usan para poder imponer esa restricción y cómo la configuran
  • Claude Code parece hacer esto automáticamente en algunos casos. Da la impresión de que tiene una heurística del tipo “esto va a consumir mucho contexto” y decide pasarlo a un subagente
    Lo veo seguido en flujos de resolución de problemas o análisis de datos: manda la recolección y agregación de datos al subagente, y luego solo trae un resumen de los resultados
    De forma parecida, a veces hace que el agente principal mantenga el contexto en documentos de diseño o archivos Markdown y los vaya actualizando mientras avanza. Eso hace posible borrar, reiniciar o transferir en cualquier momento
  • Estoy usando otro enfoque, aunque todavía estoy viendo qué tan bien funciona. En vez de entrar en recursión, cuando el contexto crece demasiado o se atasca, el agente puede pasar por una etapa de resumen/reporte/reflexión, reiniciar el hilo, escribir los hallazgos clave en memoria persistente y volver a redactar el prompt
    Por así decirlo, se parece a una recursión con optimización de llamada de cola
    En cierto sentido es una generalización de un enfoque guiado por especificaciones: además de la especificación formal, queda en memoria un buffer heredado
  • Es interesante porque reducir el contexto y el uso de tokens beneficia al usuario, pero va en contra del interés financiero del proveedor de IA
    Incluso sin ser experto, este “truco sencillo” suena como algo que puede arreglar el problema del contexto y permitir un control mucho más fino del uso de tokens. Gracias por compartir este tip en los comentarios de HN. Puede que esto cambie la forma en que la gente que sabe del tema use agentes de IA en el futuro. Cuesta seguir el ritmo

• Desde que Anthropic ofreció una ventana de contexto de 1 millón de tokens en el plan de suscripción, no he vuelto a tener esta experiencia con Opus. Normalmente paso de 500 mil tokens con frecuencia, y a veces me acerco a 800 mil sin ver este problema
  Sí vi algo cuando me acerqué al límite real, por encima de 900 mil tokens, pero no tan grave como lo que describe el autor
  Para empezar, en una sola tarea o en un grupo de tareas lo bastante relacionadas como para mantener el mismo contexto, rara vez se llena tanto la ventana; por lo general estoy entre 200 mil y 600 mil
  No digo que no haya nadie que lo experimente, pero me resulta raro que para algunas personas sea tan frecuente como para ponerle nombre

  • Veo este tipo de comentario seguido, pero me parece absurdo porque varias veces he visto a modelos Opus cometer errores básicos de recuerdo incluso por debajo de 100 mil tokens
    Personalmente creo que la zona inteligente de Opus está por debajo de 60 mil tokens. Opus 4.7 y 4.8 son peores por el tokenizador más granular
  • Opus 4.6 parecía drogado al pasar de 200 mil, me salté 4.7, 4.8 aguantó bien hasta unas 350 mil, y Fable fue excelente aun por encima de 400 mil en pruebas limitadas
    La calidad parece ir en ascenso
  • No todo el mundo usa el mismo modelo ni el mismo harness, y tampoco usan los modelos de la misma manera
    Cada modelo y versión de modelo usa una arquitectura de atención distinta, y eso afecta el rendimiento en contexto largo. Seguro que también varían la cantidad y el tipo de entrenamiento en contexto extenso
    Cada agente también arma el contexto de forma distinta y difiere en cómo implementa la compresión de contexto
    Si no es el mismo modelo, el mismo agente/harness y tareas muy parecidas, no hay motivo para esperar experiencias iguales con respecto al comportamiento del modelo ante el tamaño del contexto
  • Yo paso de 300 mil con frecuencia y he trabajado incluso con 800 mil, pero definitivamente es un problema observable
    Dependiendo del problema, una ventana de contexto grande puede funcionar, pero me parece más efectivo inclinarse por contextos más chicos, por debajo de 300 mil
  • De acuerdo. La familia Claude ha ido mejorando en este aspecto con cada lanzamiento
    Opus 4.5 empezaba a fallar en las llamadas a herramientas al acercarse al límite de 200 mil, Opus 4.6 llegaba más o menos a 300 mil antes de confundirse, Opus 4.7 podía estirarse hasta alrededor de 400 mil pero después entraba en una zona tonta. En Opus 4.8 tuve sesiones que pasaron cómodamente de 500 mil
    No usé Fable tanto tiempo, pero sí tuve algunas sesiones que llegaron sin problema a 800 mil o 900 mil

• Las versiones recientes de Opus están bien por encima de 100 mil, pero normalmente trato de mantenerme por debajo de 200 mil
  Por eso creo que los llamados sistemas de memoria suelen ser un error que termina volviendo más tonto al modelo. El modelo no tiene memoria, solo tiene contexto, y mientras más hechos irrelevantes le metas en el contexto, menos contexto queda para el problema. Cuanta menos interferencia, mejor sale el resultado
  La forma de hacer que un agente “recuerde” algo es hacer que documente el trabajo igual que lo haría un desarrollador humano al construir un proyecto amable para otros desarrolladores. Guardar en archivos Markdown concisos buena documentación de desarrollo con una página índice y buenos planes con checklists, y hacer commit de eso al repositorio, es la memoria ideal para el modelo y la documentación ideal para entender qué demonios estuvo haciendo el modelo. También ayuda cuando una persona u otro modelo hace code review, y no tiene desventajas

  • Al menos en mi caso, Opus no para de escribir cosas en memoria, pero se olvida sistemáticamente de revisar esa memoria antes de repetir el mismo error
    Entonces “¡acuérdate de revisar la memoria!” vuelve a guardarse en la memoria. Definitivamente no es un sistema que funcione bien
  • Los sistemas de “memoria” son una forma de que los desarrolladores sientan que están contribuyendo a la IA

• Casi todos los comentarios aquí apelan a la experiencia personal. En cambio, el post original hace referencia a dos estudios que comparan el rendimiento en pruebas estandarizadas de varios modelos
  No puedo decir qué tan buenas son esas pruebas, pero difícilmente pueden ser peores que la evidencia anecdótica sobre algo tan ambiguo y subjetivo como el rendimiento de los LLM

  • Para sumar más evidencia anecdótica, en todas las pruebas que he hecho la familia Llama ha sido pésima siguiendo instrucciones. No sé mucho sobre los otros modelos de RULER
    En los resultados de Chroma veo Sonnet 4, y en mi experiencia Sonnet 4 también fue pésimo. El mismo prompt que funcionó perfectamente en Sonnet 4.5 fracasó de forma desastrosa en Sonnet 4
    Me gustaría ver una prueba nueva que incluya tanto los modelos de mayor rendimiento como los modelos de pesos abiertos. Los modelos top siempre parecen seguir mejor las instrucciones y desviarse menos del tema, y estaría bueno tener datos que respalden eso
  • Esos estudios son de 2024 y 2025. No aplican a los modelos actuales de Claude

• Me ha funcionado bastante bien obligar al AI a actuar como gerente de producto y exigirle con fuerza que escriba un PRD corto por cada funcionalidad que vaya a construir
  Así puedo consultar después qué se construyó con el tiempo, y cada funcionalidad tiende a desviarse menos. Mantengo una conversación separada para cada funcionalidad
  Para mí es un punto medio razonable: evita que se descarrile, pero igual le permite consultar decisiones pasadas cuando hace falta. Lo que no me gusta del enfoque de Pocock es que escribe menos PRDs y primero busca alinearse con una discusión profunda, pero en ese ida y vuelta inicial se desperdicia demasiado del mejor tramo

  • Me pregunto si lo haces de manera temporal o si usas un enfoque más estructurado como openspec
    Yo también suelo planear primero, pero eso queda como una lista de pendientes dentro de la sesión y luego es difícil de consultar

• Probablemente, fijarse en lo que pasa dentro del agente no seguirá siendo parte del desarrollo de software por mucho tiempo
  En lo personal, ya veo a los LLM y a los agentes como una caja negra. Le doy cada solicitud de funcionalidad a varios LLM y comparo los resultados. No escribo “sesiones” manualmente. Solo veo el resultado. Si no me gusta, hago git reset --hard, cambio el prompt y vuelvo a empezar la solicitud de funcionalidad
  Dejo logs para ir teniendo una idea continua de qué agente lo hace mejor, y calculo el puntaje ELO del agente que mejor satisface mis requisitos. Lo que me importa es ese puntaje, no tanto cómo lo logró el agente

  • Considerando el costo real de inferencia, esto de verdad suena absurdamente derrochador, y no es algo para presumir
  • Me pregunto qué tipo de proyectos o trabajo de código le encargas
    Supongo que podría estar bien para ciertos tipos de trabajo frontend donde no se necesite mucha seguridad ni otra verificación
    Pero no parece adecuado para industrias reguladas o trabajos donde haya que ser extremadamente cuidadoso
  • ¿Qué modelo va más adelante?

• Sí, gestionar el contexto es la clave
  Estoy creando mi propio framework y dedico mucho tiempo a depurar este problema, y más que el tamaño absoluto del contexto, el problema es la probabilidad de que dentro de la ventana haya basura o instrucciones mal encaminadas que terminen tapando lo que el usuario considera importante
  Esto se manifiesta como que el LLM sigue intentando una y otra vez algo que ya había fallado en el enfoque anterior. Si algo aparece con frecuencia dentro de la ventana de contexto, gana peso aunque esté mal
  También hay muchos trucos, como no darle un montón de herramientas al LLM, sino darle una herramienta para buscar las herramientas que va a usar
  Pero la solución más grande está en el proceso. Usar algo como superpowers para forzar al LLM a ir paso por paso y controlar qué contexto se arrastra hacia adelante

• Hice una extensión personal muy pequeña para Pi para agregar el comando /last. Borra toda la sesión y deja solo el último mensaje de salida del agente
  Eso permite una “compresión” manual. Básicamente, le digo al agente “resume el plan que discutimos junto con las referencias de archivos que hay que editar”, luego llamo a /last y después le indico que implemente
  [1] https://pi.dev/

• No me gusta que aquí se meta todo en la misma bolsa como “modelos”. Cada modelo tiene una arquitectura de atención distinta, y por eso puede haber grandes diferencias en cómo se comporta con contexto largo
  Es cierto que el contexto largo es un problema y que en la mayoría de los modelos hay una caída de calidad, pero no generalizaría sin más el comportamiento de modelos viejos a modelos nuevos