Fable günstiger als Opus machen

Wir haben Opus 4.8 durch Fable 5 ersetzt, und die Rechnung von Devin wurde günstiger.

Fable 5 kostet pro Token doppelt so viel wie Opus 4.8. Aber als wir beide Modelle mit unserer neuen Fusion-Architektur auf FrontierCode 1.1 laufen ließen, war Fable günstiger. Kein Wunder, es erzielte auch bessere Ergebnisse. Dieser Beitrag erklärt, warum das so ist und was das für die Preisgestaltung von agentischen Arbeiten bedeutet.

Einleitung

Jeder, der Code-Agenten betreibt, weiß: Stärkere Modelle liefern bessere Ergebnisse, aber das kostet.

Als wir Devin Fusion vorgestellt haben, zeigten wir einen Ausweg: Ein Frontier-Modell hat das Kommando, delegiert an einen günstigeren und schnelleren Sidekick, und man erhält Frontier-Level-Leistung zu 35 % niedrigeren Kosten.

Aber sobald das Leitmodell den Großteil der Arbeit delegiert, dominiert dann sein Preis pro Token immer noch die Rechnung? Fable 5 kostet 2x mehr pro Token als Opus 4.8, also sollte ein von Fable geführter Agent teurer sein. Um das herauszufinden, haben wir 3.000 Evaluierungssitzungen auf FrontierCode 1.1 in vier Konfigurationen durchgeführt: Fable und Opus in der Führungsrolle, jeweils mit und ohne denselben günstigen Sidekick.

Die reinen Läufe verhalten sich genau so, wie man es erwarten würde: Fable übertrifft Opus (60,8 vs. 55,4) und kostet mehr. Besseres Modell, höhere Rechnung.

Die Läufe mit Sidekick werden interessant.

Mit demselben Sidekick kehrt sich die Kostenordnung um: Fable + Sidekick kostet weniger als Opus + Sidekick (1,86 $ vs. 2,04 $), während es höher punktet (60,7 vs. 54,6). Im Vergleich zu reinem Fable senkt Fable + Sidekick die Kosten um 54 %, während die Punktzahl nahezu unverändert bleibt.

Konfiguration

Punktzahl

Kosten/Lauf (Mittelwert)

Fable 5 (niedrig) + Sidekick

60,7

1,86 $

Opus 4.8 (mittel) + Sidekick

54,6

2,04 $

Fable 5 (niedrig)

60,8

4,03 $

Opus 4.8 (mittel)

55,4

3,06 $

Die 2-fache Prämie pro Token erweist sich als die falsche Kennzahl. Die Kosten eines Agenten werden dominiert von der Anzahl der Iterationen, die das Leitmodell durchführt, wie viel Kontext es mit sich schleppt, und vor allem, was es nicht selbst macht. Der Unterschied liegt im Führungsstil: Opus verhält sich wie ein Mikromanager mit einem Praktikanten; Fable ist ein Manager mit einem fähigen Ingenieur.

Der Aufbau

Eine kurze Auffrischung, wie Fusions Sidekick-Architektur funktioniert. Der Leitagent besitzt die Sitzung: Er spricht mit dem Nutzer, plant, überprüft die Arbeit und committed. Er hat auch einen persistenten Sidekick-Subagenten für die Delegation von Aufgaben. Der Leitagent schreibt eine Übergabe-Zusammenfassung in natürlicher Sprache, und der Subagent, der von einem viel günstigeren Modell betrieben wird, führt sie in seinem eigenen Kontext aus und berichtet zurück. Der Leitagent überprüft das Ergebnis und entscheidet, was als Nächstes passiert.

Um herauszufinden, wo die Kosten anfallen, haben wir zwei Dinge getan. Erstens haben wir jeden LLM-Aufruf über alle 3.000 Sitzungen hinweg analysiert: Welches Modell sprach, welches Tool es aufrief, wie viele Token es las und schrieb, und was jeder Aufruf kostete. Zweitens haben wir uns 40 Aufgaben genauer angesehen: diejenigen, bei denen Fable dramatisch günstiger war, diejenigen, bei denen Opus günstiger war, und eine weitere zufällige Stichprobe aus der Mitte. Für jede haben wir den von Fable geführten Lauf mit dem von Opus geführten Lauf Seite an Seite analysiert, die Verläufe untersucht und beobachtet, wohin das Geld floss.

