Fable 5 ist weg. So erziele ich bessere Ergebnisse für weniger Geld.
Wir hatten 3 Tage mit Fable.
3 Tage, in denen autonomes Coding, langfristige Problemlösung und Research-Synthese sich grundlegend anders anfühlten. Nicht "etwas besser als letztes Quartal" anders. Etwas völlig anderes.
Dann schickte das US-Handelsministerium einen Brief, und das Modell ging für jeden Nutzer weltweit offline, Amerikaner eingeschlossen, weil es keine andere rechtliche Option gab. Der Zugang verschwand von live zu weg, ohne Übergangszeit und ohne angebotenen Migrationspfad.
Und wir wissen nicht, ob wir jemals wieder ein Modell auf diesem Level sehen werden.
Der Elektroschock war nicht das Verbot selbst. Es war das, was das Verbot offenlegte: unser gesamter Produktions-Workflow läuft auf einer Infrastruktur, die 1 Regierungsbrief in 12 Stunden abschalten kann.
Inakzeptabel für Prod.
Anstatt also Leaderboards nach dem nächstbesten Modell zu durchsuchen oder auf eine Wiederherstellung zu warten, die vielleicht nie kommt, war der richtige Schritt eine andere Frage zu stellen. Nicht "was ersetzt Fable." Die eigentliche Frage: wenn wir kritische Arbeit zu einem einzigen Frontier-Orakel routen, was kaufen wir dann? Und ob etwas strukturell Besseres existiert.
TL;DR: Ein Panel aus Modellen mit einem Frontier-Judge schlägt Fable 5 solo bei Deep-Research-Benchmarks, und in der Budget-Konfiguration läuft es zu etwa der Hälfte der Kosten. Das Problem ist nicht, dass Fable weg ist. Es ist, dass wir etwas Besseres entdeckt haben, während es noch da war.
Die Nacht, als Fable offline ging
Die meisten Leute hatten dieselben 3 Reflexe: das nächstbeste Modell in den Leaderboards finden, warten bis Fable zurückkommt, auf X meckern.
Alle 3 sind der falsche Ansatz.
Das Fable-Verbot war ein Datenpunkt, keine Anomalie. Das ist das erste Mal, dass eine US-Regierungsanweisung ein kommerziell eingesetztes Frontier-Modell global in unter 12 Stunden vom Netz genommen hat. Es wird nicht das letzte Mal sein, dass ein Modell, auf das wir angewiesen sind, aus welchem Grund auch immer verschwindet, ohne sanfte Übergabe.
Wenn deine Produktions-Pipeline eine Single-Model-Abhängigkeit hat, hat das Fable-Verbot dieses Architekturproblem gerade sichtbar gemacht.
Ich schrieb über das Verbot am Tag, als es passierte. Das hier ist, was ich die Woche danach gebaut habe.
Die Orakel-Falle
Einen Prompt an 1 Modell zu senden bedeutet, nach 1 Perspektive zu fragen: 1 Architektur, 1 Training-Mix, 1 Set von Fehlermodi. Nennen wir es beim Namen: ein Orakel. Alle harten Entscheidungen durch 1 Frontier-Modell zu routen ist das LLM-Äquivalent zum Full-Glass-Cannon-Build: maximaler Output an guten Tagen, und 1 unerwarteter Zug nimmt den ganzen Build offline.
Laut TokenMix' Aufschlüsselung von OpenRouters veröffentlichten DRACO-Benchmark-Ergebnissen erzielte Fable 5 solo 65,3% bei einer 100-Task Deep-Research-Evaluation zu Recht, Medizin, Finanzen und Produktanalyse. Ein Panel aus Fable 5 und GPT-5.5, mit Opus 4.8 als Judge, erzielte 69,0%.
Der interessantere Datenpunkt ist das Budget-Panel: Gemini 3 Flash, Kimi K2.6, DeepSeek V4 Pro. Diese Kombination erzielte 64,7%, innerhalb von 1 Benchmark-Punkt zu Fable 5, bei etwa 40% der Kosten.
Ein Vorbehalt, bevor du das screenshottest: DRACO hat keine Coding-Domäne. Diese Zahlen decken Research- und Analyse-Tasks ab, juristische Synthese, medizinische Argumentation, vergleichende Bewertung. Für reine Code-Generierung übertragen sich die Daten nicht direkt. Behalte das im Kopf.
Da steckt ein längerer Gedanke in diesen Zahlen. Die gesamte Prämisse des Frontier-Model-Rennens war, dass intelligentere Einzelmodelle bessere Ergebnisse produzieren, und die richtige Investition ist, jedes gegebene Modell intelligenter zu machen. Die DRACO-Ergebnisse legen einen anderen Ansatz nahe: die Architektur der Beratschlagung übertrifft die Intelligenz jeder einzelnen Stimme. Das Management versteht das seit Jahrzehnten (Komitees, Red Teams, Advocatus Diaboli, Peer Review). Du setzt deinen teuersten Analysten nicht allein in einen Raum und akzeptierst das erste, was er sagt. Du baust einen Prozess, der Meinungsverschiedenheiten erzwingt und sie dann auflöst. AI-Entwicklung fuhr 5 Jahre lang das Intelligenteres-Einzelmodell-Playbook, ohne zu fragen, ob ein strukturiertes Argument zwischen 3 mittelstarken Systemen den unbestrittenen Output eines außergewöhnlichen übertreffen könnte. Stellt sich heraus: könnte sein.
Die meisten Benchmarks messen einen Sprint. Der Perspective Council führt ein Komitee, was langsamer und nerviger ist, und generell richtiger.
Der Perspective Council
2 Ansätze existierten vorher.
Vorher:
Der Panel-Ansatz: denselben Prompt parallel an mehrere Modelle senden, einen Judge synthetisieren lassen. Du bekommst Modell-Diversität (verschiedene Architekturen, verschiedenes Training, verschiedene Fehlermodi). Das Panel punktet höher als jedes einzelne Mitglied, weil korrelierte Fehler von unabhängigen überstimmt werden.
Der Multi-Perspective-Scan: 1 Modell sequenziell verschiedene Experten-Personas zuweisen. "Antworte als Security-Architekt." "Antworte als skeptischer Ökonom." Du bekommst Rollen-Diversität, verschiedene Reasoning-Frames vom selben zugrundeliegenden Modell.
Nachher:
Der Perspective Council stapelt beide gleichzeitig. Jedes Panelist-Modell erhält einen anderen Experten-Persona-Prefix, bevor es deinen Prompt verarbeitet. Die Security-Architekt-Persona geht an 1 Modell, der skeptische Ökonom an ein anderes, der System-Historiker an ein drittes.
Der Judge (ein separater Frontier-Model-Call) liest alle Antworten, notiert wo die Experten übereinstimmen, notiert wo sie sich widersprechen, und synthetisiert einen einzigen Output aus dem Muster.
Warum das beide Ansätze allein übertrifft: ein Panel ohne Rollen-Diversität bekommt architektonische Varianz aber korrelierte Reasoning-Frames. 2 Frontier-Modelle mit ähnlichem Training können dieselbe falsche Schlussfolgerung durch verschiedene Mechanismen erreichen. Ein Multi-Perspective-Scan mit 1 Modell bekommt Frame-Diversität aber 1 Set architektonischer blinder Flecken. Der Perspective Council bekommt beide Varianz-Achsen auf einmal.
Ich denke, das ist der Kern, warum die Benchmark-Zahlen halten, obwohl ich unabhängige Replikation wollen würde, bevor ich es als gesicherte Wissenschaft behandle.
Etwas, das mir beim Testen auffiel: Ich schickte dieselbe Architektur-Frage zweimal in derselben Session durch Opus 4.8. Erst als direkter Panelist, dann als Judge, der 3 andere Modell-Outputs synthetisiert. Die Panelist-Antwort war vollständig und selbstbewusst. Die Judge-Antwort fing 2 Annahmen ab, die der Panelist nicht hinterfragt hatte. Dasselbe Modell, dieselbe Frage, verschiedene Position in der Kette, verschiedene Antwort. Darüber denke ich nach.
Scharfe Persona-Prefixes sind der Punkt, wo das entweder funktioniert oder kollabiert. Vage Personas produzieren stilistische Variation, keine echte Meinungsverschiedenheit. Scharfe Briefs produzieren den Widerspruch, den der Judge braucht, um seinen Job zu machen, und das vollständige Prompt-Contracts-Framework (das Input/Output-Contracts für jeden LLM-Call abdeckt) überträgt sich direkt auf Persona-Design: jeder Prefix ist ein Contract, der spezifiziert, welches Optimierungsziel diese Stimme verfolgt.
3 Wege, das aufzusetzen
Die Persona ist ein Prompt-Prefix. Du injizierst ihn vor deinen eigentlichen Prompt in jedem Panelist-Call. Jedes Tool unterstützt das nativ. Die Infrastruktur-Wahl geht darum, wie du die parallelen Calls und die Judge-Synthese orchestrierst.
Level 1: OpenRouter Fusion
1 Zeilen-Änderung: "model": "openrouter/fusion". Fusion fächert deinen Prompt zu einem Panel von Modellen parallel auf, jedes mit aktivierter Web-Suche, mit einem Judge, der das Ergebnis synthetisiert. Für die Persona-Schicht prefixe deinen Prompt manuell, bevor er Fusion erreicht. Du kontrollierst nicht, welches zugrundeliegende Modell welche Rolle erhält, Fusion managed das intern.
Am besten für: das Konzept in unter 5 Minuten validieren, ohne deine Infrastruktur anzufassen. Ausnahmsweise: wenn es auf deiner Maschine funktioniert, funktioniert es auch in Prod.
Limit: keine granulare Kontrolle über Persona-zu-Modell-Routing.
Level 2: Gavel
Läuft Claude, Codex und Gemini parallel über deine bestehenden API-Keys. Claude übernimmt die Judge-Position. Die anderen Modelle sind read-only auf deinen Files, was das sicher für echte Codebases macht (Nicht-Claude-Modelle können nichts schreiben). Jedes Modell erhält seine Experten-Persona durch die Task-Prompt-Config.
Am besten für: Builder, die bereits 3 API-Subscriptions haben und den Routing-Code besitzen wollen.
Level 3: OrcaRouter Routing DSL
OrcaRouters YAML-basierte Routing DSL lässt dich ein Panel in etwa 12 Zeilen definieren: welche Modelle auffächern, welches Modell judged, welche Arbitration-Strategie läuft (best_of_n, consensus, first_to_finish). Ihr Blog veröffentlicht eine wörtliche funktionierende Config als Startpunkt. Die Personas gehen in die Prompt-Calls, nicht ins YAML. Das YAML handhabt Orchestrierung, der Prompt handhabt Rolle.
Für Fälle, wo Präzision wichtiger als Latenz ist, wiederholt llm-consortium das Panel, bis es auf einem Confidence-Threshold konvergiert. Mehr Latenz, präziser, und wissenswert. Wenn du eine vollständig self-hosted CLI-Alternative bevorzugst, deckt OpenFusion best_of_n und consensus ohne die Managed-Schicht ab.
Am besten für: Produktions-Setups, wo du den Routing-Graph versionieren, jeden Call loggen und die Strategie ohne Redeployment updaten musst.
Wähle basierend darauf, wo du stehst: Fusion, um das Konzept heute zu validieren. Gavel, wenn du bereits 3 API-Subscriptions hast und den Code lieber besitzt. OrcaRouter, wenn du etwas Produktions-kritisches baust, das den nächsten Infrastruktur-Incident überleben muss, ohne zu brechen.
Wann der Council seine Kosten rechtfertigt
Die Regel: der Council entscheidet, der leichtgewichtige Agent führt aus. Denk daran wie an den Raid-Leader, der das Kill-Target markiert, während der DPS die eigentliche Mechanik handhabt: der teure Call ist die Strategie, nicht die Ausführung.
Nicht jeder Prompt verdient ein Komitee. Bevor du eines einberufst, ist der Test einfach: hättest du Fable 5-Raten dafür bezahlt? Wenn ja, führe den Council aus. Wenn du standardmäßig zu Haiku oder Flash gegangen wärst, tu es nicht.
Wo er seinen Platz in einem Claude Code-Workflow verdient:
Architektur-Entscheidungen vor einer langen agentischen Schleife. Lass den Council über den Ansatz beraten. Ein schneller Agent implementiert. Du zahlst Frontier-Raten einmal, für die Entscheidung, nicht für jede Implementierungszeile.
Migrations-Planung. Der Council schreibt die Spec. Deine CLI-Agent-Armee führt sie aus. Der teure Call ist die Entscheidung, nicht der Rollout.
Sub-Agent-Zieldefinition. Bevor du einen Long-Horizon-Agent startest, lass den Council die Mission schreiben. Mehrdeutige Ziele sind der Punkt, wo autonome Agenten entgleisen (jeder Claude Code-User hat das gesehen). Mach das Ziel eindeutig, bevor der Agent zu laufen beginnt.
Knowledge-Base-Strukturierung. Taxonomie-Entscheidungen, Schema-Design. Entscheidungen, die billig aussehen, aber sich teuer potenzieren, wenn sie falsch sind.
Das zugrundeliegende Muster: front-load Beratschlagung, back-load Ausführung. Der teure Fehler sind nicht 3 extra Sekunden Latenz. Es ist der falsche Call, der die ganze Schleife seitwärts schickt.
Die Kosten-Falle
Bevor du alles durch einen Council routest: die Ökonomie funktioniert nicht so.
Das Budget-Preset (Gemini 3 Flash, Kimi K2.6, DeepSeek V4 Pro) läuft bei etwa 40% eines Fable 5 Solo-Calls, laut TokenMix' Aufschlüsselung. Da lebt der "halber Preis"-Claim, und er ist akkurat für diese Konfiguration.
Das Quality-Preset (Frontier-Modelle als Panelists, Frontier-Modell als Judge) kostet etwa 3x einen einzelnen Opus 4.8-Call. Teurer als Fable war. Du führst 3 Frontier-Calls plus einen Judge-Call für jeden Prompt aus.
Die Entscheidung:
Wenn die Task Fable-Raten rechtfertigte und Qualität dein Constraint ist: Quality-Preset. Strukturierte Beratschlagung, bessere Antworten bei hartem Research und Analyse.
Wenn die Task Fable-Raten rechtfertigte aber Kosten dein Constraint sind: Budget-Preset. Innerhalb von 1 Benchmark-Punkt zu Fable bei 40% des Preises.
Wenn die Task keine Fable-Raten rechtfertigte: ein einzelnes schnelles billiges Modell ist die richtige Antwort. "Fasse dieses Changelog zusammen" durch ein 4-Modell-Panel zu routen ist, wie du Budget für etwas verbrennst, was ein $0.001-Call gut handhabt. Der Council ist ein Entscheidungs-Tool für Entscheidungen, die es rechtfertigen, kein universeller API-Proxy.
Bevor wir mit DRACO schließen: keine Coding-Domäne. Das Signal ist stark für Research und Analyse. Für reine Code-Generierung übertragen sich die Benchmark-Zahlen nicht. Behandle die 64,7% Budget-Stat als Signal für Research-Arbeit, nicht als Performance-Garantie für Coding-Workflows.
Was Fable uns wirklich lehrte
Der Großteil der Unterhaltung seit dem 12. Juni handelte davon, Fable zurückzubekommen. Wann es zurückkehrt, ob es zurückkehrt, was die Verhandlungen bedeuten.
Das ist die falsche Unterhaltung.
Das Verbot zwang eine Frage auf, die wir früher hätten stellen sollen: wofür optimieren wir, wenn wir alles zu 1 Frontier-Modell routen? Die implizite Antwort für die meisten Teams war Zugang zum fähigsten Einzelsystem. Größtes Modell, beste Ergebnisse.
Die DRACO-Zahlen legen nahe, dass das der falsche Ansatz war, nicht weil Frontier-Modelle schlecht sind, sondern weil die Architektur falsch war. Wir setzten unsere fähigsten Modelle in Orakel-Position: First Responder, einzelne Stimme, finale Antwort. Das ist die schlechteste Nutzung dessen, worin ein Frontier-Modell tatsächlich gut ist.
Die Stärke eines Frontier-Modells ist Synthese und Urteilsvermögen. Die Synthese-Position ist, wo es das verdient, was du dafür zahlst, und die Panelists können billiger sein, weil sie Varianz liefern, nicht Auflösung. Fable in den Input-Slot zu setzen und seine erste Antwort zu nehmen verschwendete beides.
Wenn das nächste Modell offline geht (und es wird), beginne mit Chain-Position, nicht Modell-Auswahl.
Ich verbrachte 3 Tage damit, nach einem Fable-Ersatz zu suchen. Was ich fand: Ich hätte es von Anfang an in den Judge-Sitz setzen sollen.
Setze dein bestes Modell ans Ende der Kette, nicht an den Anfang.
Quellen
- OpenRouter Fusion announcement, Juni 2026
- TokenMix: OpenRouter Fusion API Review 2026, DRACO-Benchmark und Kosten-Aufschlüsselung
- OrcaRouter Routing DSL documentation
- Gavel on GitHub
- OpenFusion on GitHub
- irthomasthomas/llm-consortium on GitHub
- Claude Fable 5 is currently unavailable
Dieser Post kann Affiliate-Links enthalten. Wenn du sie klickst, verdiene ich möglicherweise eine kleine Provision, kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel zu liefern.