Mich interessiert an Cognitions neuem Vergleich weniger, welches Modell gewinnt. Spannender ist die Architekturlektion dahinter: Ein teures Lead-Modell kann den günstigeren Gesamtprozess erzeugen, wenn es Arbeit früh und präzise delegiert, Ergebnisse gezielt prüft und den eigenen Kontext klein hält.
Cognition hat für den Beitrag „Making Fable Cheaper Than Opus“ nach eigenen Angaben 3.000 Evaluationsläufe auf FrontierCode 1.1 ausgewertet. Verglichen wurden Fable 5 und Opus 4.8 jeweils allein und zusammen mit demselben günstigeren Sidekick-Modell in der Fusion-Architektur.
Ohne Sidekick folgt das Ergebnis der üblichen Logik: Fable erzielt den höheren Score und kostet mehr. Mit Sidekick dreht sich die Kostenreihenfolge jedoch um. Fable plus Sidekick kostet laut Cognition im Mittel 1,86 US-Dollar pro Lauf und erreicht 60,7 Punkte. Opus plus Sidekick kostet 2,04 US-Dollar bei 54,6 Punkten. Gegenüber Fable allein sinken die Kosten mit Sidekick um 54 Prozent, während der Score nahezu gleich bleibt.
Diese Zahlen sind Ergebnisse eines vom Anbieter entwickelten Benchmarks und keine allgemeingültige Preisliste für reale Kundenprojekte. Trotzdem machen sie einen wichtigen Mechanismus sichtbar: Der Preis pro Token ist für agentische Arbeit eine unvollständige Kennzahl.
Der Lead-Agent ist kein besserer Programmierer, sondern ein besserer Arbeitsverteiler
Beide Lead-Modelle delegierten im Versuch ungefähr gleich oft, im Mittel rund dreimal pro Lauf. Der Unterschied lag also nicht in der Anzahl der Übergaben, sondern in ihrem Zeitpunkt und Inhalt.
Fable delegierte früh. Nach einer kurzen Orientierung gab es dem Sidekick ein vollständiges Arbeitspaket: Ziel, technische Randbedingungen, relevante Sonderfälle, Tests und Definition of Done. Der Sidekick konnte Implementierung, Tests und Korrekturen in seinem günstigeren Kontext erledigen. Der Lead prüfte anschließend den Diff und gab bei Bedarf Feedback.
Opus arbeitete im Vergleich oft lange selbst, las bereits zusammengefasste Dateien noch einmal, traf Designentscheidungen, implementierte und debuggte. Erst der mechanische Rest wurde delegiert. Damit war der größte Teil der teuren Arbeit bereits erledigt. Cognition beschreibt das zugespitzt als Unterschied zwischen einem Manager mit einem fähigen Engineer und einem Mikromanager mit einem Praktikanten.
Meine Einordnung: Delegation ist bei KI-Agenten keine reine Routing-Funktion. Sie ist eine Form von Urteilskraft. Das System muss erkennen, welche Arbeit delegierbar ist, welche Informationen der Sidekick wirklich braucht und wann der Lead selbst eingreifen muss.
Gute Übergaben sind komprimierte Architekturarbeit
Besonders interessant finde ich die Qualität der Handoffs. Fable diktierte nicht jeden einzelnen Code-Schritt. Es formulierte Randbedingungen, Qualitätskriterien und den erwarteten Zustand. Damit wurde der Handoff zu einer kleinen technischen Spezifikation.
Das passt zu meiner Erfahrung mit Coding-Agenten: Eine gute Übergabe enthält nicht möglichst viel Text, sondern die richtigen Entscheidungen. Was soll erreicht werden? Welche Grenzen dürfen nicht verletzt werden? Welche Tests belegen das Ergebnis? Was darf ausdrücklich nicht verändert werden? Genau diese Informationen ermöglichen Autonomie, ohne Kontrolle aufzugeben.
In einem Beispiel sollte eine technische Funktion unabhängig von der Länge der Eingabe immer gleich schnell arbeiten. Opus implementierte selbst, verlor diese Anforderung unterwegs aus dem Blick und lieferte eine Lösung, die mit zunehmender Eingabelänge langsamer wurde. Fable nahm die Vorgabe ausdrücklich in den Handoff auf; der Sidekick setzte sie korrekt um. Das zeigt: Delegation kann Qualität erhöhen, wenn wichtige Anforderungen in überprüfbare Vorgaben übersetzt werden.
Vertrauen heißt nicht, ungeprüft zu übernehmen
Fable überließ dem Sidekick viel Arbeit, aber nicht die Verantwortung für das Endergebnis. Der Lead prüfte Diffs, erkannte Probleme und delegierte Korrekturen erneut. Opus holte dagegen Dateien häufiger zurück in den eigenen Kontext und nahm deutlich mehr Korrekturen selbst vor – zu Lead-Modell-Kosten.
Für mich ist das ein wichtiges Muster für produktive Agentensysteme: Verantwortung bleibt beim orchestrierenden Agenten, Ausführung muss dort aber nicht ebenfalls stattfinden. Gute Kontrolle bedeutet, Ergebnisse gegen Kriterien zu prüfen und präzises Feedback zu geben. Sie bedeutet nicht, jede Arbeit vorsorglich noch einmal selbst zu erledigen.
Genau hier liegt auch eine Parallele zu menschlichen Teams. Wer delegiert, ohne Ziel und Grenzen zu erklären, produziert Rückfragen und Nacharbeit. Wer alles selbst kontrolliert und neu schreibt, skaliert nicht. Gute Führung definiert den Rahmen, schafft überprüfbare Übergaben und greift nur dort ein, wo Urteilskraft tatsächlich benötigt wird.
Was Unternehmen daraus messen sollten
Ich würde aus dem Experiment nicht ableiten, dass Unternehmen nun grundsätzlich Fable statt Opus wählen sollten. Modelle und Preise ändern sich schnell. Der dauerhafte Wert liegt in den Messgrößen, die Cognition sichtbar macht:
Gerade der letzte Punkt verhindert eine zu einfache Schlussfolgerung. Cognition beschreibt selbst, dass Delegation bei kurzen Aufgaben oder einer langen, seriellen Root-Cause-Analyse wenig bringt. Dort ist der aufgebaute Kontext nicht Ballast, sondern die eigentliche Arbeit. Ein gutes System muss deshalb auch erkennen, wann es nicht delegieren sollte.
Meine Einschätzung: Agentenökonomie wird zu einer Architekturdisziplin
Der Beitrag bestätigt für mich eine Entwicklung, die ich schon bei Devin Fusion und bei der Kostenbetrachtung von Agentic AI sehe: Wir sollten nicht mehr fragen, welches Modell am billigsten ist. Wir sollten fragen, welche Agentenarchitektur ein akzeptiertes Ergebnis mit möglichst wenig teurer Aufmerksamkeit erzeugt.
Dazu gehören Routing, aber auch Rollen, Kontextgrenzen, Spezifikationen, Reviews, Budgets und Stop-Regeln. Ein Frontier-Modell rechtfertigt seinen Preis nicht dadurch, dass es jeden Schritt selbst erledigt. Es rechtfertigt ihn dort, wo Urteilskraft knapp ist: beim Zerlegen einer Aufgabe, beim Setzen von Constraints, beim Erkennen von Risiken und bei der finalen Qualitätsentscheidung.
Ich halte Cognitions Ergebnis deshalb für relevant, aber nicht für einen universellen Modellvergleich. Es ist ein starkes Architekturbeispiel aus einer kontrollierten Evaluation. Ob der Kostenvorteil in einem konkreten Unternehmen bestehen bleibt, muss mit den eigenen Repositories, Aufgaben, Sicherheitsgrenzen und Review-Maßstäben gemessen werden.
Mein Fazit: Das teuerste Modell ist nicht automatisch der teuerste Agent. Teuer wird ein Agent vor allem dann, wenn sein Lead zu viel selbst macht, Kontext mehrfach aufbaut und Arbeit delegiert, nachdem der wirtschaftliche Hebel bereits verbraucht ist.