Reajustar el enrutamiento de agentes de código según puntuaciones de largo horizonte

Los paneles de corto horizonte ocultan la dispersión que define el coste

Cuando un agente de código funciona durante horas, la elección del modelo se manifiesta en intentos por tarea completada, no en posición en el ranking. La pregunta en producción es qué modelo mantiene a un agente de larga duración dentro del presupuesto. Claude Fable 5.1 lideró la instantánea publicada de FrontierSWE v2 con una puntuación mean@5 del 56,3 %. GPT-5.6 registró una puntuación del 32,2 % en FrontierSWE v2, 24,09 puntos porcentuales por debajo del 56,29 % de Claude Fable 5.1. Esas puntuaciones implican unos intentos esperados por éxito de aproximadamente 1,78 frente a 3,11.

Si el cómputo por intento es similar, el modelo con menor puntuación puede costar mucho más para completar el mismo trabajo. Esa brecha es invisible en paneles saturados de corto horizonte, donde un modelo puede parecer intercambiable en tareas fáciles y luego divergir cuando una tarea requiere depuración sostenida, contexto largo y llamadas repetidas a herramientas. La dispersión importa porque las tareas de larga duración son donde los reintentos, el tiempo real y la escalación a humanos se convierten en el coste real. La brecha de puntuación es la entrada; el presupuesto es la restricción.

La aritmética convierte una brecha de puntuación en un umbral de enrutamiento

FrontierSWE v2 contiene 34 tareas tras añadir 21 nuevos desafíos de ultralargo horizonte. Evalúa cada modelo con cinco ensayos por tarea bajo un presupuesto de 20 horas en el arnés Proximus. GLM-5.3 registró una puntuación del 30,2 % en FrontierSWE v2. Esa configuración fija expone la dispersión que la comparación de modelos de código de corto horizonte a menudo comprime, porque las tareas requieren trabajo sostenido en lugar de una sola ejecución.

Convierte la brecha de puntuación en tasas de fallo: 43,7 % frente a 67,8 %. La tasa de fallo es la probabilidad de que un ensayo no complete la tarea. Con un coste similar por intento, el modelo con menor puntuación necesita más intentos y más presupuesto para terminar la misma tarea. Trata esas cifras como un modelo de coste. Un enrutador que confíe en puntuaciones saturadas seguirá enviando tareas largas al modelo equivocado, por lo que el umbral debe derivarse del delta de coste esperado.

Los umbrales de enrutamiento deben derivarse de la fiabilidad de largo horizonte

• Elige un benchmark de agentes de largo horizonte con puntuaciones no saturadas y un arnés fijo.
• Fija el número de ensayos, el presupuesto por tarea y el entorno de evaluación antes de puntuar.
• Puntúa con mean@k para que la cifra refleje fiabilidad.
• Convierte la brecha de puntuación en deltas de tasa de fallo y coste esperado por tarea completada.
• Establece umbrales de enrutamiento o de respaldo a partir del delta de coste.

Empieza por la clase de tarea. Los agentes de código e investigación de larga duración necesitan una línea base distinta a la de las completaciones cortas. Si el trabajo implica cambios en múltiples archivos, bucles de pruebas, correcciones de dependencias o verificación repetida, usa la puntuación de largo horizonte como entrada principal para el enrutamiento de modelos. Si el trabajo es corto y acotado, un panel saturado puede seguir siendo útil, pero no debe fijar el umbral de respaldo.

Fija el umbral a partir del coste esperado. Enruta al modelo principal cuando su coste esperado por tarea completada se mantenga por debajo del presupuesto. Enruta a un modelo más barato solo cuando el delta de coste sea menor que el riesgo de escalación, incluido el coste de reintento, el coste en tiempo real y la probabilidad de que un intento fallido produzca aun así un artefacto parcial que valga la pena conservar. La decisión de respaldo debe ser lo suficientemente explícita para que un ingeniero pueda explicar por qué se movió el tráfico y cuándo devolverlo.

Haz explícito el conjunto de restricciones en la configuración de enrutamiento: versión del benchmark, versión del arnés, lista de tareas, presupuesto, número de ensayos, entorno y regla de puntuación. Si alguno de esos elementos cambia, vuelve a ejecutar la comparación y el modelo de coste. Una puntuación solo es comparable cuando el número de ensayos, el presupuesto por tarea y el entorno son los mismos, por lo que el siguiente ingeniero debe poder reproducir la cifra a partir de la configuración.

Monitoriza la tasa de finalización, los intentos por tarea completada, el tiempo real por tarea completada y la tasa de escalación a humanos por modelo. Cuando la brecha en producción se aleje de la brecha del benchmark, este ya no es el proxy adecuado. Reajusta la línea base en ese momento. Mantén la revisión del umbral vinculada a la misma clase de tarea, porque una regla de enrutamiento que mezcle tareas cortas y largas derivará. Usa el modelo cuyo coste esperado de largo horizonte por tarea completada sea el más bajo con tu presupuesto actual; si el delta de coste es pequeño, mantén el modelo más barato, y si es grande, mueve el tráfico antes de la próxima revisión de presupuesto.