Abbiamo sostituito Opus 4.8 con Fable 5, e la bolletta di Devin è scesa.
Fable 5 costa il doppio per token rispetto a Opus 4.8. Ma quando abbiamo eseguito entrambi i modelli su FrontierCode 1.1 usando la nostra nuova architettura Fusion, Fable è costato meno. Come prevedibile, ha anche ottenuto un punteggio più alto. Questo articolo spiega perché e cosa significa per la determinazione dei prezzi del lavoro agentico.
Introduzione
Chiunque gestisca agenti di codifica sa che modelli più potenti danno risultati migliori, ma si paga il costo.
Quando abbiamo introdotto Devin Fusion, abbiamo mostrato una via d'uscita: tenere un modello frontier al comando, lasciargli delegare a un assistente più economico e veloce, e si ottengono prestazioni di livello frontier con un costo inferiore del 35%.
Ma una volta che il modello principale delega la maggior parte del lavoro, il suo prezzo per token domina ancora la bolletta? Fable 5 costa 2x in più per token rispetto a Opus 4.8, quindi un agente guidato da Fable dovrebbe costare di più. Per scoprirlo, abbiamo eseguito 3.000 sessioni di valutazione su FrontierCode 1.1 in quattro configurazioni: Fable e Opus al posto di comando, ciascuno con e senza lo stesso assistente economico.
Le esecuzioni pure si comportano esattamente come l'intuizione suggerirebbe: Fable supera Opus (60,8 contro 55,4) e costa di più. Modello migliore, bolletta più alta.
Le esecuzioni con assistente sono dove le cose diventano interessanti.
A parità di assistente, l'ordinamento dei costi si inverte: Fable + Assistente costa meno di Opus + Assistente (1,86 $ contro 2,04 $), con un punteggio più alto (60,7 contro 54,6). Rispetto a Fable puro, Fable + Assistente riduce il costo del 54% lasciando il punteggio quasi invariato.
Configurazione | Punteggio | Costo/esecuzione (media) |
|---|---|---|
Fable 5 (low) + Sidekick | 60,7 | 1,86 $ |
Opus 4.8 (medium) + Sidekick | 54,6 | 2,04 $ |
Fable 5 (low) | 60,8 | 4,03 $ |
Opus 4.8 (medium) | 55,4 | 3,06 $ |
Il premio del doppio per token si rivela il numero sbagliato da considerare. Il costo di un agente è dominato da quanti turni il modello principale impiega, quanto contesto si trascina dietro e, soprattutto, cosa decide non fare da solo. La differenza si riduce allo stile di gestione: Opus si comporta come un micromanager con uno stagista; Fable è un manager con un ingegnere capace.
La configurazione
Un rapido ripasso su come funziona l'architettura sidekick di Fusion. L'agente principale possiede la sessione: parla con l'utente, pianifica, rivede il lavoro e fa commit. Ha anche un sidekick subagente persistente per delegare compiti. Il principale scrive un brief di passaggio in linguaggio naturale, e il subagente, alimentato da un modello molto più economico, lo esegue nel proprio contesto e riporta i risultati. Il principale esamina il risultato e decide cosa fare dopo.
Per scoprire dove va il costo, abbiamo fatto due cose. Prima, abbiamo analizzato ogni chiamata LLM in tutte le 3.000 sessioni: quale modello parlava, quale strumento chiamava, quanti token leggeva e scriveva, e quanto costava ogni chiamata. Secondo, abbiamo selezionato 40 attività per un esame più approfondito: quelle in cui Fable era drasticamente più economico, quelle in cui lo era Opus, e un altro campione casuale dal mezzo. Per ciascuna, abbiamo analizzato l'esecuzione guidata da Fable affianco a quella guidata da Opus, esaminando le traiettorie e osservando dove andavano a finire i dollari.
Costo di un agente
Ecco come il costo si divide tra il principale e il sidekick nel nostro esperimento:
Principale $ | Sidekick $ | Totale $/esecuzione | Turni principali/esecuzione | Token di input principali (cumulativi) | |
|---|---|---|---|---|---|
Fable + Sidekick | 1,28 $ | 0,58 $ | 1,86 $ | 11,5 | 545k tok |
Opus + Sidekick | 1,73 $ | 0,31 $ | 2,04 $ | 26,5 | 1.679k tok |
Fable spende di più per il suo sidekick rispetto a Opus — 0,27 $ in più per esecuzione. Ma spende 0,45 $ in meno su se stesso. Il principale di Fable impiega 11,5 turni per esecuzione contro i 26,5 di Opus, scrive un terzo dei token di output (6,1k contro 19,0k) e consuma un terzo dei token di input. Fable è significativamente più costoso per token, ma vince nella gestione del contesto e nel numero di turni.
I risparmi di token di Fable derivano dall'evitare completamente il lavoro. È interessante notare che nell'81% delle esecuzioni guidate da Fable, il principale non effettua mai una singola modifica al codice. Per Opus, questo vale solo per il 24% delle esecuzioni. Nel 13% delle esecuzioni guidate da Fable, il principale non legge nemmeno un file del repository.
Un micromanager con uno stagista vs un manager con un ingegnere
Ecco cosa rende interessante il divario: entrambi i principali delegano lo stesso numero di volte, circa 3 passaggi per esecuzione. I log per chiamata smentiscono la facile spiegazione che Fable deleghi semplicemente di più. Ciò che differisce è quando e cosa delegano. Il primo passaggio di Fable arriva presto. Opus spesso delega tardi, dopo un lungo tratto di esplorazione e implementazione in solitaria; a quel punto, le decisioni di progettazione sono state prese, i file importanti sono nel suo contesto e il lavoro costoso è stato fatto.
GIF
Un'esecuzione tipica guidata da Fable esegue alcune azioni di ricognizione sul repository, poi scrive un brief di qualità specifica delegando l'intero ciclo implementazione + test + lint. Poi un git show per rivedere il diff e un commit.
Un'esecuzione tipica guidata da Opus passa attraverso 20–45 turni di esplorazione, progettazione e implementazione in solitaria, e un passaggio tardivo per la coda meccanica.
A volte la prima azione di Fable in una sessione è un passaggio. Sullo stesso compito, i due principali hanno aperto in questo modo:
La soluzione ovvia è far sì che Opus deleghi più esplorazione, ma forzare quel comportamento tende a diminuire le prestazioni. Sapere quando un'indagine è sicura da delegare e quando è qualcosa che bisogna fare da soli è di per sé un giudizio. Un modello costretto a delegare non acquisisce quel giudizio; delega solo le cose sbagliate.
Lo stile di gestione di ciascun modello si rivela anche nei brief di passaggio stessi. Quando Opus delega l'implementazione, detta, mentre Fable scrive un documento di progettazione:
La delega non sposta solo il costo; cambia anche la qualità del lavoro. Il compito di hashing sopra è un esempio lampante. La specifica del compito richiedeva che una funzione di hash fosse O(1) nella lunghezza del puntatore. Opus l'ha implementata a mano e non ha mai annotato quel requisito da nessuna parte. A un certo punto ha dimenticato il vincolo e ha rilasciato un'implementazione a tempo lineare, che ha ottenuto un punteggio di 25. Al contrario, Fable ha delegato utilizzando vincoli di alto livello. Il suo brief diceva: "operator() deve essere O(1) nella lunghezza del puntatore: NESSUNA scansione completa del token." Il sidekick ha implementato con successo questo, ottenendo un punteggio di 94.
Abbiamo scoperto che questo schema si generalizza tra i compiti. I passaggi di Fable enumeravano vincoli, casi limite e una definizione di "fatto", risparmiando sforzo a sé stesso e consentendo al sidekick di completare l'implementazione in modo economico e corretto.
Dopo il passaggio
L'altra metà è ciò che l'agente principale fa con il lavoro che torna dal sidekick. Entrambi i principali eseguono spesso lo stesso controllo economico: due o tre chiamate git diff/git show. Ma Opus non si ferma qui. Recupera i file del sidekick nel proprio contesto 2x più spesso e apporta 4x più modifiche correttive ai prezzi del principale. Nel caso estremo, ha annullato il lavoro del sidekick e lo ha riscritto a mano:
La sfiducia di Opus non aumenta nemmeno la correttezza. In alcuni compiti di valutazione, la singola revisione del diff di Fable ha catturato veri bug del sidekick, e ha optato per un altro passaggio economico, invece della riscrittura al livello del principale a cui Opus ricorre così spesso.
Quando la delega non aiuta
La strategia di delega di Fable non è universalmente utile; fallisce quando il compito non ha componenti delegabili. I seguenti tipi di compiti sembravano difficili da scomporre:
- Compiti brevi che includono solo una manciata di turni del modello principale, senza nulla da delegare tra la decisione e il rilascio.
- Compiti di debug seriali in cui la caccia alla causa principale è una lunga catena di giudizi. Qui, il contesto accumulato è il lavoro.
È interessante notare che in questi compiti Fable delega a malapena. Lo stesso giudizio che scrive un buon brief sa anche quando non scriverne uno. Ma quando un compito non offre nulla di degno di essere passato, la delega non ha alcuna leva sul costo.
In produzione, Fusion gestisce questo a un altro livello: la delega controlla quale lavoro rimane al modello costoso, mentre il routing decide se il modello costoso è coinvolto o meno.
Conclusione
Abbiamo iniziato questo esperimento aspettandoci di misurare quanto il premio del doppio di Fable avrebbe aumentato il costo. Siamo rimasti sorpresi nello scoprire che la delega efficace di Fable ha effettivamente ridotto il costo complessivamente. Ha specificato vincoli e risultati invece di dettagliare l'implementazione, ha dato feedback invece di apportare correzioni da solo e nella maggior parte dei casi non ha mai toccato il codice. Queste sono le abitudini di un buon manager.
Man mano che i modelli sidekick diventano più economici e migliori, più lavoro può essere affidato a loro. Ciò che rimarrà degno dei prezzi frontier è il giudizio: cosa costruire, cosa vincolare e chi dovrebbe scriverlo.
