Llevo meses investigando si puedo montar un arnés de pruebas (harness) con modelos de pesos abiertos (open-weight) (de 8B, 16B, 32B parámetros, algunos incluso corriendo en local) que consiga la calidad de Claude Code. No por deporte. Porque si funciona, tienes soberanía total sobre tus datos y costes una fracción de lo que cobran las APIs frontier.
El dolor principal es obvio: estos modelos tienen ventanas de contexto pequeñas. Un codebase mediano no les cabe ni de cerca. Pensé en varias soluciones. RAG, grep, resúmenes. Pero la única que me dio sentido real fue RLM: Recursive Language Models, un paradigma de un paper del MIT.
Así funciona RLM: el contexto no entra en el prompt, vive como variable en un entorno de código.
La idea: en vez de meter todo el contexto dentro del prompt y rezar para que el modelo no se pierda, el contexto vive como una variable en un entorno de programación. El modelo escribe código para inspeccionarlo, filtrarlo y descomponerlo. Y puede lanzar sub-modelos sobre fragmentos específicos.
No es RAG. No es una ventana de contexto (context window) más grande. Es el modelo decidiendo programáticamente qué necesita ver.
El paper oficial dice que RLM no es ideal para modelos pequeños. Pero ya sabes. Tenía que probarlo yo.
A partir de esta investigación publiqué un post en LinkedIn, vi lo que decían otros (buenos análisis de Brainqub3 y Neural Breakdown sobre el mismo paper), y diseñé un benchmark formal. Aquí están los resultados.
Spoiler: me sorprendieron.
Primero, el contexto rápido
Los agentes de código (coding agents) de hoy ya resuelven esto en la práctica. Claude Code, Codex, Cursor, todos le dan al modelo una terminal con grep, ripgrep, find, cat. El modelo busca lo que necesita, lee bajo demanda, y funciona. Pero todos dependen de modelos frontier y APIs caras, que es exactamente lo que yo quiero evitar.
Entonces la pregunta real es doble: ¿puede RLM hacer algo que la terminal no puede? Y si puede, ¿lo consigue con modelos pequeños?
Para responder eso, monté un benchmark con tres brazos:
Volcado directo (vanilla). Metes todo el código que quepa en el prompt, truncando el resto. Sin herramientas, sin navegación. El modelo solo ve lo que le cabe.
Agente con terminal (Pi). Un coding agent minimalista: system prompt lo justo, tools lo justo. Tiene bash y read, nada más. Lo elegí precisamente por eso: si el agente más espartano ya compite, el argumento es más fuerte.
RLM. La técnica del paper del MIT. El contexto se carga como variable en un REPL. El modelo lo navega con código y puede invocar sub-modelos sobre trozos del corpus. El contexto nunca entra entero en la ventana del modelo raíz.
Los tres paradigmas que comparé. Mismo modelo, mismas preguntas, distinta forma de acceder al código.
Lo que me pasó antes de llegar a resultados limpios
Esto no fue un camino recto. La librería rlms de pip tenía una API confusa donde los sub-modelos caían a gpt-3.5-turbo si no configurabas parámetros que no estaban documentados. Los tokens de razonamiento (thinking tokens) de Qwen3.6-27B (<think>...</think>) rompían el analizador (parser) del REPL. OpenRouter me cortaba por exceso de peticiones (rate limit) en medio de las ejecuciones. Después de mucha prueba y error, con mi compañero que tocaba ese día (Claude Code, usando Opus 4.6 para pensar la arquitectura y Opus 4.8 para el diseño y las pruebas), cambié a fast-rlm y empecé de cero más de una vez.
Uno de los muchos intentos fallidos. Los thinking tokens de Qwen rompían el analizador del REPL.
Cuento esto porque importa. Si alguien te muestra resultados de RLM sin mencionar que montarlo es significativamente más complejo que darle una terminal a un modelo, te está contando solo la mitad de la historia. O eso, o soy el único al que le costó tanto montarlo.
Lo que descubrí: la complejidad de la tarea decide el ganador, no la herramienta
Esto fue el hallazgo más valioso de todo el experimento. Diseñé tareas en tres niveles de complejidad computacional:
Constante. Aguja en un pajar (needle in a haystack). “¿Dónde se define X?”, “¿Cuál es el default de Y?”. Un dato puntual.
Lineal. Hay que procesar la mayoría del input. “Lista todas las opciones de configuración del CLI.”
Cuadrática. Relaciones entre entidades dispersas. “¿Qué archivos de src/ no tienen test?” Cruzar cada elemento contra todos los demás.
Usé el mismo modelo en los tres brazos (kimi-k2.6 vía OpenRouter) para comparar paradigmas, no modelos. El codebase fue repomix: 1037 archivos, 1.13 millones de tokens. Verdad base (ground truth) verificada mecánicamente con F1 sobre conjuntos, no “a ojo”.
Primera prueba: ¿puede un modelo barato con RLM igualar a uno caro?
Antes del cara a cara entre los tres paradigmas, hice una prueba más simple. Puse a un modelo barato (Qwen) a orquestar solo con RLM contra un modelo caro (kimi) con todo el contexto metido directamente. Diez preguntas factuales y dos de síntesis.
Resultado: el modelo barato con RLM acertó las diez preguntas factuales y llegó al 80% de la calidad de síntesis del modelo caro, por una novena parte del coste. Y lo más raro: cuando puse al modelo caro como orquestador de RLM, salió peor. 3x más caro y 5x más lento que el barato haciendo lo mismo.
Esto confirmó lo que dice el paper del MIT: RLM permite que modelos pequeños trabajen con contextos que normalmente no podrían manejar. Prometedor. Pero faltaba la prueba de fuego: ¿qué pasa cuando le añades un agente con terminal a la comparación?
El cara a cara: los tres paradigmas
Mismo modelo en los tres brazos (kimi-k2.6), tareas en los tres niveles de complejidad, F1 verificado.
| Complejidad | vanilla | Pi (terminal) | RLM |
|---|---|---|---|
| constante (needle) | 1.00 | 1.00 | 1.00 |
| lineal (enumerar) | 0.97 | 0.97 | 0.97 |
| cuadrática (cross-ref) | 0.00 | 0.72 | 0.70 |
Coste total (6 tareas): Pi $0.16 · RLM $0.51 · vanilla $1.09.
Lo que significa, nivel por nivel
Constante: empate total, Pi gana por goleada en coste. Los tres aciertan al 100%. Pero Pi costó ~$0.004 por tarea. RLM $0.04. Vanilla $0.18 (porque reenvía 212K tokens en cada pregunta). Para buscar un dato puntual, grep en un turno es imbatible. RLM es excesivo (overkill).
Lineal: empate en todo. Los tres sacaron ~0.97. Siendo honesto: nuestras tareas lineales (listar los 49 flags del CLI, las opciones de config) resultaron estar concentradas en 1-2 archivos que caben en la ventana. No forzaban a leer el repo entero. Por eso no discriminaron. Un test lineal de verdad requeriría agregar información dispersa por cientos de archivos. Queda pendiente.
Cuadrática: la sorpresa que rompió mi hipótesis. Yo iba esperando que solo RLM pudiera con la referencia cruzada (cross-reference) masiva. Me equivoqué.
Vanilla se fue a 0.00 (no puede cruzar lo que no ve). Pero Pi sacó 0.72 y RLM 0.70. Prácticamente empatados. En la tarea “¿qué archivos src/ no tienen test?”, Pi sacó F1 perfecto: 1.0. RLM sacó 0.99. Vanilla: 0.0.
¿Por qué ganó Pi una tarea “cuadrática”? Porque con bash escribió un script. Listó src/, listó tests/, y computó la diferencia de conjuntos. No grepea la respuesta. La calcula.
Entonces, ¿para qué sirve RLM?
El diferenciador real es ejecutar código sobre el corpus, no el paradigma concreto. Vanilla se hunde a 0 en cuadrática porque solo recibe texto pasivo. Los otros dos ganan porque ambos pueden computar sobre el corpus: RLM vía su REPL, Pi vía su terminal. Son la misma capacidad esencial (navegación programática sobre los datos) servida de dos formas. El bash de un agente de código ya es el 80% de lo que RLM ofrece.
En mis pruebas de código, RLM no superó al agente con terminal en ningún nivel. Y costó más. Empató en constante y lineal, empató (ligeramente por debajo) en cuadrática, y fue 3x más caro que Pi en el conjunto.
Pero el nicho de RLM existe. Tareas cuadráticas y semánticas sobre corpus de 6-11 millones de tokens que ni caben en la ventana ni se reducen a operaciones de shell. “¿Cuáles de estas 900 funciones son semánticamente equivalentes aunque con nombres distintos?” No hay keyword. No es automatizable con script. Requiere entender significado. Para eso, los sub-modelos recursivos de RLM procesan lo que grep no puede leer y la ventana no puede sostener.
Lo que cambió en mi cabeza
Empecé este experimento con la esperanza de que RLM me iba a resolver un problema concreto: que mis modelos pequeños, con ventanas de contexto limitadas, pudieran entender codebases grandes sin depender de APIs caras.
Los resultados me dejaron con dos conclusiones que parecen contradictorias pero no lo son.
Primera: RLM sí ayudó a los modelos pequeños. Qwen solo, con el contexto truncado, acertó 8 de 10 preguntas factuales y sacó un 4.0 en síntesis. El mismo Qwen con RLM acertó las 10 y subió a 6.0, por menos dinero. Para mi objetivo original, eso es un dato real y prometedor.
Segunda: cuando enfrenté los tres paradigmas con un modelo capaz (kimi-k2.6), el agente con terminal empató con RLM en todo y costó 3x menos. Para un modelo que ya tiene capacidad suficiente, la terminal cubre lo que RLM ofrece.
Lo que no probé, y es la pregunta que queda abierta, es darle una terminal a ese mismo modelo pequeño. No sé si la mejora de Qwen vino de RLM específicamente, o si cualquier forma de navegar el contexto (incluida una terminal) le habría dado el mismo salto. Queda pendiente.
El proceso me enseñó algo que no esperaba: lo que importa no es el paradigma sino si el agente puede ejecutar código sobre los datos. Y me mostró que hay un territorio real (razonamiento semántico masivo sobre corpus enormes, análisis legal profundo, síntesis documental corporativa) donde RLM desbloquea cosas que hoy no puedes hacer de otra forma.
No encontré exactamente lo que buscaba. Encontré algo más útil: un mapa de cuándo usar cada herramienta, y una pregunta nueva que vale la pena responder.
Semanas de trabajo condensadas en una tabla. A veces lo que encuentras es mejor que lo que buscabas.
Limitaciones (para que leas esto con honestidad)
No quiero que nadie tome estos números como definitivos. Hay cosas que sé que no cubrí:
La escala fue de 1.13M tokens. Apenas supera las ventanas actuales. No alcancé el régimen de 6-11M donde RLM debería despegar. El coste era prohibitivo para este estudio.
El nivel lineal no discriminó porque las respuestas estaban concentradas en pocos archivos. Un test lineal real necesita información dispersa por todo el repo.
Las tareas cuadráticas eran automatizables con script (referencia cruzada de nombres de archivo). Las cuadráticas semánticas (el nicho de RLM) quedan pendientes.
Usé un solo modelo (kimi-k2.6) y n pequeño. Los números son direccionales, no definitivos.
Reproducibilidad
Todo el arnés de pruebas, los datos crudos de las corridas publicadas y la verdad base congelada están en aleksandarlabs/rlm-benchmark.
Para reproducirlo con el mismo corpus (repomix):
git clone https://github.com/aleksandarlabs/rlm-benchmark.git
cd rlm-benchmark
git clone https://github.com/yamadashy/repomix.git corpus
cp examples/questions-repomix-exp1.json questions/questions.json
cp examples/questions-repomix-exp2.json questions/questions-complexity.json
python benchmark/corpus.py
python benchmark/run_bench.py --condition rlm-all-small
python benchmark/compare.py
python benchmark/run_complexity.py --limit-per-tier 1
python benchmark/run_complexity.pyClaves necesarias (en .env): GROQ_API_KEY, OPENROUTER_API_KEY. El brazo Pi requiere el CLI pi instalado.
Este estudio nació de un problema práctico: hacer que modelos pequeños sean útiles programando sobre codebases que no les caben en la ventana. RLM parecía la respuesta. Resultó ser parte de la respuesta, pero no la que esperaba. Y la pregunta que me queda es mejor que la que tenía al empezar.
AleksandarLabs · julio 2026