Claude Opus 5 vs. Claude Fable 5: Sieben-Task-Benchmark mit realer API und Empfehlungen für Production-Routing

Claude Opus 5 vs Claude Fable 5: 7 reale API-Tests und Empfehlungen für Produktions-Routing#

Wie sollte man zwischen Claude Opus 5 und Claude Fable 5 wählen? Wenn man nur eine einzelne erfolgreiche Antwort betrachtet, können beide Modelle sehr überzeugende mathematische Herleitungen liefern. Für die Produktionserfahrung sind aber meist drei andere Fragen entscheidend: Wird die Aufgabe stabil ausgeliefert, passt die Latenz zur Interaktion, und lässt sich ein Fehler automatisch abfangen?

Wir haben am 25. Juli 2026 beide Modelle über dieselbe OpenAI-compatible API mit identischen Prompts und Parametern in 7 Aufgabentypen getestet. Das Ergebnis passt nicht in die einfache Erzählung „das größere Modell ist immer besser“:

• claude-fable-5 war bei Aufgaben, die beide Modelle erfolgreich erledigten, schneller und knapper;
• claude-opus-5 deckte nach Retry schließlich alle 7 Aufgabentypen ab;
• Fable 5 löste bei einem normalen Code-Review-Prompt und einem Incident-JSON-Prompt wiederholt content_filter aus;
• Opus 5 gab bei der Physikaufgabe in den ersten beiden Versuchen trotz HTTP 200 nur eine unpassende Begrüßung zurück und erledigte die Aufgabe erst im 3. Versuch korrekt.

Für die Produktionsauswahl heißt das: Es sollte nicht nur eine einzige Modell-ID geben. Robuster ist es, zuerst je nach Aufgabentyp ein Primärmodell zu wählen und Ausnahmen anschließend mit Inhaltsvalidierung, Retries und Modell-Fallbacks abzufangen.

Opus 5 und Fable 5 über dieselbe API testen

Kurzfazit#

Wenn deine Eingabetypen schwer vorhersehbar sind oder du vermeiden musst, dass normale Business-Prompts gefiltert werden, solltest du Opus 5 priorisieren. Wenn die Aufgabenstruktur stabil ist, bereits Regressionstests durchgeführt wurden und Interaktionsgeschwindigkeit sowie kurze Ausgaben wichtiger sind, eignet sich Fable 5 besser als erster Hop.

Wie wir getestet haben#

Vor dem Test haben wir zunächst die Modelllisten-API aufgerufen, um sicherzustellen, dass beide exakten Modell-IDs sichtbar sind:

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
claude-fable-5

Alle offiziellen Requests liefen über denselben Endpoint:

POST https://cn.crazyrouter.com/v1/chat/completions

Die gemeinsamen Bedingungen waren:

identischer system prompt
identischer user prompt
temperature = 1
für jede Aufgabe identisches max_tokens
stream = true
keine Tools und kein Webzugriff

Der einheitliche system prompt verlangte lediglich eine korrekte Antwort und die Einhaltung des gewünschten Ausgabeformats. Es wurden keine Rollenformulierungen eingefügt, die eines der Modelle bevorzugen könnten:

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

Erfasst haben wir nicht nur den finalen Text, sondern auch:

• HTTP-Status und finish_reason;
• response ID und returned model;
• Zeit bis zum ersten sichtbaren Token und Gesamtlatenz;
• completion tokens und reasoning tokens;
• ob die sichtbare Antwort die Aufgabenvalidierung erfüllt;
• ob sich abnormale Requests mit denselben Parametern per Retry erholen.

Dies ist ein End-to-End-Test über das Crazyrouter-Gateway, kein Experiment mit einem fest vorgegebenen einzelnen Upstream-Kanal. Die Ergebnisse spiegeln daher zugleich Modellverhalten, Upstream-Filterung, Gateway-Routing und den damaligen Kanalzustand wider. Sie beantworten gut die Frage „Was erlebt ein Nutzer über diese API tatsächlich?“, eignen sich aber nicht als rein offline gemessene Fähigkeitsrangliste der Claude-Familie.

