- Satoshi Nakamoto
- 22 hours ago
- 9 min read
Un nuevo trabajo de Voltropy propone una arquitectura de memoria para modelos de lenguaje llamada LCM, o Lossless Context Management, con la que su agente Volt logró superar a Claude Code en pruebas de contexto largo. La propuesta apunta a uno de los grandes cuellos de botella de la IA actual: cómo conservar, resumir y recuperar información sin degradar el rendimiento cuando las sesiones se extienden durante horas, días o millones de tokens.
***
Voltropy presentó LCM, una arquitectura determinista de memoria para agentes de IA que conserva acceso recuperable a todo el historial.
En pruebas sobre OOLONG con Opus 4.6, el agente Volt superó a Claude Code desde los 32.000 tokens hasta 1 millón de tokens.
El sistema combina compresión jerárquica, recuperación con punteros sin pérdidas y herramientas paralelas como LLM-Map y Agentic-Map.
La gestión de memoria sigue siendo uno de los problemas centrales para los modelos de lenguaje de gran escala. Aunque varios sistemas comerciales ya anuncian ventanas de contexto de más de 1 millón de tokens, el reto práctico no desaparece cuando una sesión acumula archivos, resultados de herramientas, decisiones intermedias y cadenas largas de razonamiento.
En ese escenario se ubica LCM: Lossless Context Management, un trabajo firmado por Clint Ehrlich y Theodore Blackman, de Voltropy PBC, fechado el 14 de febrero de 2026. El documento describe una arquitectura de memoria determinista para agentes de IA y asegura que su integración en el agente de programación Volt permitió superar a Claude Code en tareas de contexto largo.
La idea central del paper es que el manejo del contexto no debería quedar enteramente en manos del modelo. En lugar de pedirle a la IA que escriba por sí sola scripts, bucles o estrategias para resumir su historial, LCM traslada esa responsabilidad al motor del sistema, que administra la memoria con reglas fijas, almacenamiento persistente y recuperación trazable.
Según los autores, ese enfoque no solo mejora la confiabilidad en producción, sino que también evita penalizaciones de costo y latencia en tareas cortas. En términos simples, el sistema no activa su maquinaria de compresión y recuperación hasta que el contexto realmente lo exige.
Qué es LCM y por qué busca resolver un cuello de botella crítico
El paper parte de una observación conocida en la industria: el contexto efectivo de un modelo suele ser menor que su límite nominal. Incluso cuando un proveedor promete ventanas enormes, el rendimiento puede deteriorarse antes de llegar al máximo. Los autores citan este fenómeno como “context rot”, o deterioro del contexto.
Frente a ese problema, LCM se presenta como una extensión y a la vez una reinterpretación de la idea de Recursive Language Models, o RLM. Ese paradigma había planteado que el modelo puede gestionar activamente su propio contexto, tratándolo como parte de un entorno externo y no como una entrada fija.
Voltropy sostiene que esa intuición era valiosa, pero también arrastraba una debilidad importante. Si el modelo tiene que escribir los bucles y scripts que administran su memoria, el sistema hereda la variabilidad de cada ejecución. Una estrategia puede salir bien en un intento y peor en el siguiente.
LCM toma el camino opuesto. En vez de máxima libertad para el modelo, ofrece un conjunto acotado de mecanismos manejados por el motor. Los autores comparan esa decisión con el paso histórico de instrucciones GOTO al control de flujo estructurado en programación: menos expresividad teórica, pero más previsibilidad en la práctica.
El sistema se apoya en una arquitectura de memoria de doble estado. Por un lado está el “Immutable Store”, que conserva de forma textual e inmutable cada mensaje del usuario, respuesta del asistente y resultado de herramientas. Por otro lado está el “Active Context”, que es la ventana real enviada al modelo en cada turno.
Cuando el contexto crece, los mensajes antiguos se reemplazan por nodos de resumen dentro de un DAG jerárquico, es decir, un grafo acíclico dirigido. Sin embargo, esos resúmenes mantienen punteros estables a los originales, de modo que el historial completo pueda recuperarse después mediante herramientas específicas como lcm_grep o lcm_expand.
Cómo funciona la compresión sin pérdidas y el manejo de archivos grandes
Los autores usan el término “lossless”, o sin pérdidas, en un sentido preciso. No quieren decir que el modelo siempre recuerde todo por sí solo, sino que el sistema retiene los originales intactos y permite navegar hacia ellos. En otras palabras, el resumen puede ocultar temporalmente detalles, pero no destruye el contenido fuente.
Eso diferencia a LCM de varios enfoques comunes. Un archivo plano completo con búsquedas por coincidencia exacta puede conservar la verdad de base, pero sirve poco para consultas abiertas, como preguntar qué decisiones arquitectónicas se han tomado hasta ahora. A su vez, una estrategia de búsqueda semántica basada en embeddings puede encontrar fragmentos relevantes, pero suele devolverlos fuera de su contexto conversacional.
El DAG jerárquico intenta combinar ambos mundos. Los nodos de resumen actúan como un mapa multinivel de la historia de la sesión, mientras que los punteros permiten bajar a detalles concretos cuando hace falta. El paper señala que un índice por embeddings podría añadirse en el futuro, aunque no fue necesario para sus pruebas.
La compresión del contexto opera con dos umbrales de tokens. Si la sesión supera un umbral blando, el sistema inicia una compactación asíncrona sin bloquear al usuario. Si rebasa un umbral duro, el motor sí detiene la interacción hasta resumir los bloques más antiguos y volver a entrar en rango.
LCM también presta especial atención a los archivos de gran tamaño, un problema frecuente en agentes de programación. Si un archivo es pequeño, entra al contexto como de costumbre. Si rebasa un umbral de tokens, el motor guarda solo una referencia compacta con un ID, la ruta del archivo y un “Exploration Summary” generado según el tipo de contenido.
Ese resumen de exploración cambia según el formato. Un JSON, CSV o base SQL recibe extracción de esquema y forma. Un archivo de código recibe análisis estructural, como firmas de funciones o jerarquías de clases. Un texto no estructurado se resume con ayuda del modelo. Así, el agente conserva conciencia de los archivos sin saturar su ventana.
El trabajo aclara que el contenido completo de esos archivos grandes no se duplica en la base del sistema. Solo se conserva la referencia a la ruta en disco, porque en sesiones reales de producción puede haber registros, datasets o artefactos de compilación de decenas de gigabytes. La manipulación detallada queda en manos de las herramientas normales de sistema de archivos.
Por qué LCM insiste en la convergencia garantizada y en la continuidad sin costo
Uno de los riesgos más incómodos en agentes autónomos es el fallo de compactación. Puede ocurrir que se le pida a un modelo resumir un texto y, contra toda intuición, produzca una salida más larga que la entrada. Cualquier sistema que dependa de esa operación necesita un plan de contingencia.
LCM lo resuelve con un protocolo de tres niveles. En el primer nivel usa un resumen pensado para preservar detalles. Si eso no reduce tokens, pasa a un nivel más agresivo basado en viñetas. Si tampoco funciona, cae a una truncación determinista de 512 tokens sin usar el modelo.
Los autores subrayan que ese tercer escalón garantiza convergencia. Puede ser menos elegante, pero impide que el sistema entre en un ciclo donde intenta resumir sin éxito y consume todavía más contexto. En entornos de producción, ese tipo de garantía suele pesar tanto como la calidad promedio del resumen.
Otro rasgo importante es lo que el paper llama “Zero-Cost Continuity”. La idea es que, por debajo del umbral blando, no hay resumen ni recuperación adicional. El almacén solo registra la sesión en segundo plano, mientras el usuario percibe la latencia normal del modelo base.
Solo cuando el contexto crece lo suficiente entra en juego la lógica de compresión. Incluso entonces, la mayor parte del tiempo sucede entre turnos y de forma asíncrona. El documento afirma que el usuario solo notaría latencia extra en una sucesión muy rápida y pesada de prompts y llamadas a herramientas que supere el umbral duro durante una ventana aproximada de 25 segundos.
La otra garantía destacada es la recuperabilidad determinista. Cada vez que se compacta un bloque, el motor inserta automáticamente los identificadores del contenido resumido junto al texto del resumen. Eso permite que cualquier mensaje anterior siga siendo recuperable mediante lcm_expand, sin depender de que el modelo “recuerde” por su cuenta que hubo compactación.
Volt, map paralelo y el giro desde la recursión simbólica hacia operadores administrados
LCM fue implementado dentro de Volt, un agente terminal de programación presentado como vista previa de investigación de código abierto. Volt se basa en OpenCode, un agente también abierto y agnóstico al proveedor, construido con arquitectura cliente-servidor en TypeScript y una interfaz de terminal.
La integración, según el paper, reemplaza la gestión de sesión por defecto de OpenCode, pero no exige cambios en la definición de herramientas ni en el formato del prompt. El bucle de control de contexto y la escalada de resumen corren dentro del pipeline de procesamiento de mensajes.
Más allá de la memoria, los autores también proponen pasar de la “recursión simbólica” a la “recursión a nivel de operador”. En vez de que el modelo escriba bucles en Python o Bash para recorrer lotes de datos, Volt le ofrece dos herramientas: LLM-Map y Agentic-Map.
LLM-Map aplica un prompt a cada elemento de una lista en paralelo, como llamadas independientes al modelo. Agentic-Map hace algo similar, pero en vez de una llamada simple lanza un subagente completo por elemento, con acceso a lectura de archivos, ejecución de código y otras herramientas.
En ambos casos, el motor administra iteración, concurrencia, reintentos y validación de salida contra un esquema JSON. El modelo solo indica qué quiere hacer con cada elemento y qué forma debe tener la respuesta. Según Voltropy, eso reduce errores de implementación y evita que el contexto del modelo se llene con datasets enormes.
El paper añade que las entradas y salidas de estas operaciones viven fuera del contexto activo, en archivos JSONL sobre disco. Ese detalle permite procesar volúmenes arbitrariamente grandes sin contaminar la ventana del modelo. Además, el almacenamiento persistente usa estados como pendiente, en ejecución, completado o fallido, con bloqueo pesimista para reclamar tareas y semántica de ejecución exactamente una vez, salvo reintentos por error.
También se incorpora una protección contra delegación infinita. Si un subagente quiere crear otro, debe especificar qué porción exacta del trabajo delega y cuál retiene. Si intenta delegar toda su responsabilidad, el motor rechaza la llamada. Así, cada nivel de anidamiento tiene que reducir estrictamente su alcance.
Resultados frente a Claude Code y límites del benchmark OOLONG
La evaluación se realizó con el benchmark OOLONG, en su división trec_coarse, orientada a medir razonamiento y agregación en contexto largo. El trabajo compara a Volt con LCM contra Claude Code v2.1.4, un agente CLI con acceso nativo a sistema de archivos y herramientas, y usa Opus 4.6 como modelo principal de razonamiento en ambos casos.
Según los autores, tanto Volt como Claude Code tuvieron además acceso a Claude Haiku 4.5 para subtareas ligeras de alto rendimiento, como clasificación por elemento. La intención fue aislar las diferencias arquitectónicas y no sesgar el resultado por acceso desigual a modelos auxiliares.
En promedio, Volt obtuvo una puntuación absoluta de 74,8 frente a 70,3 de Claude Code. Eso representa una ventaja de 4,5 puntos. Frente a Opus 4.6 sin andamiaje agentico, Volt mostró una mejora promedio de 29,2 puntos, mientras Claude Code registró 24,7.
En contextos cortos, de 8.000 y 16.000 tokens, el desempeño fue parecido. Claude Code tuvo una ligera ventaja a 8.000 tokens, con una mejora de 13,1 puntos contra 11,2, y también a 16.000, con 26,3 frente a 25,0. Sin embargo, desde 32.000 tokens Volt superó a Claude Code en cada longitud evaluada hasta 1 millón de tokens.
El diferencial se amplió especialmente más allá de 131.000 tokens. A 256.000, Volt llevó una ventaja de 10,0 puntos, con 18,5 frente a 8,5. A 512.000, la brecha fue de 12,6 puntos, con 42,4 frente a 29,8. A 1 millón de tokens, Volt mantuvo una diferencia de 4,3 puntos, con 51,3 contra 47,0.
El documento afirma que Opus 4.6 sin arquitectura auxiliar cayó por debajo de 20 puntos en los mayores tamaños de contexto. Para los autores, eso refleja dos regímenes distintos: en ventanas cortas, ambos agentes pueden trabajar con el contexto completo; en ventanas largas, la diferencia aparece porque Claude Code depende más de que el modelo improvise su estrategia de fragmentación, mientras Volt delega esa lógica al motor con operadores paralelos.
Aun así, el paper reconoce una limitación importante. Durante la evaluación, los investigadores detectaron contaminación de datos en OOLONG. En algunos casos, Opus 4.6 parecía reconocer el dataset subyacente y responder desde memoria paramétrica, sin ejecutar la agregación requerida. Por eso excluyeron tareas donde los rastros de razonamiento evidenciaban memorizar la respuesta.
Los autores sostienen que, incluso tras esa descontaminación, la conclusión general no cambia y Volt sigue superando a Claude Code, aunque con una brecha menor. También proponen avanzar hacia evaluaciones generadas proceduralmente, capaces de producir contextos y tareas nuevas al vuelo para reducir el riesgo de que futuros modelos ya hayan visto el benchmark durante entrenamiento.
En conjunto, el trabajo de Voltropy plantea una discusión relevante para el diseño de agentes de IA. En vez de apostar todo a que los modelos aprendan a autogestionar su memoria con total autonomía, sugiere que todavía hay espacio para arquitecturas más opinadas, con reglas fijas, mejor trazabilidad y menor fragilidad en entornos de producción.
Imagen original de , creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público
Este artículo fue escrito por un redactor de contenido de IA
