Tu contexto está casi lleno, Hermes empieza a compactar, y te quedas mirando el spinner durante 10 minutos enteros. No es la red — la antigua “lean compaction” llamaba al modelo aux una vez por cada fragmento de historial para construir digests, así que una sesión grande podía requerir hasta 28 llamadas aux secuenciales, y en una ruta aux lenta (digamos gpt-5.6 con esfuerzo de razonamiento alto como modelo de resumen) una compactación significaba 7-11 minutos de agonía (issue #96603). Un cambio integrado el 30 de agosto (PR #98628) elimina ese bucle de digests por completo: exactamente una petición aux por intento de compactación. El cambio está en main, aún sin publicar en una release.

Por qué la compactación era tan lenta

La “lean compaction” es el pipeline de compresión que se convirtió en el predeterminado en v0.20.6; su trabajo es condensar un historial largo en un resumen de session-log. El problema era el modelo de ejecución: la implementación antigua dividía el historial en fragmentos y hacía una llamada al modelo aux por fragmento para generar un digest, y después cosía los digests entre sí. Con muchos fragmentos, esas llamadas son secuenciales — hasta 28 peticiones aux por intento, cada una esperando a que el modelo emita tokens en streaming. Con un modelo rápido era solo lento; con un modelo aux lento era catastrófico (7-11 minutos medidos en #96603).

La corrección: un fragmento, una petición

La directiva del mantenedor fue contundente: “one chunk, one request” (un fragmento, una petición). En concreto:

• El bucle de digests ha desaparecido: la petición de resumen principal ahora absorbe las tareas del session-log (las mismas reglas estrictas — identificadores verbatim, viñetas densas, transcripción-es-datos), con un presupuesto de tokens de respuesta única elevado;
• Regiones sobredimensionadas: las entradas demasiado grandes se muestrean de forma uniforme con marcadores explícitos [... elided ...] — nunca una segunda petición;
• Las salvaguardas no cambian: el anchor index sin LLM (que cubre la región completa) y el pie de recuperación de session_search se quedan exactamente como estaban — las evaluaciones oficiales muestran que el anchor index, no los digests por fragmento, era lo que impulsaba el recuerdo de hechos-aguja (23.3 → 60.0 en la pista GUI).

Los números: 5 veces más rápido, y también más ligero

El A/B oficial se ejecutó sobre una sesión grande real (1,338 mensajes, ~499,625 tokens, llamadas aux reales):

Métrica	Antes (bucle de digests)	Ahora (una sola petición)
Llamadas aux	19 (1 resumen + 18 digests)	1
Tiempo de pared	196.5s	39.6s
Tokens después	57,567	46,135

5 veces más rápido en una ruta rápida; en rutas lentas (el escenario de #96603) pasa de 7-11 minutos a aproximadamente una llamada de resumen. El resultado post-compactación además es ~11K tokens más ligero — el antiguo muro de digest de 81K caracteres viajaba en cada petición posterior; ahora ha desaparecido. Nueve tests nuevos fijan el contrato de exactamente-una-llamada (restaurar una segunda llamada los pone en rojo).

Qué significa esto para ti

Si trabajas con sesiones muy largas con regularidad, la sensación de la compresión pasa de “tiempo de tomar un café” a “un sorbo de agua”. Y como el resultado es más ligero, cada turno posterior también ahorra tokens. Combínalo con nuestra guía de la compresión lean-tail por defecto y la guía de optimización de tokens de contexto para el manual completo de ahorro de tokens; recuperar hechos clave después de la compactación está cubierto en la guía de anclaje del uso de contexto.

Cuándo puedes usarlo

El PR #98628 se integró el 30 de agosto y no está en v0.20.6 (etiquetada el 27 de agosto). Haz pull de la última main para probarlo, o espera a la próxima release. Los usuarios intensivos que han vivido “la compactación tarda 10 minutos” deberían actualizar cuanto antes.

En resumen: la lentitud estaba en las llamadas secuenciales del bucle de digests por fragmento; ahora es una petición y listo — 5 veces más rápido, menos tokens y las capacidades de recuerdo intactas.