Fable ist weg, aber aufgeben gilt nicht ── Mit OpenRouter Fusion＋chinesischen LLMs＋Review-Schicht durchhalten

1. Fable ist tot. Und jetzt?

Ich sage es ehrlich: An Fable reicht das bei Weitem nicht heran.

Zum Zeitpunkt dieses Artikels hat Anthropic seinen KI-Coding-Agenten „Fable” eingestellt. Diese Präzision, diese Geschwindigkeit, dieses Gefühl der nahtlosen Integration — einen gleichwertigen Ersatz gibt es bislang nicht.

Trotzdem kann man nicht einfach die Hände in den Schoß legen. Sucht man nach Alternativen, sieht die Auswahl in etwa so aus:

• Claude Code / Claude Sonnet: Klug. Aber allein reicht es nicht an die Präzision von Fable heran, und die Kosten summieren sich
• GPT-5 / GPT-5.5: Überraschend schwach. Bei längeren Codebasen geht schnell die Puste aus. Und teuer ist es obendrein
• Cursor / Windsurf: Gute Nutzererfahrung, aber man ist vom zugrunde liegenden Modell abhängig. Freie Konfiguration ist nicht möglich
• Lokale LLMs (Ollama etc.): Schnell, aber sobald man ein echtes Repository übergibt, bricht die Präzision deutlich ein

Nach allerlei Ausprobieren bin ich schließlich bei folgendem Aufbau gelandet: Code generieren mit Fusion von OpenRouter＋chinesischen LLMs, und zum Abschluss ein Review durch gpt-5.5-pro oder eine PR-Review durch Codex. An Fable kommt das überhaupt nicht heran, ist aber deutlich brauchbarer als das nackte gpt-5.5. Es taugt einigermaßen.

Allerdings: Weil es sich um chinesische LLMs handelt, ist es doch etwas beklemmend, geschäftlichen Code hineinzufüttern. Das Ganze ist ausdrücklich nur für Hobbyprojekte und die private Entwicklung gedacht.

2. Was ist OpenRouter Fusion?

OpenRouter ist ein API-Gateway, über das sich mehrere LLM-Anbieter einheitlich ansprechen lassen. Claude, GPT, Gemini, DeepSeek — alles läuft über dieselbe Schnittstelle.

Dieses OpenRouter besitzt eine Funktion namens „Fusion”.

Vereinfacht gesagt handelt es sich um einen Mechanismus, bei dem ein Prompt an mehrere Modelle geschickt wird, deren Antworten analysiert werden und ein einzelnes Modell daraus die endgültige Ausgabe zusammenfasst. Man kann es als „Ratsversammlung der Modelle” bezeichnen.

Konkret läuft es wie folgt ab:

1. Der Nutzer gibt einen Prompt ein
2. Die in analysis_models angegebenen Modelle beantworten gleichzeitig denselben Prompt
3. Das in model angegebene Modell vergleicht und analysiert diese Antworten und strukturiert Übereinstimmungen, Widersprüche, Lücken und blinde Flecken (= die Rolle des Judge)
4. Anschließend schreibt dasselbe Modell basierend auf dieser Analyse die endgültige Antwort

Wichtig ist: Den einzelnen Analysemodellen können keine unterschiedlichen Rollen oder Prompts zugewiesen werden. Alle Modelle erhalten denselben Prompt, antworten unabhängig voneinander, und der Judge bewertet die Unterschiede — ein simpler Mechanismus.

Der CLI-Coding-Agent opencode unterstützt dieses Fusion nativ als Plugin. Es genügt, die Konfiguration in opencode.json einzutragen, und man erhält einen Agenten, bei dem mehrere Modelle zusammenarbeiten, um Code zu generieren und zu reviewen.

3. Die tatsächliche Konfiguration

Im Folgenden der zentrale Teil meiner aktuell verwendeten opencode.json.

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

Das Setup besteht aus fünf Analysemodellen und einem Ausführungsmodell.

Analysemodelle (alle sehen denselben Prompt und antworten gleichzeitig)