Kosten eines Agenten

So teilen sich die Kosten zwischen Leit- und Sidekick in unserem Experiment auf:

Leitmodell $

Sidekick $

Gesamt $/Lauf

Leitmodell-Iterationen/Lauf

Eingabe-Token des Leitmodells (kumulativ)

Fable + Sidekick

1,28 $

0,58 $

1,86 $

11,5

545k Token

Opus + Sidekick

1,73 $

0,31 $

2,04 $

26,5

1.679k Token

Fable gibt mehr für seinen Sidekick aus als Opus – 0,27 $ mehr pro Lauf. Aber es gibt 0,45 $ weniger für sich selbst aus. Fables Leitmodell benötigt 11,5 Iterationen pro Lauf gegenüber 26,5 bei Opus, schreibt ein Drittel der Ausgabe-Token (6,1k vs. 19,0k) und verbraucht ein Drittel der Eingabe-Token. Fable ist pro Token deutlich teurer, gewinnt aber beim Kontextmanagement und der Anzahl der Iterationen.

Fables Tokeneinsparungen entstehen durch die Vermeidung von Arbeit an sich. Interessanterweise führt das Leitmodell in 81 % der von Fable geführten Läufe nie selbst eine Codebearbeitung durch. Bei Opus trifft das nur auf 24 % der Läufe zu. In 13 % der von Fable geführten Läufe liest das Leitmodell nicht einmal selbst eine Repository-Datei.

Ein Mikromanager mit einem Praktikanten vs. ein Manager mit einem Ingenieur

Hier liegt der interessante Unterschied: Beide Leitmodelle delegieren gleich oft, etwa 3 Übergaben pro Lauf. Die Protokolle pro Aufruf widerlegen die einfache Erklärung, dass Fable einfach mehr delegiert. Was sich unterscheidet, ist wann und was sie delegieren. Fables erste Übergabe erfolgt früh. Opus delegiert oft spät, nach einer langen Phase der Erkundung und Implementierung; dann sind die Designentscheidungen gefallen, die wichtigen Dateien sind im Kontext und die teure Arbeit ist erledigt.

GIF

Ein typischer von Fable geführter Lauf unternimmt ein paar Aufklärungsaktionen im Repository, schreibt dann eine spezifikationsähnliche Zusammenfassung, die den gesamten Implementierungs-, Test- und Lint-Zyklus delegiert. Dann ein git show, um den Diff zu überprüfen, und ein Commit.

Ein typischer von Opus geführter Lauf durchläuft 20–45 Iterationen der Erkundung, des Designs und der Implementierung allein, mit einer späten Übergabe für den mechanischen Rest.

Manchmal ist Fables erste Aktion in einer Sitzung eine Übergabe. Bei derselben Aufgabe begannen die beiden Leitmodelle wie folgt:

Die offensichtliche Lösung wäre, Opus zu mehr Delegation zu zwingen, aber dieses Verhalten zu erzwingen, verringert tendenziell die Leistung. Zu wissen, wann eine Untersuchung sicher delegiert werden kann und wann man sie selbst durchführen muss, ist selbst eine Ermessensentscheidung. Ein Modell, das zur Delegation gezwungen wird, erlangt dieses Urteilsvermögen nicht; es delegiert nur die falschen Dinge.

Der Führungsstil jedes Modells zeigt sich auch in den Übergabe-Zusammenfassungen selbst. Wenn Opus die Implementierung delegiert, diktiert es, während Fable ein Design-Dokument schreibt:

