Co-escrito con @VaishShrivas
Les enseñamos a los agentes CLI a predecir las respuestas del terminal durante RL, junto con la pérdida GRPO habitual en las acciones. El cambio es mínimo: mismo rollout y forward pass, pero dejamos de enmascarar los tokens de salida del terminal. El efecto es enorme: todas las evaluaciones mejoran y los modelos resultantes aprenden de forma medible cómo se comporta el terminal.
¡Los agentes CLI pueden aprender un modelo del terminal gratis y usarlo para actuar mejor!
Esto es ECHO: un objetivo híbrido que entrena en ambos lados de la interacción: lo que el agente escribe y lo que el terminal responde.
Consulta el artículo completo y el código basado en SkyRL.
Si no tienes tiempo para leer todo el post, esto es lo que encontramos:
- El RL estándar de agentes descarta la respuesta del entorno. GRPO entrena en los tokens de acción y enmascara las respuestas del terminal, aunque ya están en el contexto, ya pasan por el modelo y son señales de verdad fundamental sobre cómo las acciones del agente afectaron al entorno.
- ECHO soluciona esto entrenando en ambos lados de la interacción. Mantiene la pérdida GRPO habitual en los tokens de acción y añade una pérdida simple de entropía cruzada del entorno en los tokens de salida del terminal. Son unas pocas líneas de código sobre cualquier entrenador GRPO. Mismo rollout y forward pass, solo una máscara diferente sobre los logits.
- ¡ECHO funciona y es gratis! ECHO mejora Qwen3-8B, OpenThinker-Agent-v1-SFT y Qwen3-14B en todos los benchmarks que probamos. ECHO también entrena hasta 2.3 veces más rápido para alcanzar el mismo rendimiento. TerminalBench-2.0 pass@1 casi se duplica tanto en 8B (2.7 → 5.2) como en 14B (5.2 → 10.8).
- ¡ECHO enseña dinámicas del terminal! En trayectorias no vistas, la entropía cruzada de los tokens del entorno disminuye drásticamente con ECHO y apenas se mueve con GRPO simple. Evidencia directa de que ECHO le enseña al modelo cómo responde realmente el terminal. Los mismos checkpoints que predicen mejor las salidas del terminal también resuelven más tareas.
- ECHO puede sustituir a un profesor experto. Desde un Qwen3-8B base sin demostraciones de expertos, ECHO casi iguala lo que GRPO logra después de SFT con demostraciones de expertos.
- ¡ECHO permite que los agentes se auto-mejoren sin recompensas de verificador! Sin ninguna recompensa de verificador, ECHO (sin ningún GRPO) permite que el agente mejore aún más simplemente actuando en el entorno y prediciendo lo que sucede.
Todo empezó con una pregunta simple: si cada comando produce una respuesta del terminal, ¿por qué RL entrena solo en el comando?
Vaish hizo todo el trabajo para descubrirlo. Yo contribuí con un experimento tonto de laberinto*, una opinión firme sobre el título y decir "¡santo cielo!" cuando me mostró el primer resultado. Gracias a Ahmed Awadallah por darnos el espacio — y las GPUs — para perseguir ideas como esta, incluso cuando comienzan como una simple curiosidad de investigación.
Vale la pena mencionar: la primera ejecución en clúster para ECHO se lanzó el 29 de marzo 😊
Este trabajo se realizó en AI Frontiers, un laboratorio de investigación boutique dentro de Microsoft Research.
¿Cómo aprendes continuamente?
La primera vez que surgió esta idea fue motivada por una pregunta simple sobre la auto-mejora y el aprendizaje continuo. ¿Cómo mejora un agente simplemente actuando en el mundo?
Vaish y yo habíamos estado hablando desde el otoño pasado sobre la auto-mejora en agentes CLI, es decir, qué significaría mejorar a partir de la interacción con el entorno (también conocido como el terminal), especialmente sin un verificador.
El RL sin verificador es un problema en el que la gente ha trabajado durante años, y la mayoría de los intentos enfrentan el mismo problema: ¿de dónde viene la supervisión si no hay recompensa?
Más o menos al mismo tiempo, un tuit tonto mío llevó a una llamada con @willccbb discutiendo nuevamente el aprendizaje continuo. Durante esta charla, recuerdo haber dicho algo tonto como esto:
Quizás el aprendizaje continuo sea entrenar en lo que sea que el entorno te devuelva como respuesta a tus acciones.
Eso debería enseñarle algo al modelo, ¿verdad?
Resulta que ¡sí!
¡El mundo es una función de pérdida!
Cuando un agente actúa en un entorno, la respuesta del entorno a esa acción siempre es verdadera.
Un ejemplo del mundo físico: si accionas un interruptor de luz, la luz se enciende o no. Si no se enciende, esa es una respuesta legítima: te dice algo sobre la bombilla, el cableado, el disyuntor, etc. De cualquier manera, lo que recibes es una pequeña pieza de información sobre cómo cambió el mundo debido a tus acciones. No estás expuesto al mecanismo completo de cómo funcionan la electricidad, los interruptores y las bombillas, pero sí ves el resultado. ¿Se encendió la luz? Y eso es suficiente para empezar a construir un modelo mental de cómo accionar interruptores enciende las luces.
El terminal funciona más o menos de la misma manera.
La salida después de un comando bash es un pequeño resumen de cómo cambió el estado de la computadora/contenedor después de ejecutar el comando. Ves stdout, stderr, códigos de salida, listados de archivos, etc. No ves el estado del kernel, el árbol de procesos ni nada demasiado detallado.
Lo que ves es una proyección de baja dimensión de lo que sucedió en segundo plano, que es también lo que el agente CLI usará para elegir la siguiente acción hacia la tarea que intenta lograr. Y como con el interruptor de la luz, eso es suficiente señal para construir un modelo mental — o si lo prefieres, un modelo del mundo — de cómo se comporta el sistema.
La mejor parte es que la salida del terminal, que nuevamente es un reflejo de cómo cambió el estado del sistema, es una señal de supervisión, calculada para ti, en cada turno, gratis.
¡Genial!
El problema es que el RL de agentes estándar (por ejemplo, GRPO en SkyRL) empuja los gradientes solo a través de los tokens de acción e ignora los tokens de salida del terminal. A pesar de que la salida del terminal ya está en el contexto. El modelo le presta atención, el forward pass calcula logits para ella, pero el entrenador la enmascara de la pérdida.
¡Qué desperdicio de buenos tokens! 😊
Entonces, ¿qué pasaría si no lo hiciéramos?
El modelo ya está condicionado a esos tokens. Ya produce una distribución de probabilidad sobre ellos. Agregar una pérdida de entropía cruzada no cuesta prácticamente nada.
Y si lo hacemos… el modelo tiene una razón para aprender cómo se comporta realmente el terminal y, por lo tanto, puede construir, dentro de sí mismo, un modelo implícito del sistema en el que está actuando. Para predecir lo que devolverá ls, el modelo tiene que rastrear qué archivos acaba de crear, qué vive dónde, etc.
Como dijo Ilya:
Predecir bien el siguiente token significa que entiendes la realidad subyacente que llevó a la creación de ese token.
En nuestro contexto, eso significaría: un agente que es bueno prediciendo las salidas del terminal ha construido, en un sentido pequeño pero real, un modelo implícito del terminal.
Entonces, ¿cómo logramos que el agente prediga las salidas del terminal?
ECHO: Aprende un modelo del mundo sin pagar por ello
Un rollout de un agente de terminal ya entrelaza dos flujos de tokens: los tokens de acción del agente y los tokens de observación del entorno. GRPO estándar aplica pérdida solo en los tokens de acción.
Esto es especialmente derrochador porque las recompensas del terminal son escasas, retrasadas y binarias. En nuestro entorno con Qwen3-8B, para muchas tareas, menos del 15% de los rollouts on-policy tienen éxito. Pero las trayectorias fallidas no son datos fallidos: todavía contienen listados de archivos, errores, registros, seguimientos de pila, salidas de grep y otras consecuencias de los comandos del agente.
Nuestro método es la forma más vergonzosamente simple de aprender de esas consecuencias 😊
Agregamos una pérdida de entropía cruzada normalizada por longitud en los tokens de observación del entorno, junto con la pérdida GRPO estándar en los tokens de acción. ECHO es el objetivo híbrido:
donde Actions son las posiciones de las acciones del agente y Observations son las posiciones de la salida del terminal.
Algunos detalles técnicos:
- ECHO aprende on-policy. En lugar de entrenar en un conjunto congelado de transcripciones del terminal del modelo base o de un profesor, ECHO aprende de las respuestas del terminal producidas por el modelo actual durante RL. A medida que el agente mejora, explora nuevas partes del entorno y obtiene supervisión fresca de nuevas transiciones acción → observación. Mejores políticas inducen mejor retroalimentación; una mejor predicción de la retroalimentación le da a la política mejores prioridades de acción. ¡Un bucle! ¿Qué divertido?
- En el objetivo conjunto, λ importa. Si es muy pequeño, la pérdida del entorno no moldea mucho el modelo. Si es demasiado grande, la política puede optimizar para salidas predecibles en lugar del progreso de la tarea. ¡Hay que equilibrarlo!
- Los tokens objetivo importan. Entrenamos en la salida real del terminal, no en advertencias del harness. Las advertencias son fáciles de memorizar; la señal útil es la respuesta real del terminal: nombres de archivos, seguimientos de pila y mensajes de error.
Entonces, ¿cuánto cuesta esto?
Un lector astuto podría preguntar:
¿No es el backward pass más caro si estás retropropagando gradientes en más posiciones de tokens?
Casi no. La parte cara de la retropropagación son las multiplicaciones de matrices a través de las capas de atención y MLP, y esas se ejecutan sobre la misma secuencia de tokens independientemente de qué posiciones de salida contribuyan a la pérdida. Los logits en cada posición de respuesta ya están calculados para GRPO. La máscara de acción y la máscara de observación simplemente recogen diferentes subconjuntos de ellos para diferentes términos de pérdida.
Haz una pausa aquí por un segundo: agregamos una pérdida de modelado del mundo, ¡y el costo es básicamente CERO! Sin rollouts adicionales, modelo profesor y sin forward pass extra.
¿Ayuda ECHO a entrenar un mejor agente CLI?
Ejecutamos la comparación más limpia posible en tareas de terminal de múltiples turnos: mismos modelos, misma receta GRPO, mismas tareas, mismo presupuesto de rollouts y turnos, mismo número de pasos de entrenamiento. Recompensa = 1 si el agente pasa los casos de prueba después de n turnos, 0 si falla.
La única diferencia es si los tokens de salida del terminal también entran en la pérdida.
Las curvas rosas son ECHO y las verde azulado son GRPO. En todos los tamaños de modelo y cortes de evaluación, la respuesta es la misma: agregar la predicción del entorno hace que el agente sea sustancialmente mejor.
ECHO mejora consistentemente el rendimiento en los tres conjuntos de validación no vistos: las curvas rosas se separan de las verde azulado desde el principio y generalmente se mantienen por encima.
ECHO también aprende sustancialmente más rápido: ¡ECHO iguala el rendimiento de GRPO en 500 pasos en Terminal-Bench Lite 280 pasos más rápido! Una aceleración de 2.3x y sigue subiendo 😊
Estos resultados corroboran nuestra intuición detrás de ECHO. GRPO entrena solo con recompensas de resultado binarias y escasas. Para dominios difíciles como las tareas de terminal donde la tasa de aprobación es baja para modelos pequeños, esto se traduce en poca o ninguna señal para muchas tareas.
ECHO hace que el entrenamiento sea mucho más eficiente en términos de muestras al convertir las acciones fallidas en supervisión. Incluso cuando una acción no resuelve la tarea, la respuesta del terminal aún le enseña al modelo qué causó esa acción. ¡Y predecir las consecuencias de las acciones fallidas puede ayudar al agente a elegir mejores acciones!
Si prefieres ver los números en todas las evaluaciones, la misma historia en forma de tabla:
Mira la última fila en cada bloque: ECHO. TerminalBench-2.0 pass@1 casi se duplica en escalas de 8B (2.7 → 5.2) y 14B (5.2 → 10.8). Y es importante destacar que esto no proviene de datos adicionales, rollouts, un modelo profesor o un verificador diferente. El rollout ya contenía la respuesta del terminal. ECHO simplemente aprende de ella.
"El rendimiento casi se duplica sin costo adicional" es una frase que muy raramente lees en toda tu carrera de investigación 😊.
ECHO supera sustancialmente el rendimiento de GRPO en todos los benchmarks y tamaños de modelo, es mucho más eficiente en muestras y no cuesta prácticamente nada. Aprendes un modelo del mundo a medida que tu política mejora, lo que ayuda a que mejore más rápido.
Sin embargo, los escépticos podrían objetar: ¿realmente aprendes un modelo del mundo?
¡Veamos!
¿ECHO realmente aprende las dinámicas del terminal?
Vamos a ser un poco cautelosos aquí porque la comunidad del modelado del mundo puede ponerse un poco intensa.
No afirmaremos que ECHO aprende un modelo del mundo en el sentido más estricto. Pero afirmaremos que ECHO entrena una política cuyos estados ocultos han absorbido algo sobre cómo se comporta el terminal, y cuya capacidad para predecir lo que el terminal hará ha mejorado de forma medible.
Si inviertes la cita de Ilya, obtienes una versión más falseable. Para nuestro entorno, sería algo como esto:
Si el modelo ha aprendido las dinámicas del terminal, tiene que ser bueno prediciendo la salida del terminal.
Porque no hay otra forma de asignar consistentemente una alta probabilidad a los tokens correctos. Un modelo que es mejor predictor es, en términos de teoría de la información, un mejor compresor del sistema que está prediciendo.
Entonces, la pregunta se vuelve empírica: ¿ECHO realmente hace que el modelo sea un mejor predictor de la salida del terminal?
Sí. Por mucho.
Para que esta prueba sea limpia, usamos un modelo profesor más fuerte, Qwen 3 32B (no utilizado en ninguna de nuestras ejecuciones de entrenamiento) para generar trayectorias para cada uno de nuestros conjuntos de validación. Luego evaluamos nuestras políticas iniciales, las políticas entrenadas con GRPO y las políticas entrenadas con ECHO, y medimos qué tan "sorprendido" estaba cada modelo por los tokens de salida del terminal resultantes.
El patrón es el mismo en todos los paneles: GRPO apenas cambia la entropía cruzada de los tokens del entorno en relación con la política inicial. ECHO la reduce drásticamente.
Entonces, no diremos modelo del mundo con mayúsculas. Pero diremos esto:
ECHO produce políticas que son mediblemente mejores para comprimir las dinámicas del terminal, en trayectorias que no generaron.
Que es la versión operativa de la afirmación que hace el título, y la versión que es totalmente defendible.
Hallazgo sorprendente 1: ECHO reduce la dependencia del SFT experto
Una receta común para el RL de agentes es: primero, clonar el comportamiento de trayectorias de expertos de un modelo más fuerte, luego ejecutar RL. Esto es especialmente común para agentes de terminal, donde la recompensa es escasa y el espacio de acciones es enorme.
En nuestro entorno, la línea base de SFT experto es OpenThoughts-Agent-v1-SFT (OT-SFT): Qwen3-8B ajustado en demostraciones de agentes de terminal generadas por un profesor GLM-4.6 más fuerte.
Entonces preguntamos: ¿cuánto de ese beneficio del SFT experto puede recuperar ECHO sin clonar el comportamiento del profesor?
¿Puede ECHO permitirte saltarte el SFT experto? En nuestro entorno, ¡mayormente sí!
Esta figura compara tres ejecuciones: GRPO simple en el modelo base, ECHO en el modelo base y GRPO en el modelo con SFT (SFT + GRPO). En relación con la brecha entre GRPO y SFT+GRPO (por ejemplo, la ganancia que proporciona comenzar desde SFT), ECHO recupera el 104% de la ganancia en ITD, el 89% en Terminal Bench Lite (TBLite) y el 50% en TerminalBench-2.0 (TB2) pass@1.
El resultado sugiere que una gran parte del valor del SFT experto puede provenir de enseñarle al modelo una prioridad de interacción, no solo una prioridad de estrategia experta. Las demostraciones de expertos muestran tanto cómo comportarse como un agente de terminal (inspeccionar archivos, ejecutar pruebas, seguir rastreos, etc.) como lo que un experto haría en estados específicos. ECHO no imita esas elecciones de expertos. En cambio, entrena al modelo para predecir las consecuencias en el terminal de sus propias acciones, para que aprenda qué comandos exponen un estado útil, qué errores son diagnósticos y qué tokens de salida del terminal señalan progreso. Luego, pueden surgir mejores estrategias a través de la interacción en lugar de la imitación.
Esto también ayuda a interpretar la división del benchmark. En ITD y TBLite, ECHO casi iguala al SFT experto, lo que sugiere que gran parte de la ventaja del SFT allí proviene de un mejor modelo de interacción con el terminal. En TB2, ECHO aún recupera un 50% sustancial de la brecha sin demostraciones. La brecha restante es consistente con que TB2 sea más difícil y esté distribucionalmente más lejos del conjunto de entrenamiento.
No trataríamos esto como un techo fijo: un entrenamiento más amplio o más largo en tareas similares a TB2 debería mejorar aún más al agente.
Por lo tanto, la conclusión no es que el SFT experto sea obsoleto, sino que gran parte de lo que compra el SFT experto puede ser un mejor modelo de interacción con el terminal, y esa parte se puede aprender directamente del entorno.
En resumen: ¡El terminal es el profesor!
Hallazgo sorprendente 2: Chispas de auto-mejora sin recompensas
Hasta ahora, ECHO ha sido GRPO con una pérdida auxiliar del entorno. El verificador todavía le dice al agente si resolvió la tarea, y GRPO actualiza el modelo en los tokens de acción. Así que es una configuración RL estándar, con un pequeño término extra.
Pero si ECHO realmente le está enseñando algo a la política sobre cómo se comporta el terminal, entonces quizás no necesitamos la señal del verificador en absoluto.
Preguntamos: ¿Qué sucede si apagamos el verificador? Sin recompensas de las que aprender, solo esto:
Es decir, el modelo actúa, observa y se actualiza solo prediciendo las salidas del terminal como consecuencia de sus propias acciones.
Esto suena como que no debería mejorar el rendimiento de la tarea. No hay una etiqueta que diga qué acción fue buena. Si la política mejora, tiene que ser porque aprender a predecir el terminal remodela indirectamente las prioridades de acción de la política.
¡Así que lo intentamos!
Tomamos nuestro checkpoint más fuerte de Qwen3-8B+ECHO, eliminamos el término GRPO por completo y entrenamos durante 100 pasos más en tareas no vistas usando solo la pérdida de entropía cruzada del entorno. \\\\La pregunta era si el modelo podía mejorar en tareas OOD que nunca había visto antes, puramente interactuando con el entorno y prediciendo lo que regresaba.
¿Funcionó esta idea loca? ¡Algo así!
En val100 (dentro de la distribución): +3.8 pp. En ITD: +5.2 pp. En PyTerm (un conjunto OOD no visto de tareas de terminal con mucho Python): +10.0 pp después de filtrar a trayectorias limpias de llamadas a herramientas.
El entrenamiento solo con el entorno mejora la política cuando la salida del terminal es una supervisión útil. Sin señal de recompensa, el modelo se entrena solo para predecir las salidas causadas por sus propias acciones, por lo que las ganancias dependen de si esas salidas exponen dinámicas útiles.
En val100, que está cerca de la mezcla de entrenamiento, la ganancia es real pero pequeña: +3.8 pp antes de la saturación. La política ya ha aprendido la mayoría de las dinámicas locales durante el entrenamiento con ECHO.
En ITD, la política inicial más débil produce trayectorias ruidosas: comandos no válidos, errores de análisis, bucles sin salida. Filtrar a rollouts limpios elimina el ruido de la señal y da +5.2 pp.
Sin embargo, las trayectorias limpias por sí solas no son suficientes. El mismo filtrado no mejoró consistentemente TBLite, mientras que PyTerm comenzó desde una tasa de aprobación similar pero mejoró bajo la misma receta, lo que sugiere que el cuello de botella no es solo la fuerza de la política. La diferencia clave es cuán informativas son las observaciones: las tareas de Python proporcionan una retroalimentación densa vinculada a la acción (código → rastreo → corrección), mientras que las tareas de terminal más amplias revelan el estado de manera más indirecta a través de archivos, configuraciones y configuraciones de múltiples pasos.
Creemos que la adaptación sin verificador es posible: una vez que RL ha producido un modelo de exploración decente, el agente a veces puede seguir mejorando solo a partir de las consecuencias, pero solo cuando sus rollouts son limpios y la retroalimentación del terminal es informativa. ESA es la parte sorprendente. No es que el agente se auto-mejore perfectamente, sino que se auto-mejora en absoluto, a partir de nada más que actuar y predecir lo que regresa.
Dónde nos deja esto
La lección central de ECHO es simple: los rollouts de agentes contienen más supervisión que solo la recompensa final, y deberíamos usarla.
Cada comando que ejecuta un agente produce una respuesta del terminal (stdout, errores, rastreos, archivos, registros, etc.) y el RL estándar usa esos tokens solo como contexto para la siguiente acción. ECHO los convierte en objetivos de entrenamiento. No se necesita un modelo profesor, rollouts adicionales ni un modelo del mundo separado. Simplemente dejamos de tirar los tokens del entorno que ya están en la transcripción.
Ese pequeño cambio condujo a tres resultados sorprendentes: un rendimiento RL más fuerte, mucha menos dependencia del SFT experto y, en algunos entornos, auto-mejora sin verificador solo a partir de la interacción con el entorno. No creemos que esto signifique que las recompensas o las demostraciones sean obsoletas. Las trayectorias de expertos aún enseñan estrategia y los verificadores proporcionan la señal de nivel de tarea más limpia. Pero ECHO sugiere que entre "imitar al experto" y "esperar la recompensa escasa", hay una fuente densa y subutilizada de supervisión: las consecuencias de las propias acciones del agente.
La idea más amplia es una continuación de la predicción auxiliar que tiene una larga historia en RL, y el trabajo reciente ha revivido los objetivos de modelado del mundo para agentes LLM, por ejemplo, Agent Learning via Early Experience usa la señal de acción-consecuencia como una etapa previa a RL, VAGEN agrega una recompensa de modelado del mundo para agentes VLM, RWML pre-entrena en la predicción del siguiente estado, y CWM entrena a medio camino un modelo de código en trayectorias de observación-acción. ECHO es la versión en línea, dentro del bucle RL, con sabor a CLI, de la misma idea.
¿Hasta dónde puede llegar esta idea?
El siguiente paso es hacer que esta señal del entorno sea más potente y probar hasta dónde se generaliza. ECHO usa las salidas sin procesar del terminal porque ya están en el rollout, pero el mejor objetivo de aprendizaje podría ser una representación más limpia y compacta: resúmenes o vistas del estado relevantes para la tarea. También: ¿En qué observaciones deberíamos entrenar? ¿Cuándo deberíamos filtrar trayectorias? ¿Cómo deberíamos ponderar la predicción del entorno frente a la optimización de la política? ¿Puede la misma idea funcionar más allá de los terminales: para agentes de navegador, sistemas multiherramienta, agentes de codificación de horizonte largo o asistentes orientados al usuario donde los seguimientos, las correcciones y las preferencias son otra forma de retroalimentación de interacción?
Nuestra apuesta es que en cualquier lugar donde un agente actúe y el mundo responda en tokens, esos tokens de respuesta — o mejores representaciones de ellos — deberían ser parte de la señal de aprendizaje. ECHO es la versión más simple de esa idea que se nos ocurrió, y sospechamos que alguna forma de predicción de tokens del entorno será estándar en los entrenadores de RL de agentes para finales de 2026.
Consulta el artículo completo y el código basado en SkyRL.
Prueba ECHO y cuéntanos qué tan rápido entrenó tu agente.
Nota al pie: entrenando un modelo de mundo de laberinto en mi laptop… más o menos
¿Recuerdas cuando dije que "contribuí con un experimento tonto de laberinto"? Aquí está el experimento tonto de laberinto.
La configuración era una versión pequeñísima de ECHO: Un laberinto de cuadrícula en un terminal diminuto. El agente (un transformador de 10M en un bucle) emite una dirección — arriba, abajo, izquierda, derecha — y el terminal responde con dónde está el agente con respecto a sus "vecinos" (es básicamente un problema de búsqueda de caminos en una cuadrícula 2D) y la distancia al destino. Así que el rollout se ve exactamente (para valores pequeños de exactamente) como un rollout de un agente CLI, solo que mucho más simple 😊: acción → respuesta del entorno → acción → respuesta del entorno, etc.
Probé dos condiciones en un transformador de 10M de parámetros desde cero: 1) entrenar solo en los tokens de acción 2) entrenar en los tokens de acción y la respuesta del terminal (vecinos, distancia, etc.). Todo entrenado en laberintos nuevos de 6×6 / 7×7 / 8×8.
¿Es esta cosa del laberinto un artículo de Nature? No. Pero: creo que hay un punto que he estado haciendo que sigue generalizándose.
Casi todas las ideas limpias tienen un microcosmos: una versión reducida que puedes ejecutar en una laptop en una tarde y que te dice si vale la pena escalar la idea.
El laberinto no demostró que ECHO funcionaría. Me dio suficiente convicción para enviarle un mensaje de Teams a Vaish en lugar de olvidar la idea. Resultó que Vaish había estado dando vueltas alrededor de la misma idea de forma independiente y cuando su primera ejecución en clúster regresó con resultados, me emocioné y me sorprendí genuinamente. El laberinto de ECHO había insinuado que la dirección era correcta, pero no podría haber predicho duplicar los puntajes de TerminalBench, recuperar la mayor parte del SFT experto o la auto-mejora sin recompensas. Esos fueron los resultados de Vaish. "Resolver más o menos un laberinto de 6×6" y "duplicar en TerminalBench" son estados epistémicos muy diferentes.
Pero el objetivo de este apéndice no es que la laptop reemplace el experimento del clúster. El objetivo es que la mayoría de mis ideas están equivocadas y el experimento de la laptop (con la ayuda de Claude Code y Codex) me indica cuáles descartar antes de que le cuesten tiempo a alguien más. De vez en cuando, una idea sobrevive, y cuando lo hace, quizás se gana el derecho al tiempo de un colaborador y a sus GPUs.
ECHO es una de ellas.