Ausführungsmodell (schreibt die endgültige Antwort auf Basis der Analyseergebnisse)

• deepseek/deepseek-v4-pro: Übernimmt auf Basis der Antworten der Analysemodelle die eigentliche Codegenerierung und die Dateibearbeitung.

Warum chinesische LLMs?

Ganz einfach, weil das Preis-Leistungs-Verhältnis überwältigend ist.

Stand 2026 liegen die API-Preise chinesischer LLMs bei 1/5 bis 1/20 von Anthropic oder OpenAI, bei vergleichbarer oder besserer Leistung. Insbesondere die Coding-Leistung von DeepSeek V4 Pro wirkt in der Praxis nicht selten ebenbürtig mit oder sogar überlegen gegenüber Claude Sonnet und GPT-5.5.

4. Wie es funktioniert ── Warum Fusion allein nicht reicht

Der Ablauf mit Fusion allein sieht so aus:

1. Der Nutzer gibt einen Prompt ein
2. Die fünf Analysemodelle generieren jeweils unabhängig voneinander eine Antwort
3. Das Ausführungsmodell (DeepSeek V4 Pro) vergleicht und analysiert diese Antworten und erstellt eine strukturierte Analyse mit Übereinstimmungen, Widersprüchen und Lücken
4. Auf Basis dieser Analyse schreibt dasselbe Ausführungsmodell (DeepSeek V4 Pro) schließlich den finalen Code

Das ähnelt der menschlichen Teamarbeit in der Entwicklung: Fünf Ingenieure betrachten dieselbe Spezifikation und geben jeweils ihre Review-Kommentare ab, und eine Person (DeepSeek V4 Pro) analysiert und ordnet diese, bevor sie implementiert.

Zur Begrenzung des Kontextfensters: Das Kontextfenster von Fusion beträgt 128K Tokens. Das wirkt auf den ersten Blick knapp bemessen, und tatsächlich füllt es sich überraschend schnell, da neben dem Gesprächsverlauf auch alle Antworten der fünf Modelle hineinpassen müssen. Man muss deswegen aber nicht in Panik geraten. Selbst wenn die 128K überschritten werden und der Zusammenführungsschritt von Fusion scheitert, haben die einzelnen Analysemodelle die Verarbeitung des Prompts bereits individuell abgeschlossen — jeweils mit ihrem eigenen, deutlich größeren Kontextfenster (DeepSeek V4 Pro etwa eine Million Tokens, Kimi K2.7 rund 260.000 Tokens). Auch opencode selbst bewahrt den Gesprächsverlauf der gesamten Sitzung, sodass das „Gedächtnis” der Modelle nicht verloren geht. In der Praxis stellt das nach meiner Erfahrung kein größeres Hindernis dar.

Allein damit kommt man aber an Fable überhaupt nicht heran. Fable erzielte schließlich als einzelnes Modell eine Präzision, die eine Ratsversammlung mehrerer Modelle mühelos übertraf. Das ist Anthropics eigentliche Stärke.

Deshalb wird der Fusion-Ausgabe eine weitere Review-Schicht hinzugefügt. Dafür gibt es zwei Optionen.

Option A: Code-Review durch gpt-5.5-pro

1. Code mit dem Fusion-Aufbau generieren
2. Den generierten Code an gpt-5.5-pro geben mit der Anweisung „reviewe das und schlage Korrekturen vor”
3. Diese Korrekturvorschläge vom ursprünglichen Ausführungsmodell übernehmen lassen

gpt-5.5-pro ist bei eigenständiger Codegenerierung eher schwach, aber überraschend gut im Review bestehenden Codes.

Option B: PR-Review durch GitHub Codex

1. Code mit dem Fusion-Aufbau generieren
2. Als PR einreichen und durch die GitHub Codex-PR-Review laufen lassen
3. Die von Codex genannten möglichen Bugs oder Design-Bedenken einarbeiten

Codex reviewt unter Berücksichtigung des GitHub-Kontexts (Issues, frühere PRs, Projektstruktur) und liefert dadurch eine andere Perspektive als ein generisches LLM-Review.