Wenn du verstehen möchtest, warum Modelltests finish_reason und Output-Budget erfassen müssen, lies auch den max_tokens-Retest von Claude Fable 5 vs GPT-5.5.

Gesamttabelle der 7 Ergebnisse#

Auslieferungsrate im Haupttest:

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

Nach Retry:

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

„Auslieferung“ bedeutet hier nicht, dass der Request erfolgreich war, sondern dass die Anwendung eine sichtbare Antwort erhält, die die Aufgabenanforderungen erfüllt. Auch HTTP 200, Modellname und token usage vorhanden sind, zählt eine Aufgabe als fehlgeschlagen, wenn der Body leer ist, gefiltert wurde oder nur eine Begrüßung zurückkommt.

Mathematik, Constraints und Statistik: Beide Modelle sind zuverlässig#

Die Mathematikaufgabe verwendete eine dreistufige Markow-Kette. Gefragt war die Wartezeit bis zum erstmaligen Erreichen von Zustand 3 aus Zustand 1:

E1[τ]
E1[τ²]
Var1(τ)

Beide Modelle lieferten:

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

Beide schrieben außerdem die transiente Matrix Q sowie die Gleichungen für erstes und zweites Moment aus. In dieser Aufgabe gab es keinen Fall, in dem die Endzahlen korrekt, die Herleitung aber inkonsistent war.

Bei der Constraint-Suche mussten die fünf Vorträge A, B, C, D und E auf fünf Zeitslots verteilt werden, unter Bedingungen wie unmittelbarer Nachbarschaft, Reihenfolge, Abstand und Nicht-Nachbarschaft. Beide Modelle fanden die eindeutige Reihenfolge:

A, C, E, B, D

Die Statistikaufgabe enthielt absichtlich eine falsche Schlussfolgerung: „Mittelwert 10, Varianz 4, also P(X≥14)=0.5.“ Beide Modelle erklärten, dass die ersten beiden Momente nicht ausreichen, um die Tail-Wahrscheinlichkeit eindeutig zu bestimmen, und verwendeten die einseitige Chebyshev-/Cantelli-Ungleichung:

P(X >= 14) <= 0.2

Diese drei Aufgabentypen zeigen, dass Fable 5 seinen Geschwindigkeitsvorteil nicht dadurch erkauft, dass es grundlegende Reasoning-Korrektheit opfert. Bei klaren, kurzen und gut validierbaren Mathematik- und Logikaufgaben kann es gut als leichterer erster Hop eingesetzt werden.

Auch frühere Tests wie Claude Fable 5 vs Claude Sonnet 5 API-Test und GLM-5.2 vs Fable 5 Output-Budget-Test zeigen: Ob ein Modell produktionsreif ist, lässt sich nur beurteilen, wenn Korrektheit, Output-Budget und Auslieferungsform gemeinsam betrachtet werden.

Physikaufgabe: Fable erledigt sie im ersten Durchlauf, Opus erholt sich im dritten#

Die Physikaufgabe betraf einen Zweifreiheitsgrad-Oszillator mit Erdungsdämpfung und Kopplungsdämpfung. Zu berechnen waren die beiden ungedämpften Eigenfrequenzen sowie die komplexe Frequenzantwort der beiden Massen bei ω=8 rad/s.

Die Referenzwerte waren:

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°

Fable 5 gab im ersten Durchlauf alle korrekten Ergebnisse zurück. Bei Opus 5 trat in den ersten beiden Aufrufen dagegen eine Anomalie auf, die für Produktionsteams wichtiger ist als ein bloßer Rechenfehler: Die API antwortete mit HTTP 200 und finish_reason=stop, aber der Body enthielt nur:

Hi! How can I help you today?

Die prompt tokens dieser beiden Antworten lagen jeweils bei nur 10 und passten damit offensichtlich nicht zur tatsächlichen Eingabe. Beim 3. Durchlauf desselben Requests antwortete Opus 5 nach 34.901 Sekunden vollständig; alle sechs Zahlen bestanden die Prüfung.

