StopLoss interrumpe las ejecuciones condenadas de los agentes de programación y ahorra hasta un 48% del coste

Los agentes de programación se empeñan en pulir soluciones que de todos modos no pasarán la verificación, y cada paso innecesario se paga en tokens. Encargar esa vigilancia a un modelo de frontera choca con el mismo problema: el propio observador es caro. Los autores de StopLoss proponen un pequeño monitor externo que lee los últimos pasos del agente y detiene la ejecución a tiempo. En SWE-bench Verified reduce el coste por solución conservada un 4,5% y mantiene el 99% de las ejecuciones exitosas. En el subconjunto más costoso, SWE-bench Pro, el ahorro alcanza el 31%, y con Qwen3-8B como modelo base llega al 48%.

Cómo funciona el monitor

El nombre viene de la orden bursátil de stop-loss: la posición se cierra automáticamente cuando la pérdida se vuelve más probable que la ganancia. Aquí, la «posición» es la ejecución del agente. El monitor decide abortar cuando la estimación de riesgo de fallo supera un umbral.

El entrenamiento se apoya en trayectorias ya finalizadas y en los veredictos del verificador. El resultado de toda la ejecución, éxito o fallo, se asigna a ventanas locales anteriores: las últimas llamadas a herramientas. Así se obtiene un conjunto de entrenamiento sin etiquetado manual. Un modelo de lenguaje afinado evalúa cada ventana en una sola pasada directa, sin razonamientos largos y sin generar texto. El umbral se calibra con ejecuciones exitosas, para no interrumpir las que habrían llegado a una solución. El ejecutor permanece intacto: el monitor se conecta desde fuera y no exige modificar el agente ni sus prompts.

El modelo se entrenó con trayectorias de la familia GPT de SWE-rebench. Se evaluó en SWE-bench Verified y en un subconjunto de SWE-bench Pro, con GPT y Claude como ejecutores. Como referencia se usaron seis jueces LLM de propósito general, a los que se dieron exactamente las mismas ventanas.

Qué muestran las mediciones

En los jueces de propósito general, la predicción de fallo en la primera comprobación se acerca al azar. El entrenamiento con resultados la convierte en una señal útil. Además, cada comprobación cuesta entre uno y dos órdenes de magnitud menos que con cualquiera de los jueces probados. Eso es lo que hace económicamente razonable la parada temprana: si la comprobación en sí es cara, se come el beneficio de las ejecuciones interrumpidas.

• Coste por solución conservada en Verified: −4,5% respecto a ejecutar todas las tareas hasta el final, manteniendo el 99% de las ejecuciones exitosas.
• En el subconjunto Pro: hasta −31%, y con Qwen3-8B como base, hasta −48%.
• Coste de la comprobación: entre uno y dos órdenes de magnitud inferior al de cualquiera de los seis jueces.
• En las cuatro configuraciones, el coste por solución conservada de StopLoss es inferior al de cualquier política basada en jueces.
• El ejecutor no cambia y el umbral se ajusta con ejecuciones exitosas.

La diferencia entre benchmarks es reveladora. En Verified las tareas son más baratas y apenas queda margen de ahorro: un 4,5% es una cifra modesta. En Pro, donde una ejecución fallida cuesta bastante más, interrumpir los fallos compensa más. El efecto crece con el precio del error.

Dónde puede resultar útil en la práctica

La métrica «coste por solución conservada» es más útil que el coste por ejecución. Tiene en cuenta tanto los tokens ahorrados como los éxitos perdidos por paradas erróneas. Los equipos que lanzan agentes de forma masiva, por ejemplo para corregir bugs automáticamente en CI, deberían medir precisamente esta.

El enfoque no requiere acceso a las entrañas del ejecutor y se apoya en datos que la mayoría de los equipos ya tiene: logs de trayectorias y resultados de tests. Un monitor pequeño se puede afinar con las propias ejecuciones y ajustar el umbral a una proporción aceptable de éxitos perdidos. En el trabajo, esa proporción es del 1% en Verified.

Hay también limitaciones. Los resultados proceden de dos benchmarks de tareas de ingeniería de software, y las trayectorias de entrenamiento pertenecen a la familia GPT. El artículo no muestra cómo se comportaría el monitor con otro tipo de carga de trabajo ni con otros arneses de agentes. Aun así, la idea es clara: si el fallo se puede reconocer a bajo coste, no hace falta esperar al final de la ejecución.