Reemplazamos Opus 4.8 por Fable 5, y la factura de Devin bajó.
Fable 5 cuesta el doble por token que Opus 4.8. Pero cuando ejecutamos ambos modelos en FrontierCode 1.1 con nuestra nueva arquitectura Fusion, Fable resultó más barato. Como era de esperar, también obtuvo una puntuación más alta. Este artículo explica por qué y qué implica para fijar el precio del trabajo con agentes.
Introducción
Todos los que ejecutan agentes de código saben que los modelos más potentes dan mejores resultados, pero pagan el costo.
Cuando presentamos Devin Fusion, mostramos una salida: mantener un modelo de frontera al mando, dejar que delegue en un ayudante más barato y rápido, y obtener un rendimiento de nivel frontera con un costo 35% menor.
Pero una vez que el modelo principal delega la mayor parte del trabajo, ¿sigue dominando su precio por token la factura? Fable 5 cuesta 2x más por token que Opus 4.8, por lo que un agente liderado por Fable debería costar más. Para averiguarlo, ejecutamos 3000 sesiones de evaluación en FrontierCode 1.1 en cuatro configuraciones: Fable y Opus como líderes, cada uno con y sin el mismo ayudante barato.
Las ejecuciones puras se comportan exactamente como la intuición sugiere: Fable supera a Opus (60.8 vs 55.4) y cuesta más. Mejor modelo, factura más grande.
Las ejecuciones con ayudante son donde las cosas se ponen interesantes.
Con el mismo ayudante, el orden de costos se invierte: Fable + Ayudante cuesta menos que Opus + Ayudante ($1.86 vs. $2.04), mientras obtiene una puntuación más alta (60.7 vs. 54.6). En comparación con Fable puro, Fable + Ayudante reduce el costo en un 54% mientras deja la puntuación casi sin cambios.
Configuración
Puntuación
Costo/ejecución (media)
Fable 5 (bajo) + Ayudante
60.7
$1.86
Opus 4.8 (medio) + Ayudante
54.6
$2.04
Fable 5 (bajo)
60.8
$4.03
Opus 4.8 (medio)
55.4
$3.06
La prima de 2x por token resulta ser el número equivocado a mirar. El costo de un agente está dominado por cuántas vueltas da el modelo principal, cuánto contexto arrastra y, sobre todo, qué decide no hacer él mismo. La diferencia se reduce al estilo de gestión: Opus se comporta como un microgestor con un becario; Fable es un gerente con un ingeniero capaz.
La configuración
Un repaso rápido de cómo funciona la arquitectura de ayudante de Fusion. El agente principal es dueño de la sesión: habla con el usuario, planifica, revisa el trabajo y hace commit. También tiene un subagente ayudante persistente para delegar tareas. El líder escribe un breve informe en lenguaje natural, y el subagente, impulsado por un modelo mucho más barato, lo ejecuta en su propio contexto e informa. El líder revisa el resultado y decide qué hacer a continuación.
Para averiguar dónde va el costo, hicimos dos cosas. Primero, analizamos cada llamada LLM en las 3000 sesiones: qué modelo hablaba, qué herramienta llamó, cuántos tokens leyó y escribió, y cuánto costó cada llamada. Segundo, seleccionamos 40 tareas para un análisis más detallado: aquellas donde Fable era drásticamente más barato, aquellas donde lo era Opus, y otra muestra aleatoria del medio. Para cada una, analizamos la ejecución liderada por Fable frente a la liderada por Opus una al lado de la otra, examinando las trayectorias y observando adónde iban los dólares.
Costo de un agente
Así es como se divide el costo entre el líder y el ayudante en nuestro experimento:
Líder $
Ayudante $
Total $/ejecución
Vueltas líder/ejecución
Tokens de entrada líder (acumulados)
Fable + Ayudante
$1.28
$0.58
$1.86
11.5
545k tok
Opus + Ayudante
$1.73
$0.31
$2.04
26.5
1,679k tok
Fable gasta más en su ayudante que Opus — $0.27 más por ejecución. Pero gasta $0.45 menos en sí mismo. El líder de Fable da 11.5 vueltas por ejecución frente a las 26.5 de Opus, escribe un tercio de los tokens de salida (6.1k vs 19.0k) y consume un tercio de los tokens de entrada. Fable es significativamente más caro por token, pero gana en gestión de contexto y número de vueltas.
Los ahorros de tokens de Fable provienen de evitar trabajo por completo. Curiosamente, en el 81% de las ejecuciones lideradas por Fable, el líder nunca hace una sola edición de código. Para Opus, eso es cierto solo en el 24% de las ejecuciones. En el 13% de las ejecuciones lideradas por Fable, el líder ni siquiera lee un archivo del repositorio por sí mismo.
Un microgestor con un becario vs un gerente con un ingeniero
Esto es lo que hace interesante la brecha: ambos líderes delegan el mismo número de veces, aproximadamente 3 transferencias por ejecución. Los registros por llamada desmienten la explicación fácil de que Fable simplemente delega más. Lo que difiere es cuándo y qué delegan. La primera transferencia de Fable llega temprano. Opus a menudo delega tarde, después de un largo tramo de exploración e implementación en solitario; para entonces, las decisiones de diseño están tomadas, los archivos importantes están en su contexto y el trabajo costoso ya está hecho.
Una ejecución típica liderada por Fable toma algunas acciones de reconocimiento en el repositorio, luego escribe un breve informe de especificaciones delegando todo el bucle de implementar + probar + lint. Luego un git show para revisar el diff y un commit.
Una ejecución típica liderada por Opus pasa por 20–45 vueltas de exploración, diseño e implementación en solitario, y una transferencia tardía para la cola mecánica.
A veces, la primera acción de Fable en una sesión es una transferencia. En la misma tarea, los dos líderes comenzaron así:
La solución obvia es hacer que Opus delegue más exploración, pero forzar ese comportamiento tiende a disminuir el rendimiento. Saber cuándo una investigación es segura para delegar y cuándo es algo que debes hacer tú mismo es en sí mismo un juicio. Un modelo forzado a delegar no adquiere ese juicio; simplemente delega las cosas equivocadas.
El estilo de gestión de cada modelo también se revela en los propios breves informes de transferencia. Cuando Opus delega la implementación, dicta, mientras que Fable escribe un documento de diseño:
La delegación no solo mueve costos; también cambia la calidad del trabajo. La tarea de hashing anterior es un ejemplo claro. La especificación de la tarea requería que una función hash fuera O(1) en la longitud del puntero. Opus la implementó a mano y nunca escribió ese requisito en ningún lado. En algún momento olvidó la restricción y entregó una implementación de tiempo lineal, que obtuvo una puntuación de 25. Por el contrario, Fable delegó usando restricciones de alto nivel. Su breve informe decía: "operator() debe ser O(1) en la longitud del puntero: NO escanear token completo". El ayudante implementó esto con éxito para una puntuación de 94.
Descubrimos que este patrón se generaliza en todas las tareas. Las transferencias de Fable enumeraban restricciones, casos límite y una definición de "terminado", ahorrándose esfuerzo y permitiendo que el ayudante completara la implementación de manera barata y correcta.
Después de la transferencia
La otra mitad es lo que hace el agente líder con el trabajo que regresa del ayudante. Ambos líderes a menudo ejecutan la misma verificación barata: dos o tres llamadas a git diff/git show. Pero Opus no se detiene ahí. Tira los archivos del ayudante de vuelta a su propio contexto 2 veces más y hace 4 veces más ediciones correctivas a precios de líder. En el caso extremo, revirtió el trabajo del ayudante y lo reescribió a mano:
La desconfianza de Opus tampoco aumenta la corrección. En algunas tareas de evaluación, la revisión única del diff de Fable detectó errores reales del ayudante y optó por otra transferencia barata, en lugar de la reescritura a nivel de líder que Opus suele usar.
Cuando la delegación no ayuda
La estrategia de delegación de Fable no es universalmente útil; falla cuando la tarea no tiene componentes delegables. Los siguientes tipos de tareas parecían difíciles de descomponer:
- Tareas cortas que incluyen solo un puñado de vueltas del modelo líder sin nada que delegar entre decidir y enviar.
- Tareas de depuración en serie donde la búsqueda de la causa raíz es una larga cadena de juicios. Aquí, el contexto acumulado es el trabajo.
Notablemente, en estas tareas Fable apenas delega. El mismo juicio que escribe un buen informe también sabe cuándo no escribirlo. Pero cuando una tarea no ofrece nada que valga la pena transferir, la delegación no tiene apalancamiento sobre el costo.
En producción, Fusion maneja esto en otra capa: la delegación controla qué trabajo se queda con el modelo caro, mientras que el enrutamiento decide si el modelo caro está involucrado en absoluto.
Conclusión
Empezamos este experimento esperando medir cuánto aumentaría el costo la prima del 2x de Fable. Nos sorprendió descubrir que la delegación efectiva de Fable en realidad disminuyó el costo general. Especificaba restricciones y resultados en lugar de detallar la implementación, daba retroalimentación en lugar de hacer las correcciones él mismo y, en la mayoría de los casos, nunca tocaba el código. Estos son los hábitos de un buen gerente.
A medida que los modelos ayudantes se vuelven más baratos y mejores, se les puede delegar más trabajo. Lo que seguirá valiendo precios de frontera es el juicio: qué construir, qué restringir y quién debería escribirlo.