Diese Anomalie sollte daher nicht als „Physikaufgabe falsch berechnet“ klassifiziert werden, sondern als „Request-Kontext wurde nicht korrekt verarbeitet“. Die einfachste Schutzmaßnahme ist nicht manuelle Logprüfung, sondern Validierung auf Aufgabenebene: Die Antwort muss ω1, ω2, X1 und X2 enthalten; fehlt eines der Felder, wird automatisch ein Retry ausgelöst.

Code und striktes JSON: Fables Filterung ist der größte Unterschied dieser Runde#

In der Codeaufgabe sollte das Modell einen Python-DFS-Zyklendetektor reviewen. Der Bug war gewöhnlich: Nach Abschluss des DFS wurde der Knoten nicht aus der Menge visiting entfernt. Dadurch wurden bereits abgeschlossene Knoten weiterhin fälschlich als Teil des Rekursionsstapels betrachtet, was in einem DAG zu falsch positiven Zyklen führt.

Opus 5 benannte den minimalen Fix korrekt:

visiting.discard(node)
visited.add(node)
return False

Fable 5 gab keine Codeanalyse zurück, sondern finish_reason=content_filter mit leerem Body. Um Verzerrungen durch den system prompt oder zufälliges Routing auszuschließen, führten wir drei Runden durch: den ursprünglichen Test, einen Retest mit bereinigtem system prompt und einen unabhängigen Einzelaufgaben-Retry. Das Ergebnis war jedes Mal content_filter.

Die strikte JSON-Aufgabe enthielt ebenfalls keine gefährlichen Inhalte. Die Eingabe umfasste lediglich die Gesamtzahl der Requests innerhalb von 15 Minuten, die Fehlerzahl, Kanalzuordnung, Anzahl der durch Retry wiederhergestellten Fälle und ergriffene Maßnahmen. Gefordert war ein JSON-Objekt. Das von Opus 5 zurückgegebene JSON ließ sich direkt parsen; Fable 5 wurde erneut 3-mal in Folge gefiltert.

Diese beiden Fehlerklassen zeigen: Sicherheitsfilterung ist selbst ein Teil der Produktionsfähigkeit einer Modell-API. Wenn ein Modell bei normalen Code-Reviews oder Incident-Retrospektiven stabil falsch filtert, kann es selbst dann nicht den gesamten Business-Traffic übernehmen, wenn es in Mathematikaufgaben schneller ist.

Die response ID der beiden unabhängigen Retries:

Code-Review: gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
Incident JSON: gen-1784915390-buOWZQSnqjgHeJ6nUogF

Latenz und Ausgabelänge#

Damit fehlgeschlagene Requests mit kurzer Laufzeit nicht als „Geschwindigkeitsvorteil“ zählen, vergleichen wir hier nur die vier Aufgaben, die beide Modelle erfolgreich erledigt haben: Mathematik, Constraint-Suche, statistische Fehlerkorrektur und Experimentdesign.

In dieser kleinen Stichprobe lag Fable 5 bei der P50-Gesamtlatenz etwa 24% niedriger, beim ersten sichtbaren Token etwa 17% niedriger und bei der Antwortlänge etwa 43% kürzer. Für Chat, Batch-Zusammenfassungen und hochfrequente strukturierte Aufgaben wirken sich solche Unterschiede direkt auf Wartezeit und nachgelagerte Verarbeitung aus.

Die Medianwerte aus 4 Aufgaben sollten aber nicht als SLA formuliert werden. Upstream-Last, Caching, Routing und Rate Limits verändern die Latenz. Vor einem Produktionsstart solltest du mit deinen eigenen Business-Prompts 20–50 Wiederholungen durchführen und anschließend P50, P95, P99 sowie die realen Kosten pro bestandenem Ergebnis auswerten.

