Reemplazamos Opus 4.8 con 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 usando nuestra nueva arquitectura Fusion, Fable costó menos. Como era de esperar, también obtuvo una puntuación más alta. Este artículo explica por qué y qué significa eso para la fijación de precios del trabajo con agentes.
Introducción
Todos los que ejecutan agentes de codificación saben que los modelos más potentes dan mejores resultados, pero te comes el costo.
Cuando presentamos Devin Fusion, mostramos una salida: mantener un modelo frontera al mando, dejar que delegue en un compañero más barato y rápido, y obtienes 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 3,000 sesiones de evaluación en FrontierCode 1.1 en cuatro configuraciones: Fable y Opus en el asiento principal, cada uno con y sin el mismo compañero barato.
Las ejecuciones puras se comportan exactamente como la intuición sugeriría: Fable supera a Opus (60.8 vs 55.4) y cuesta más. Mejor modelo, factura más grande.
Las ejecuciones con compañero son donde las cosas se ponen interesantes.
Con el mismo compañero, el orden de costos se invierte: Fable + Compañero cuesta menos que Opus + Compañero ($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 + Compañero 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) + Compañero | 60.7 | $1.86 |
Opus 4.8 (medio) + Compañero | 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 para mirar. El costo de un agente está dominado por cuántos turnos toma el modelo principal, cuánto contexto arrastra y, sobre todo, lo que decide no hacer él mismo. La diferencia se reduce al estilo de gestión: Opus se comporta como un microgestor con un pasante; Fable es un gerente con un ingeniero competente.
La configuración
Un repaso rápido de cómo funciona la arquitectura de compañero de Fusion. El agente principal posee la sesión: habla con el usuario, planifica, revisa el trabajo y confirma. También tiene un subagente compañero persistente para delegar tareas. El principal escribe un resumen de traspaso en lenguaje sencillo, y el subagente, impulsado por un modelo mucho más barato, lo ejecuta en su propio contexto e informa los resultados. El principal revisa el resultado y decide qué sucede a continuación.
Para descubrir a dónde va el costo, hicimos dos cosas. Primero, analizamos cada llamada LLM en las 3,000 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 lado a lado, examinando las trayectorias y observando dónde se iban los dólares.
Costo de un agente
Así es como se divide el costo entre el principal y el compañero en nuestro experimento:
$ Principal | $ Compañero | $ Total/ejecución | Turnos principal/ejecución | Tokens de entrada principal (acumulados) | |
|---|---|---|---|---|---|
Fable + Compañero | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok |
Opus + Compañero | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |
Fable gasta más en su compañero que Opus — $0.27 más por ejecución. Pero gasta $0.45 menos en sí mismo. El principal de Fable toma 11.5 turnos por ejecución frente a los 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 turnos.
Los ahorros de tokens de Fable surgen de evitar trabajo directamente. Curiosamente, en el 81% de las ejecuciones lideradas por Fable, el principal nunca realiza 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 principal ni siquiera lee un archivo del repositorio por sí mismo.
Un microgestor con un pasante vs un gerente con un ingeniero
Esto es lo que hace interesante la brecha: ambos principales delegan la misma cantidad de veces, aproximadamente 3 traspasos por ejecución. Los registros por llamada descartan la explicación fácil de que Fable simplemente delega más. Lo que difiere es cuándo y qué delegan. El primer traspaso de Fable llega temprano. Opus a menudo delega tarde, después de un largo período 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.
GIF
Una ejecución típica liderada por Fable realiza algunas acciones de reconocimiento en el repositorio, luego escribe un resumen de calidad de especificación 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 turnos de exploración, diseño e implementación en solitario, y un traspaso tardío para la parte mecánica.
A veces, la primera acción de Fable en una sesión es un traspaso. En la misma tarea, los dos principales 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 resúmenes de traspaso. Cuando Opus delega implementación, dicta, mientras que Fable escribe un documento de diseño:
La delegación no solo mueve el costo; 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ó manualmente y nunca escribió ese requisito en ninguna parte. En algún momento olvidó la restricción y envió una implementación de tiempo lineal, que obtuvo una puntuación de 25. En contraste, Fable delegó usando restricciones de alto nivel. Su resumen decía: "operator() debe ser O(1) en la longitud del puntero: SIN escaneo completo de tokens." El compañero implementó esto con éxito para una puntuación de 94.
Descubrimos que este patrón se generaliza entre tareas. Los traspasos de Fable enumeraban restricciones, casos límite y una definición de "terminado", ahorrándose esfuerzo mientras permitían al compañero completar la implementación de manera económica y correcta.
Después del traspaso
La otra mitad es lo que hace el agente principal con el trabajo que regresa del compañero. Ambos principales a menudo ejecutan la misma verificación barata: dos o tres llamadas git diff/git show. Pero Opus no se detiene ahí. Trae los archivos del compañero de vuelta a su propio contexto 2 veces más y realiza 4 veces más ediciones correctivas a precios de principal. En el caso extremo, revirtió el trabajo del compañero y lo reescribió manualmente:
La desconfianza de Opus tampoco aumenta la corrección. En algunas tareas de evaluación, la revisión única de diff de Fable detectó errores reales del compañero, y optó por otro traspaso barato, en lugar de la reescritura a nivel de principal que Opus suele aplicar.
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 unos pocos turnos del modelo principal sin nada que delegar entre decidir y entregar.
- 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 resumen también sabe cuándo no escribir uno. Pero cuando una tarea no ofrece nada que valga la pena delegar, 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.
Cierre
Comenzamos este experimento esperando medir cuánto aumentaría el costo la prima de 2x de Fable. Nos sorprendió descubrir que la delegación efectiva de Fable en realidad disminuyó el costo en general. Especificaba restricciones y resultados en lugar de detallar la implementación, daba retroalimentación en lugar de hacer correcciones él mismo, y en la mayoría de los casos nunca tocaba el código en absoluto. Estos son los hábitos de un buen gerente.
A medida que los modelos compañeros se vuelven más baratos y mejores, más trabajo puede ser entregado a ellos. Lo que seguirá valiendo los precios de frontera es el juicio: qué construir, qué restringir y quién debería escribirlo.
