TerminalHorizon: datos agénticos long-horizon y +13,85 en Terminal-Bench 2.1 con solo SFT
TL;DR
- Verificado (arXiv 2610.13166, publicado el 9-oct-2026): AMAP (Alibaba Group), la USTC y SUSTech publican TerminalHorizon, un motor que sintetiza automáticamente entornos de terminal long-horizon: tareas profesionales que exigen explorar, implementar y verificar a lo largo de muchas interacciones. Con él construyen 1.535 entornos y 2.852 trayectorias de entrenamiento.
- Verificado: con esas trayectorias y solo SFT —sin una hora de RL— ajustan Qwen3.5-27B para obtener TerminalHorizon-27B. Según los autores: 46,82 → 60,67 en Terminal-Bench 2.1 (+13,85 puntos), mejoras en los 12 benchmarks que miden (coding, agentes en producción y reasoning) y la misma receta aplicada a Qwen3.5-35B-A3B y Qwen3.5-122B-A10B con ganancias de dos dígitos.
- Verificado: el número incómodo para el resto del campo está en la Tabla 1: RST-27B llega a 49,4 en Terminal-Bench 2.0 con 327.200 trayectorias; TerminalHorizon-27B reporta 55,8 con 3.000. Pesos Apache 2.0 de los tres tamaños en Hugging Face, más los dos datasets.
- Claim de los autores: que las trayectorias conservan los patrones agénticos que los entornos sintéticos suelen destruir —el motor detecta con ejecución independiente qué trabajo la construcción ya hizo de más, y reconstruye el entorno para devolvérselo al agente— y que el resultado transfiere a benchmarks de producción sin sacrificar reasoning.
- Matices que importan: todo es auto-reportado; a 4 días del release no hay replicación externa; los comparables de la Tabla 1 mezclan scaffolds; y el dato pasa por un profesor frontier (DeepSeek-V4-Pro-0813), con lo que el techo del alumno hereda el del profesor. Detalles abajo.
El problema: el entorno sintético puede resolver la tarea antes de que llegue el agente
La diagnosis del paper merece citarla casi entera, porque describe una enfermedad que cualquiera que haya generado tareas sintéticas para agentes reconoce: “environment synthesis may complete or simplify the key work underlying these patterns in advance and thus remove the need for exploration, implementation, and verification that the agent was meant to perform”. El entorno parece difícil, el agente pasa la evaluación, y la trayectoria que sale no enseña nada de lo que se quería enseñar.
El ejemplo que ponen es tan concreto que duele: si la tarea pide implementar una función central pero el entorno ya la trae, el trabajo restante se reduce a cambiar una constante. La trayectoria resultante puede tener su secuencia completa de interacción, pero el patrón que importaba —explorar, diagnosticar, implementar, verificar— no ocurre en ninguna parte. Lectura nuestra, no del paper: un pipeline que premia trayectorias por terminar en éxito deja pasar exactamente este tipo de dato hueco, y por eso el filtrado orientado a proceso —del que hablamos abajo— es la mitad importante de la receta.
No es un problema nuevo ni de este paper: es el mismo debate de fondo que cubrimos en AgentGarten, entornos generados para agentes —cada vez se generan más mundos sintéticos, la pregunta es qué aprendizaje conservan— y en Learn2Play Bench, donde la conversación cruda enseñaba más que las reglas resumidas. Lo que aporta TerminalHorizon es un mecanismo concreto para atacarlo.
Cómo funciona: ejecución independiente, reconstrucción y expansión bajo el mismo goal
El motor tiene dos etapas. La primera, Challenge-Guided Long-Horizon Synthesis, convierte problemas profesionales reales en tareas ejecutables y entonces hace algo poco glamuroso y muy sensato: le encarga la tarea a un Independent Challenger, un agente que no participó en la construcción y que solo ve la instrucción pública y el entorno —ni el blueprint, ni la solución de referencia, ni los tests privados—. Analiza la trayectoria resultante, compara el trabajo que se pretendía con el que realmente hizo falta, y donde la construcción simplificó o resolvió de más, reconstruye el entorno. El bucle repite hasta que el trabajo sobrevive a la ejecución independiente.
La segunda etapa, Progressive Horizon Expansion, coge las tareas aceptadas y las extiende bajo el mismo goal: roles más amplios, mecanismos que antes se simplificaban y ahora forman parte del trabajo, más evidencia que cruzar, o rediseños del método. La clave es que el trabajo añadido dependa de los resultados y feedback de las etapas anteriores, para que los patrones agénticos se encadenen a lo largo de la trayectoria en vez de reiniciarse en cada subtarea. El paper organiza lo que quiere conservar en 27 patrones agénticos de 5 familias (seguimiento de relaciones, revisión ante evidencia, entrega progresiva, etc.).
El resultado material: 1.535 paquetes de tarea, dos trayectorias por tarea generadas con DeepSeek-V4-Pro-0813 como profesor sobre el harness Terminus2, y un filtrado con tres criterios que retiene 2.852 trayectorias —el 93% de las ~3.070 recogidas; el dataset se llama TerminalHorizon-3K y se queda corto por 148—. Las trayectorias medias tienen 52,8 turnos de interacción (percentil 90: 98), con una cadena continua de acción-feedback mediana de 25 turnos.
Los números, con verificado y atribución
Consulta de fuentes: 13-oct-2026. Todas las cifras salen del HTML v1 del paper; son mediciones de los autores (AMAP/Alibaba + USTC) con sus verifiers y su harness. Repetirlas aquí no las convierte en datos independientes.
| Benchmark | Base Qwen3.5-27B | TerminalHorizon-27B | Δ |
|---|---|---|---|
| Terminal-Bench 2.1 | 46,82 | 60,67 | +13,85 |
| Terminal-Bench 2.0† | 41,6 | 55,8 | +14,2 |
| Terminal-Bench 1.0 | 46,3 | 55,0 | +8,7 |
| AutomationBench (Pass) | 5,5 | 17,2 | +11,7 |
| AutomationBench (Partial) | 26,4 | 49,7 | +23,3 |
| τ²-bench Airline | 79,0 | 84,5 | +5,5 |
| τ²-bench Retail | 84,9 | 87,5 | +2,6 |
| VitaBench Cross-domain | 20,5 | 31,8 | +11,3 |
| MATH-500 | 96,9 | 98,9 | +2,0 |
| GSM8K | 96,3 | 97,3 | +1,0 |
| AIME 2024 | 93,3 | 96,7 | +3,4 |
| AIME 2025 | 86,7 | 93,3 | +6,6 |
| KOR-Bench (Cipher) | 90,1 | 91,2 | +1,1 |
†: en la Tabla 1 del paper la marca cubre solo el 41,6 del base en Terminal-Bench 2.0, cifra que viene de las model cards oficiales y no de una evaluación propia de los autores; del 46,3 en Terminal-Bench 1.0 el paper no indica el origen. Los 12 benchmarks que anuncian en el abstract son exactamente estos tres bloques: coding (Terminal-Bench 1.0/2.0/2.1), agénticos de producción (AutomationBench, τ²-bench, VitaBench) y reasoning (MATH-500, GSM8K, AIME, KOR-Bench).
Tres lecturas. Primera: las mejoras grandes están donde el base es débil —AutomationBench Partial casi se duplica, de 26,4 a 49,7—, que es el patrón esperable cuando el SFT enseña comportamiento de ejecución sostenida y no conocimiento. Segunda: en reasoning no hay sacrificio (todo sube algo), pero tampoco ganancia relevante: +1,0 en GSM8K es ruido bueno, no una segunda contribución. Tercera: Terminal-Bench 1.0 mejora menos (+8,7) que las versiones 2.x; si tu referencia es la 1.0, modula el titular.
Eficiencia de datos: la Tabla 1 es el titular real
El cruce que hace interesante este paper frente a otra docena de releases de agentes de terminal es el coste en trayectorias:
| Modelo (TB 2.0) | Base | Trayectorias | Scaffold | TB 2.0 |
|---|---|---|---|---|
| CLI-Universe-32B | Qwen3-32B | 6k | Terminus2 | 33,4 |
| TMax-27B | Qwen3.6-27B | 16,5k | Vanillux2Agent | 42,7 |
| RST-27B | Qwen3.5-27B | 327,2k | Terminus2 | 49,4 |
| Terminal-Universe-27B | Qwen3.5-27B | 32,0k | Terminus2 | 52,8 |
| TerminalHorizon-27B | Qwen3.5-27B | 3k | Terminus2 | 55,8 |
Cifras de la Tabla 1 del paper, atribuidas a sus autores. La lectura honesta: contra RST-27B —mismo base, mismo scaffold, 109 veces más trayectorias— la diferencia reportada es de 6,4 puntos a favor de TerminalHorizon. Eso, si se sostiene, dice que la calidad y estructura del dato manda sobre el volumen, que es exactamente la tesis del paper. Ojo, eso sí: TMax usa otro scaffold y CLI-Universe parte de otro base, así que la tabla es comparación de contexto, no experimento controlado.
Dos datos más de eficiencia. El scaling de 1k a ~3k trayectorias sube Terminal-Bench 2.1 hasta el 60,67% “sin señal de saturación” en la curva —con 3k puntos, la palabra “saturation” lo que de verdad dice es que no tienen datos para saber dónde acaba—. Y la receta escala con el tamaño: +13,85 con Qwen3.5-27B, +13,11 con 35B-A3B y +14,98 con 122B-A10B, ganancias de dos dígitos en los tres (Fig. 6 del paper).
El detalle que revela el criterio: cómo eligen al profesor
Antes de generar el dataset completo, compararon dos profesores candidatos —GLM-5.2 y DeepSeek-V4-Pro-0813— sobre una muestra de 100 tareas:
| Métrica | GLM-5.2 | DeepSeek-V4-Pro-0813 |
|---|---|---|
| Turnos medios | 46,1 | 53,5 |
| Cadena de feedback media | 19,2 | 30,3 |
| Repeticiones exactas | 15,8% | 13,2% |
| Pass rate | 44,0% | 50,0% |
Elegieron DeepSeek, y no por el pass rate: por las interacciones más sostenidas (cadena de feedback media de 30,3 frente a 19,2). Para un dataset cuyo producto es el patrón de trabajo a lo largo de la trayectoria, ese criterio es el correcto y dice más del equipo que cualquier tabla de benchmarks. El matiz escéptico: es destilación de un frontier, con lo que TerminalHorizon-27B aprende a trabajar como DeepSeek-V4-Pro-0813 trabaja; sin RL posterior, no hay mecanismo para superar a quien generó el dato.
RSI-Exam: 12 horas de presupuesto autónomo por problema
La parte más ambiciosa del paper son cuatro casos de mejora recursiva (RSI) con 12 horas de presupuesto de investigación autónoma por caso, puntuados con recompensa normalizada (×100). Base frente a TerminalHorizon-27B: robot routing 14,63 → 39,72; inversión del campo de fricción tidal 27,41 → 48,15; estrategia 2048 37,54 → 45,25; fusión multi-vista de nubes de puntos 21,93 → 48,96. Lo cubrimos con escepticismo por defecto en RSI de agentes: qué es real en la auto-mejora recursiva, así que nos quedamos con el detalle cualitativo que reportan, que es de los más honestos que hemos leído en un paper reciente: en el caso de fusión de puntos, el modelo base consigue buena puntuación en una métrica proxy que se inventa él mismo y “voluntarily stops after just 12.1 minutes, judging its results to be excellent”. Deja 11 horas y 48 minutos de presupuesto sobre la mesa porque su proxy le dice que ya ha ganado. El modelo entrenado sigue iterando contra la cobertura real del problema y más que duplica la recompensa (2,23×). Ese es el comportamiento que las trayectorias long-horizon compran.
Dicho esto: son cuatro casos, no un leaderboard, y los seleccionan los autores. Señal, no prueba.
Lo que el titular no dice
Todo es auto-reportado. Verifiers propios, scaffolds propios, benchmarks elegidos por los autores. A 13-oct-2026, 4 días tras el release, la adopción es la de todo paper fresco: 132 upvotes en la paper page de HF, y descargas modestas de pesos (56 en el 27B, 957 en el 35B-A3B y 89 en el 122B-A10B, medición propia vía API de HF). Nadie ha publicado todavía un “lo probé en producción y…”.
La comparación de eficiencia no es un experimento controlado. Ya se ha dicho: scaffolds mezclados, un base distinto en dos filas, y los baselines citados con sus cifras originales. La dirección (menos dato, más estructura) es creíble; el “109× más eficiente” exacto no se lo firmamos a nadie.
El techo lo pone el profesor. Sin RL, todo lo que el modelo sabe hacerlo lo sabe hacer DeepSeek-V4-Pro-0813. El valor aquí es de compresión y forma (27B Apache 2.0 que trabaja de forma sostenida), no de capacidad nueva.
Cómo aprovecharlo
Si solo consumes agentes: hay pesos Apache 2.0 de los tres tamaños en Hugging Face (TerminalHorizon-27B, -35B-A3B y -122B-A10B; los dos últimos son MoE), más los dos datasets —TerminalHorizon-Environment con las 1.535 tareas y TerminalHorizon-3K con las 2.852 trayectorias—. El 27B es dense y sirve con transformers/vLLM estándar; no lo hemos desplegado, así que no hay cifra de VRAM ni de latencia de este lado.
Si generas datos sintéticos para agentes —terminal o no—, lo aprovechable no es el dataset, es el método, y se resume en dos movimientos baratos: haz que un agente sin contexto de construcción intente cada tarea antes de aceptarla, y compara qué trabajo se evaporó; y expande tareas bajo el mismo goal haciendo que lo nuevo dependa de lo anterior. Los criterios de filtrado del Apéndice F y el protocolo de descontaminación (0 pares exactos contra Terminal-Bench 1.0/2.0/2.1, tablas 8-9 del paper) son una checklist razonable para cualquiera que publique un dataset de entrenamiento agéntico. Nótese que aquí todo es SFT: el contraste con la vía RL puro sobre tareas sintéticas lo cubrimos en FrogNano, 1.500 tareas sintéticas y RL para un agente de 4B —dos respuestas distintas al mismo problema de dónde salen las trayectorias—.
Qué haría yo
Si montas agentes de CLI o automatización de terminal, el experimento barato es evaluar el 27B en 20-30 de tus tareas reales contra tu modelo actual y mirar una sola cosa: si sostiene el trabajo (diagnóstico → implementación → verificación → entrega) o se rinde en la primera ambigüedad. Es exactamente la variable que este dataset intenta enseñar, y es la que tu benchmark interno puede medir sin creerse el 60,67 de nadie. Todo esto encaja en la línea que seguimos en el hub de agentes: el progreso útil ya no viene del tamaño, viene de qué experiencia le das al modelo y de si esa experiencia conserva el trabajo de verdad.
Lo que yo no haría: adoptar el “+13,85 en 12 benchmarks” como expectativa de producción sin replicación externa, ni extrapolar la eficiencia de 3k trayectorias a tu dominio —la eficiencia aquí probablemente viene de lo caro del método (ejecución independiente + reconstrucción por tarea), no de magia comprimible—.
Fuentes
- arXiv: Scaling Agentic Data for Long-Horizon Terminal Intelligence (2610.13166) (v1, 9-oct-2026) — abstract, afiliaciones (USTC, AMAP/Alibaba Group, SUSTech).
- HTML v1 del paper — tablas 1-4, mecanismo de síntesis, comparación de profesores, descontaminación y hyperparámetros de SFT.
- Hugging Face: paper page — 132 upvotes a 13-oct-2026.
- TerminalHorizon-27B, TerminalHorizon-35B-A3B y TerminalHorizon-122B-A10B — pesos Apache 2.0.
- Dataset TerminalHorizon-Environment (1.535 tareas) y TerminalHorizon-3K (2.852 trayectorias).
- Project page.