Einer der beiden Wege genügt. Fusion (Ratsversammlung von fünf Modellen) → Review (gpt-5.5-pro oder Codex) — ein zweistufiger Aufbau. Der Grundgedanke lautet: Weil man an Fable in einem einzigen Durchgang bei Weitem nicht herankommt, gleicht man das über den Prozess aus.

Falsche Bibliotheksversionen oder die Verwendung nicht existierender APIs, die beim nackten gpt-5.5 häufig vorkommen, haben mit diesem Aufbau deutlich abgenommen.

5. Geschwindigkeit und Praxistauglichkeit

Die Geschwindigkeit selbst unterscheidet sich kaum von einem einzelnen Modell. Da fünf Modelle parallel laufen, bleibt die reine Antwortzeit in einem akzeptablen Rahmen.

Das Problem ist die Präzision. Wo Fable auf Anhieb durchkäme, entsteht bei diesem Aufbau mehrfaches Nacharbeiten. Im Ergebnis ist die Gesamtentwicklungszeit deutlich langsamer als mit Fable. Je mehr Fehler, desto langsamer.

Dennoch ist es deutlich brauchbarer als das nackte gpt-5.5. Mit Fusion＋Review generierter Code liegt schon beim ersten Versuch recht nah an der richtigen Lösung — klar schneller, als mit gpt-5.5 allein in die Endlosschleife aus Generieren→Korrigieren→Korrigieren→Korrigieren zu geraten.

Mein Gesamteindruck: „Die Geschwindigkeit ist nicht schlecht. Bei der Präzision liegt es weit hinter Fable, ist aber mehrere Stufen besser als das nackte gpt-5.5.” Ein solides Mittelmaß.

6. Bonus: Die Review-Schicht und weitere opencode-Einstellungen

Review-Schicht: gpt-5.5-pro oder Codex-PR-Review

Der Fusion-Aufbau allein wirkt nicht ganz vertrauenswürdig, deshalb nutze ich eine der beiden Optionen als Review-Schicht.

gpt-5.5-pro: Über die Task-Funktion von opencode als Subagent einsetzen und die Anweisung geben, den generierten Code zu „reviewen und Korrekturvorschläge vorzuschlagen”. Lässt man es von Grund auf Code schreiben, ist das Ergebnis eher mittelmäßig, aber im Auffinden von Schwachstellen in fremdem Code ist es seltsam gut.

GitHub Codex: Beim Einreichen eines PR die Codex-PR-Review laufen lassen. Das Review berücksichtigt den Kontext des gesamten Projekts, was einen anderen Geschmack hat als ein generisches LLM-Review.

Welches ich verwende, hängt von der Tagesform ab. Beide gleichzeitig einzusetzen wäre eindeutig übertrieben und zu langsam.

Weitere Einstellungen

In opencode.json habe ich neben Fusion noch einige praktische Einstellungen hinterlegt.

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

Hier gibt es zwei zentrale Punkte.

1. Blockieren von löschenden Befehlen

Remove-Item, del, rm, rmdir, rd, erase und git clean werden explizit verweigert. Einem KI-Agenten das Löschen von Dateien zu überlassen, ist mir schlicht unheimlich. Wenn wirklich gelöscht werden muss, erledige ich das selbst.

2. primary_tools: ["task"]

Damit wird die parallele Exploration über Subagenten (task) priorisiert. Beim gleichzeitigen Lesen oder Durchsuchen mehrerer Dateien in einer großen Codebasis ist der Weg über task deutlich schneller.

7. Fazit

Das Ende von Fable schmerzt. Wirklich sehr. Etwas Gleichwertiges gibt es bislang nicht.

Aber man kann nicht einfach die Hände in den Schoß legen, also behelfe ich mir derzeit mit einem Aufbau, der mit OpenRouter Fusion＋chinesischen LLMs generiert und mit gpt-5.5-pro oder einer Codex-PR-Review abschließt.

Die Kernpunkte dieses Aufbaus:

