No confíes en las ventanas de contexto grandes

Experiencia con ventanas de contexto grandes

• Fuerte desacuerdo sobre la gravedad y el umbral de la “zona tonta”.
  • Algunos ven una degradación clara una vez que el contexto supera ~10–20% de la ventana (p. ej., 100–200k en una ventana de 1M), con más errores de recuerdo y rutas “contaminadas” de las que es difícil recuperarse.
  • Otros informan un comportamiento estable mucho más allá de 300–500k, incluso 700–900k tokens, y dicen que rara vez piensan en el contexto en absoluto.
• Muchos describen el rendimiento como altamente dependiente de la tarea: el “trabajo de fontanería” simple o las ediciones localizadas toleran mejor las sesiones largas que las refactorizaciones complejas y holísticas.
• Varios señalan que la calidad y la consistencia del contexto pueden importar más que la longitud bruta; los “restos”, las instrucciones en conflicto y los intentos fallidos repetidos parecen envenenar el razonamiento posterior.

Estrategias de gestión del contexto

• Patrón común: mantener las conversaciones de nivel superior cortas y descargar el trabajo en subagentes, flujos de trabajo o llamadas recursivas que tengan sus propios contextos frescos.
• Otros hacen reinicios periódicos: resumen el plan o el estado actual en markdown (AGENTS.md, DESIGN, ROADMAP, etc.), empiezan una sesión nueva a partir de eso y continúan.
• Algunos imponen límites duros (p. ej., 15–20% de la ventana, 200–400k tokens), umbrales de compactación automática o comprobaciones tipo “no brown M&Ms” (p. ej., fallar si el modelo olvida un comando de compilación personalizado).
• Una minoría minimiza agresivamente el contexto: una conversación por funcionalidad, compactación manual estilo “/last”, o insistir en documentos de diseño/PRD antes de programar.
• Varios argumentan que los documentos externos en el repositorio son mejor “memoria” que meter hechos en el contexto vivo o en sistemas de memoria propietarios, que pueden almacenar datos incorrectos o desactualizados.

Diferencias de modelo, harness y muestreo

• El comportamiento varía según la versión del modelo y las herramientas. Algunos informan que los modelos más antiguos o más baratos se degradan antes; modelos frontier más nuevos y ciertas herramientas (p. ej., frameworks de agentes, flujos de trabajo) mejoran la fiabilidad a largo plazo.
• Se citan los mecanismos de atención, la granularidad del tokenizer y las estrategias de muestreo (p. ej., muestreadores “modernos” como min_p) como posibles razones de que las experiencias diverjan, pero esto sigue siendo anecdótico.

Coste, UX e incentivos de los proveedores

• Un grupo ejecuta múltiples agentes en paralelo y los puntúa (p. ej., estilo ELO) a pesar del alto uso de tokens, argumentando que el resultado y el ahorro de tiempo dominan el coste.
• Otros consideran esto un despilfarro y hacen hincapié en el caching de prompts, las actualizaciones incrementales y un alcance más estricto para reducir tokens.
• Muchos siguen viendo las ventanas de 1M de tokens como una gran mejora de UX, incluso si no siempre se usan de forma segura.

Rigor, benchmarks e incertidumbre

• Varios critican que la discusión es en gran medida consejo anecdótico de “jardinería” y piden evaluaciones sistemáticas que precarguen contexto antes de pruebas estandarizadas.
• Otros responden que el rápido relevo de modelos dificulta los benchmarks estables y actualizados, por lo que los practicantes se apoyan en heurísticas cambiantes.