Die Haupttest-Antworten von Fable 5 enthielten ein cost-Feld; die 7 Durchläufe summierten sich auf etwa $0.24596. Die usage von Opus 5 lieferte kein cost-Feld derselben Methodik. Deshalb trifft dieser Artikel kein Urteil darüber, welches Modell in US-Dollar günstiger ist. Ein fehlendes Feld bedeutet nicht kostenlos und sollte nicht mit ungeprüften Preisen ergänzt werden.

Empfohlene Routing-Strategie für die Produktion#

Ein Einzelmodellaufruf ist am einfachsten zu implementieren, gibt aber alle zufälligen Modellverhaltensweisen direkt an Endnutzer weiter. Für die beiden Modelle dieser Runde ist folgende Aufgabenteilung sinnvoller:

Fable 5 als erster Hop#

Geeignet für:

• Mathematik, Constraint-Reasoning und kurze Zusammenfassungen, die Regressionstests bestanden haben;
• Interaktionen, die empfindlich auf ersten Token und Gesamtlatenz reagieren;
• Aufgaben, bei denen kurze Antworten und weniger Nachbearbeitung wichtig sind.

Voraussetzung ist, dass die Aufgabenfamilie bereits auf Filterung getestet wurde und der Client content_filter, leere Bodys und fehlende Felder prüft.

Opus 5 als Fallback mit breiterer Abdeckung#

Geeignet für:

• unvorhersehbare Eingabetypen;
• Code-Review, striktes JSON, komplexe Physik und andere Szenarien, die breitere Aufgabenabdeckung brauchen;
• Fälle, in denen nach einer Filterung durch Fable 5 die Nutzeranfrage automatisch wiederhergestellt werden muss.

Auch Opus 5 darf nicht ungeprüft durchgelassen werden. Die Begrüßungsanomalie in dieser Runde zeigt: HTTP 200 und stop bedeuten nicht automatisch eine brauchbare Business-Antwort.

OpenAI-compatible Python-Beispiel#

Das folgende Beispiel ruft zuerst Fable 5 auf. Bei Filterung, leerem Body oder fehlgeschlagener Validierung fällt es auf Opus 5 zurück. Wenn Opus weiterhin nur eine Begrüßung zurückgibt, wird noch einmal retryt.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)


def valid_answer(text: str, required_terms: tuple[str, ...]) -> bool:
    normalized = (text or "").strip()
    if not normalized:
        return False
    if normalized.lower().startswith("hi! how can i help"):
        return False
    return all(term in normalized for term in required_terms)


def call_model(model: str, prompt: str) -> tuple[str, str | None]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=1,
        max_tokens=3000,
    )
    choice = response.choices[0]
    return choice.message.content or "", choice.finish_reason


def routed_completion(prompt: str, required_terms: tuple[str, ...] = ()) -> str:
    for model, attempts in (("claude-fable-5", 1), ("claude-opus-5", 2)):
        for _ in range(attempts):
            text, finish_reason = call_model(model, prompt)
            if finish_reason == "content_filter":
                break
            if valid_answer(text, required_terms):
                return text
    raise RuntimeError("No model produced a valid business answer")


answer = routed_completion(
    "Return a JSON incident summary with keys total, failed, recovered.",
    required_terms=('"total"', '"failed"', '"recovered"'),
)
print(answer)

Eine Produktionsimplementierung sollte außerdem model, response ID, finish_reason, Gesamtlatenz und den Grund für eine fehlgeschlagene Validierung protokollieren. Nur so kannst du Rechenfehler, Output-Truncation, Inhaltsfilterung und verlorenen Request-Kontext unterscheiden, statt alles unter einem unscharfen „Modellfehler“ zu verbuchen.

Wenn du Multi-Modell-Infrastruktur planst, sind auch die Unterschiede zwischen AI API Gateway, Aggregator und direkter Modell-API sowie der Sieben-Dimensionen-Test von Kimi K3 vs Opus 4.8 relevant.

Abschließende Empfehlung#

Die wertvollste Erkenntnis dieser Runde ist nicht, wer die höhere Punktzahl erreicht hat, sondern dass beide Modelle unterschiedlich scheitern:

• Fable 5 ist bei gemeinsamen Aufgaben schneller und kürzer; das Risiko liegt darin, dass manche normalen Business-Prompts stabil Filterung auslösen.
• Opus 5 deckt nach Retry alle Aufgaben ab; das Risiko liegt in seltenen Begrüßungsantworten, die nichts der tatsächlichen Eingabe zu tun haben.

Daher empfiehlt es sich, Fable 5 vor verifizierte Hochfrequenzaufgaben zu setzen, Opus 5 als Fallback mit breiterer Abdeckung zu verwenden und auf beiden Pfaden Inhaltsvalidierung durchzuführen. So wird aus einem Modellvergleich echte Zuverlässigkeit, statt nur eine weitere Rangliste zu produzieren.

API Key erstellen und dieses Dual-Modell-Routing reproduzieren

FAQ#

Ist Claude Opus 5 immer stärker als Claude Fable 5?#

Aus dieser kleinen Stichprobe lässt sich nicht ableiten, dass Opus 5 „bei allen Aufgaben stärker“ ist. Beide Modelle bestanden Mathematik, Constraints, statistische Fehlerkorrektur und Experimentdesign; Fable 5 war schneller und kürzer, Opus 5 hatte die vollständigere Aufgabenabdeckung. Die Auswahl sollte auf der Erfolgsrate konkreter Aufgaben basieren, nicht auf dem Modellnamen.

Eignet sich Claude Fable 5 für Produktionsumgebungen?#

Ja, für Aufgaben, die Regressionstests bestanden haben. In dieser Runde war Fable 5 bei mehreren Reasoning-Aufgaben korrekt und schneller, löste aber bei Code-Review und Incident JSON wiederholt Filterung aus. Vor dem Rollout solltest du mit echten Prompts die Filterrate messen und Opus 5 oder andere Modelle als Fallback konfigurieren.

Warum zählt HTTP 200 trotzdem als Fehler?#

HTTP 200 bedeutet nur, dass die Schnittstelle eine Antwort abgeschlossen hat. Ein leerer Body, finish_reason=content_filter, abgeschnittener Output oder eine bloße Begrüßung erfüllen die Business-Aufgabe nicht. Produktionsmetriken sollten die „Validierungs-Bestehensrate“ erfassen, nicht nur die HTTP-Erfolgsrate.

Warum lautet das returned model anthropic/claude-fable-5?#

Der Request verwendet claude-fable-5, während das returned model in der Antwort stabil als anthropic/claude-fable-5 mit Provider-Präfix erscheint. Das kann als normalisierter Alias betrachtet werden; eine reine Präfixänderung reicht nicht aus, um einen Modelltausch zu belegen.

Kann man die US-Dollar-Kosten beider Modelle direkt vergleichen?#

In dieser Runde nicht. Die Antworten von Fable 5 enthielten ein cost-Feld, Opus 5 lieferte kein Feld mit derselben Methodik. Ein sauberer Kostenvergleich sollte aus einheitlichen Abrechnungslogs stammen und „Kosten pro validiert bestandenem Ergebnis“ als Metrik verwenden.

Wie oft sollte man wiederholen, bevor man live geht?#

Empfohlen sind mindestens 20–50 Wiederholungen pro zentraler Aufgabenfamilie, einschließlich normaler Eingaben, Randfälle, langer Eingaben und potenziell filteranfälliger Eingaben. Mindestens erfasst werden sollten Aufgaben-Erfolgsrate, Filterrate, Rate leerer Bodys, Truncation-Rate, P50/P95/P99-Latenz und Kosten.

Wie starte ich mit dem Testen?#

Verwende https://cn.crazyrouter.com/v1 als OpenAI-compatible base URL und rufe claude-opus-5 sowie claude-fable-5 separat auf. Fixiere Prompts und Parameter, speichere die Rohantworten und entscheide anschließend mit lokalen Assertions oder Strukturvalidierung, ob die Aufgabe wirklich abgeschlossen wurde.

Starte deinen Claudeual-Modell-Test