• Codegenerierung durch die „Ratsversammlung” von fünf Modellen über OpenRouter Fusion
• Analysemodelle: Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
• Ausführungsmodell: DeepSeek V4 Pro
• Abschließende Review-Schicht: gpt-5.5-pro oder Codex-PR-Review (nur eines von beiden)
• Geschwindigkeit vergleichbar mit einem einzelnen Modell. Durch die geringere Präzision im Vergleich zu Fable entsteht jedoch Nacharbeit, die es verlangsamt
• Deutlich brauchbarer als das nackte gpt-5.5. Reicht nicht an Fable heran, ist aber praxistauglich
• Wegen der chinesischen LLMs schwer für geschäftlichen Code einsetzbar. Beschränkt auf Hobby- und private Entwicklung

Wer bei KI-Coding-Agenten unter dem „Fable-Verlust” leidet oder findet, dass das nackte gpt-5.5 zu schwach ist, für den lohnt sich dieser Aufbau als Übergangslösung.

Mit einem OpenRouter-Konto lässt sich das ab sofort einsetzen.

Weiterführende Links

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• opencode: Config
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist Fusion bei OpenRouter für eine Funktion?

Dabei wird ein einzelner Prompt gleichzeitig an mehrere Modelle geschickt, ein Modell (in der Rolle des Judge) vergleicht und analysiert deren Antworten, um Übereinstimmungen, Widersprüche und Lücken strukturiert herauszuarbeiten, und dasselbe Modell schreibt anschließend auf Basis dieser Analyse die endgültige Antwort. Man kann es sich als eine Art Ratsversammlung der Modelle vorstellen. Den einzelnen Analysemodellen lassen sich keine unterschiedlichen Rollen oder Prompts zuweisen — alle Modelle erhalten denselben Prompt. Der CLI-Coding-Agent opencode unterstützt Fusion nativ als Plugin; es genügt, die Konfiguration in opencode.json einzutragen.

Warum werden chinesische LLMs eingesetzt?

Schlicht wegen des überwältigenden Preis-Leistungs-Verhältnisses. Stand 2026 liegen die API-Preise chinesischer LLMs bei etwa 1/5 bis 1/20 von Anthropic oder OpenAI, bei vergleichbarer oder besserer Leistung. Insbesondere die Coding-Leistung von DeepSeek V4 Pro wirkt in der Praxis nicht selten ebenbürtig mit oder sogar überlegen gegenüber Claude Sonnet und GPT-5.5. Da es aber ein Risiko darstellt, geschäftlichen Code an chinesische LLMs zu übergeben, ist dieser Ansatz ausdrücklich nur für Hobbyprojekte und die private Entwicklung gedacht.

Warum reicht Fusion allein nicht aus?

Weil selbst die Ratsversammlung aus fünf Modellen nicht an die Präzision von Fable heranreicht. Deshalb wird der Fusion-Ausgabe eine weitere Review-Schicht hinzugefügt. Zur Auswahl stehen zwei Wege: den generierten Code von gpt-5.5-pro reviewen lassen und die Korrekturvorschläge übernehmen, oder den Code als PR einreichen und durch die PR-Review von GitHub Codex laufen lassen — einer der beiden Wege genügt. gpt-5.5-pro ist bei eigenständiger Codegenerierung eher schwach, dafür aber überraschend gut im Review bestehenden Codes, während Codex Hinweise gibt, die den Kontext des gesamten Projekts berücksichtigen.

Wie praxistauglich ist dieser Aufbau?

Da fünf Modelle parallel laufen, unterscheidet sich die Geschwindigkeit kaum von einem einzelnen Modell. Die Präzision liegt allerdings deutlich hinter Fable zurück, sodass durch entstehendes Nacharbeiten die Gesamtentwicklungszeit spürbar länger wird. Trotzdem ist es klar schneller, als mit dem nackten gpt-5.5 allein in eine Endlosschleife aus Generieren und Korrigieren zu geraten, und auch falsche Bibliotheksversionen oder die Verwendung nicht existierender APIs haben deutlich abgenommen. Mit einem OpenRouter-Konto lässt sich das sofort ausprobieren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.