LEASH delega los pasos difíciles al agente fuerte y ahorra un 19,2% frente a Opus 5

El equipo detrás de LEASH propone una forma de no ejecutar el modelo caro en cada paso de un agente de computer-use. Un modelo abierto débil actúa por defecto; el fuerte se activa solo cuando el primero «duda», y tras el traspaso del control permanece bajo supervisión. En OSWorld, la combinación con Qwen3.5-35B-A3B resolvió con éxito el 73,66% de las tareas, a $0,4117 por tarea. Claude Opus 5 funcionando de forma permanente obtuvo un 72,90%. Es decir, LEASH no se queda atrás en calidad y sale un 19,2% más barato.

El problema: tareas largas e inferencia cara

Los agentes que manejan un ordenador resuelven tareas de decenas de pasos: abrir una aplicación, buscar un archivo, cambiar ajustes, comprobar el resultado. Un modelo de frontera en cada paso dispara rápidamente la factura. Un modelo open-weight pequeño, por su parte, a menudo no llega solo hasta el final. La escalada débil-fuerte promete un término medio, pero choca con una pregunta: ¿cuándo exactamente hay que llamar al modelo fuerte? Para responderla hace falta una señal que se pueda consultar en cada paso casi sin coste.

Hay además un segundo problema. El agente fuerte suele obtenerse a través de una API cerrada, de modo que no es posible examinar sus estados internos. Incluso después de recibir el control, puede perderse, y no hay con qué supervisarlo.

Cómo funcionan las tres capas de LEASH

El framework no requiere entrenamiento y se apoya en los estados ocultos del modelo débil. Los autores los comparan con los estados de trayectorias anteriores, exitosas y fallidas. Cuanto más se parece el estado actual a los de las trayectorias fallidas, mayor es la puntuación de incertidumbre. El estimador reutiliza las activaciones que el modelo ya calcula al generar la acción. No hacen falta un forward pass adicional ni un monitor entrenado aparte.

Esta señal alimenta tres capas:

• incertidumbre inicial de la tarea: enrutamiento temprano para decidir si se necesita el modelo fuerte desde el primer paso;
• incertidumbre por paso: escalada en plena ejecución, cuando el agente débil empieza a «flaquear»;
• observador en la sombra: sigue vigilando al agente fuerte, que es una caja negra, incluso después del traspaso del control.

El nombre LEASH («correa») describe bastante bien la idea: al agente fuerte se le suelta de la correa cuando hace falta, pero sin dejarlo ir del todo.

Qué mostró OSWorld

Los experimentos se realizaron en OSWorld con cuatro backbones modernos. Resultados según el texto del trabajo:

• LEASH es sistemáticamente mejor que los agentes débiles por sí solos;
• con la misma proporción de escaladas, supera a la escalada aleatoria entre 6,55 y 11,94 puntos;
• Qwen3.5-35B-A3B + LEASH: 73,66% de éxito y $0,4117 por tarea;
• Claude Opus 5 en modo always-on: 72,90%;
• ahorro en inferencia respecto al modo always-on: 19,2%.

Del último punto se deduce que una ejecución completa con Opus 5 cuesta unos $0,51 por tarea. Es un cálculo nuestro: el resumen del trabajo no da esa cifra. Conviene no inflar una diferencia de precisión de 0,76 puntos en un solo benchmark. Pero la dirección está clara: un enrutamiento inteligente alcanza al modelo estrella en calidad y le gana en precio.

Dónde puede servir y cuál es el inconveniente

Para los equipos que construyen agentes sobre las API de modelos de frontera, el esquema parece práctico. El grueso del trabajo lo asume un modelo open-weight local o barato, y la llamada costosa se reserva para los pasos complejos. Cuanto más largos son los escenarios, más se nota el efecto: la factura crece con el número de pasos, mientras que la escalada se activa pocas veces.

También hay limitaciones. El método exige acceso a los estados ocultos del modelo débil, así que solo sirve con una variante self-hosted u open-weight. Además, hace falta una base de trayectorias anteriores etiquetadas como éxito o fallo, aunque no haya que entrenar nada. La validación se limita por ahora a OSWorld, y no se sabe cómo se comportará la señal en otras interfaces y en aplicaciones no estándar. Antes de llevar LEASH a producción, conviene reunir un conjunto propio de trayectorias y comprobar hasta qué punto la señal de incertidumbre coincide con los fallos reales en vuestras tareas.