Delegation verschiebt nicht nur Kosten, sondern verändert auch die Qualität der Arbeit. Die obige Hashing-Aufgabe ist ein eindrucksvolles Beispiel. Die Aufgabenbeschreibung verlangte eine Hash-Funktion, die in der Länge des Zeigers O(1) sein sollte. Opus implementierte es von Hand und schrieb diese Anforderung nirgendwo auf. Irgendwann vergaß es die Einschränkung und lieferte eine lineare Implementierung aus, die 25 Punkte erzielte. Im Gegensatz dazu delegierte Fable mit übergeordneten Einschränkungen. In seiner Zusammenfassung hieß es: „operator() muss in der Zeigerlänge O(1) sein: KEIN vollständiger Token-Scan.“ Der Sidekick implementierte dies erfolgreich und erzielte 94 Punkte.

Wir haben festgestellt, dass dieses Muster über verschiedene Aufgaben hinweg gilt. Fables Übergaben zählten Einschränkungen, Randfälle und eine Definition von „fertig“ auf, sparten sich selbst Arbeit und ermöglichten es dem Sidekick, die Implementierung günstig und korrekt abzuschließen.

Nach der Übergabe

Die andere Hälfte ist das, was das Leitmodell mit der Arbeit macht, die vom Sidekick zurückkommt. Beide Leitmodelle führen oft denselben günstigen Check durch: zwei oder drei git diff/git show-Aufrufe. Aber Opus hört damit nicht auf. Es zieht die Dateien des Sidekicks 2x häufiger in seinen eigenen Kontext und nimmt 4x mehr korrigierende Bearbeitungen zu Leitmodell-Preisen vor. Im Extremfall hat es die Arbeit des Sidekicks rückgängig gemacht und von Hand neu geschrieben:

Das Misstrauen von Opus erhöht auch nicht die Korrektheit. Bei einigen Evaluierungsaufgaben erkannte Fables einfache Diff-Überprüfung tatsächliche Sidekick-Fehler und entschied sich für eine weitere günstige Übergabe, anstatt für die von Opus so oft bevorzugte Neufassung auf Leitmodell-Ebene.

Wann Delegation nicht hilft

Fables Delegationsstrategie ist nicht universell nützlich; sie versagt, wenn die Aufgabe keine delegierbaren Komponenten hat. Die folgenden Arten von Aufgaben schienen schwer zu zerlegen:

• Kurze Aufgaben, die nur eine Handvoll Leitmodell-Iterationen umfassen, mit nichts zu delegieren zwischen Entscheidung und Auslieferung.
• Serielle Debugging-Aufgaben, bei denen die Ursachensuche eine lange Kette von Entscheidungen ist. Hier ist der angesammelte Kontext die Arbeit.

Bemerkenswerterweise delegiert Fable bei diesen Aufgaben kaum. Dasselbe Urteilsvermögen, das eine gute Zusammenfassung schreibt, weiß auch, wann man keine schreiben sollte. Aber wenn eine Aufgabe nichts bietet, das sich zu delegieren lohnt, hat Delegation keinen Hebel auf die Kosten.

In der Produktion behandelt Fusion dies auf einer anderen Ebene: Delegation steuert, welche Arbeit beim teuren Modell bleibt, während das Routing entscheidet, ob das teure Modell überhaupt beteiligt wird.

Abschluss

Wir begannen dieses Experiment mit der Erwartung, zu messen, wie sehr Fables 2-fache Prämie die Kosten erhöhen würde. Wir waren überrascht zu finden, dass Fables effektive Delegation die Kosten tatsächlich insgesamt senkte. Es spezifizierte Einschränkungen und Ergebnisse, anstatt die Implementierung im Detail vorzugeben, gab Feedback, anstatt selbst Korrekturen vorzunehmen, und berührte in den meisten Fällen überhaupt keinen Code. Das sind die Gewohnheiten eines guten Managers.

Wenn Sidekick-Modelle günstiger und besser werden, kann mehr Arbeit an sie übergeben werden. Was weiterhin Frontier-Preise wert sein wird, ist Urteilsvermögen: was zu bauen ist, was einzuschränken ist und wer es schreiben sollte.