# Claude Fable 5.2 vs Opus 5.5: Coding und Agent-Aufgaben > Fable 5.2 und Opus 5.5 auf denselben Coding- und Tool-Aufgaben: Antwortqualität, Laufzeit, Tokenverbrauch und Kostenschätzung nach offiziellen Preisen. - Canonical HTML: https://omniakey.com/de/blog/fable-5-2-vs-opus-5-5 - Markdown: https://omniakey.com/de/blog/fable-5-2-vs-opus-5-5.md - Published: 2026-11-12 (updated 2026-11-12) - Author: Kiki, COO at OmniaKey - Language: de - Category: Comparison - Reading time: 9 min - All posts: https://omniakey.com/blog/llms.txt --- Bei diesen vier kleinen Coding- und Tool-Aufgaben lohnt sich der Aufpreis für Fable 5.2 nicht: [Claude Fable 5.2](https://omniakey.com/de/claude-fable-5-2) und [Claude Opus 5.5](https://omniakey.com/de/claude-opus-5-5) haben alle 29 Codeprüfungen bestanden, und die Schätzung zu Standardtarif lag für das Set bei Opus bei $0,031 gegenüber $0,146 bei Fable. Ziehen Sie Fable für schwierigeres Reasoning oder lange Agent-Läufe in Betracht, wenn Opus mit höherem Effort nicht ausreicht. - **Claude Opus 5.5** (Erste Wahl für kleine Korrekturen): Standardwahl für kurze Coding- und Tool-Aufgaben: 29/29 Prüfungen und eine Schätzung zu Standardtarif von $0,031 für vier Aufgaben. - **Claude Fable 5.2** (Erst prüfen, wenn Opus nicht reicht): Prüfen Sie Fable für schwierigeres Reasoning oder lange Agent-Läufe, wenn Opus mit höherem Effort an Ihren eigenen Fällen scheitert. ## Fable 5.2 und Opus 5.5 im Überblick Fable 5.2 ist neuer, aber beide Modelle teilen dasselbe Kontextfenster von 1M Tokens und dieselbe Ausgabe von 128K Tokens. Der praktische Unterschied in diesem Test war der Tokenverbrauch, nicht die Korrektheit des Codes. |Punkt|Fable 5.2|Opus 5.5| |-|-|-| |Veröffentlicht|9.11.2026|22.9.2026| |Kontext / Ausgabe|1M / 128K|1M / 128K| |Standard-Effort|high|medium| |Eingabe / Ausgabe ($/1M)|$8 / $40|$4 / $20| Die Modellseiten von Anthropic zu [Fable 5.2](https://platform.claude.com/docs/en/models/fable-5-2/overview) und [Opus 5.5](https://platform.claude.com/docs/en/models/opus-5-5/overview) führen beide als aktiv, mit Text- und Bildeingabe. Fable erschien am 9. November 2026, Opus am 22. September 2026. Die Standard-Effort-Stufen unterscheiden sich, setzen Sie beim Vergleich also bei beiden `medium`. Die [Modellübersicht](https://platform.claude.com/docs/en/models/overview) von Anthropic empfiehlt Opus 5.5 für die meisten Aufgaben. Fable 5.2 ist dort für anspruchsvolles Reasoning und lang laufende Agent-Arbeit positioniert, oder für Fälle, in denen Evaluierungen von Opus 5.5 mit höherem Effort noch nicht ausreichen. Das ist die Positionierung des Anbieters; dieser Test umfasst vier kleine Aufgaben. Was sich in Fable 5.2 geändert hat, steht in [den Änderungen in Fable 5.2](https://omniakey.com/de/blog/claude-fable-5-2). Eine Einzelbesprechung gibt es im [Opus-5.5-Review](https://omniakey.com/de/blog/claude-opus-5-5-review). ## Was die vier Aufgaben kosten Die [offizielle Preisseite](https://platform.claude.com/docs/en/about-claude/pricing) von Anthropic nennt für Fable 5.2 $8 Eingabe und $40 Ausgabe pro Million Tokens, gegenüber $4 und $20 für Opus 5.5 (geprüft am 12.11.2026). Batch halbiert beide Paare; der Fast-Modus verdoppelt sie. Über die vier bewerteten Aufgaben hinweg verbrauchte Fable 3.439 Eingabe- und 2.954 Ausgabe-Tokens. Opus verbrauchte 2.421 und 1.065. Zu Standardtarif ergibt das: - Fable: (3.439 × $8 + 2.954 × $40) ÷ 1.000.000 = $0,1457 - Opus: (2.421 × $4 + 1.065 × $20) ÷ 1.000.000 = $0,0310 Das sind Schätzungen zu Standardtarif aus den beobachteten Tokens, keine Rechnungen und keine OmniaKey-Beträge. Die Antwort von Opus meldete die Geschwindigkeit fast, die von Fable standard; Anthropic listet Eingabe und Ausgabe bei fast zum doppelten Standardtarif. Hier normalisieren wir beide auf Standardtarif, die Zahlen sind also kein kontrollierter Zeit- oder Abrechnungsvergleich. Schätzungen zu Standardtarif in US-Dollar: |Aufgabe|Fable 5.2|Opus 5.5| |-|-|-| |Nutzungssummen|$0,0498|$0,0067| |Cursor-Seiten|$0,0428|$0,0102| |Ledger|$0,0180|$0,0053| |Dateipatch|$0,0351|$0,0088| |Vier Aufgaben|$0,1457|$0,0310| Im Mittel über die vier getesteten Aufgaben kostete Fable $0,0364 und Opus $0,0077; die Schätzung zu Standardtarif lag bei Fable über das Set um $0,1147 höher. Die praktische Regel sind die Kosten pro nutzbarer Aufgabe: API-Ausgaben plus Zeit für Wiederholungen und Prüfung. Wechseln Sie nach oben, wenn gescheiterte echte Fälle diese Mehrkosten rechtfertigen; diese vier kleinen Aufgaben tun das nicht. Die Gesamtlaufzeit betrug 27,8 s für Fable und 43,6 s für Opus. Die Antworten von Fable meldeten standard, die von Opus fast, und wir haben keine Geschwindigkeit gesetzt; lesen Sie das als Beobachtung, nicht als Geschwindigkeitsrangliste. ## Zwei Python-Korrekturen: 22/22 Prüfungen bei beiden Beide Korrekturen sind kurz, und beide Modelle lieferten funktionierende Funktionen. Die Fehler lohnen sich zum Wiederverwenden, weil sie den Umgang mit Revisionen und Randfälle der Paginierung prüfen, nicht Bibliothekswissen. ### Nutzungssummen: Eine neuere Fehlrevision muss einen älteren Erfolg löschen Die alte Funktion summierte jedes complete-Ereignis. Sie ignorierte revision und status, daher zählte ein Wiederholungsversuch Tokens doppelt, und eine neuere failed-Revision konnte eine ältere complete nicht aufheben. Die Kernregel im Prompt: > Keep only the highest revision for each event\_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing. Die kleinste Reproduktion ist Ereignis x in Revision 1, complete, 10 Tokens, gefolgt von x in Revision 2, failed, 10 Tokens. Die richtige Summe ist null; die alte Funktion liefert 10. Beide Modelle behielten die höchste Revision, nutzten bei gleichen Revisionen die letzte Eingabereihenfolge, übersprangen failed-Gewinner, behielten Nutzer mit null Tokens und ließen die Eingabe unverändert. **Ergebnis:** je 8/8 Prüfungen, mit gleichwertigen Funktionen. ### Cursor-Paginierung: Gleichstände dürfen weder doppeln noch überspringen Die alte Version sortierte nur nach `ts`, schnitt die erste Seite vor dem Anwenden des Cursors ab, akzeptierte gleiche Zeitstempel mit `<=`, validierte `limit` nie und gab immer einen nächsten Cursor zurück. Bei zwei Zeilen mit `ts=4` wiederholt oder überspringt das eine ID. Die Kernregeln im Prompt: > Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next\_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid. Beide behoben alles: Tupel-Sortierung, strikt kleiner, Filterung der vollen Liste vor dem Schnitt, nächster Cursor nur bei verbleibenden Zeilen und eine Validierung, die `True`, `False`, `0`, `101`, `1.5`, `'2'` und `None` ablehnt. **Ergebnis:** je 14/14 Prüfungen, einschließlich eines Ein-Zeilen-Durchlaufs über gleiche Zeitstempel. ## Das asynchrone Ledger: gleiche Zahlen, anderes JSON Beide Modelle rechneten die Abstimmung richtig: $0,93 netto reserviert, t3 ausstehend, t1 und t5 abgeschlossen und `poll_existing` für t3. Das mitgelieferte synthetische Fixture verwendet Beispielbeträge, keine OmniaKey-Preise. Die wichtigsten Zeilen: > POST key=a => 201 task=t1 quote=0.40 > > POST key=a, identical body => 200 task=t1 > > GET t1 => SUCCEEDED > > POST key=b => 201 task=t2 quote=0.40 > > GET t2 => FAILED > > POST key=c => 201 task=t3 quote=0.13 > > Client stopped polling t3 after 120 seconds; last status PROCESSING > > POST key=d => 201 task=t4 quote=0.13 > > GET t4 => CANCELED > > POST key=e => 201 task=t5 quote=0.40 > > GET t5 => SUCCEEDED Die Rechnung ist 0,40 + 0,13 + 0,40 = 0,93. t2 und t4 werden erstattet; t1 und t5 werden verbraucht; t3 behält seine Reservierung, weil der Client das Abfragen beendet hat und nicht, weil die Aufgabe fehlgeschlagen ist. Zählt man nur Aufgaben mit zuletzt beobachtetem Status SUCCEEDED, gaben beide dieselben Werte zurück. Fable gab rohes JSON zurück. Opus packte das JSON in einen JSON-Codeblock. Der Prompt sagte "Return ONLY JSON", ein striktes `json.loads` auf Opus' Antwort schlägt also fehl, bis der Block entfernt ist. Das ist ein reiner Formatfehler: Die Anfrage verlangte reinen JSON-Text, ohne JSON-Schema und ohne Modus für strukturierte Ausgabe. **Ergebnis:** Die Werte stimmen bei beiden; für Automatisierung prüfen Sie die rohe Antwort mit einem strikten Parser oder nutzen strukturierte Ausgabe. Das war ein beobachteter Fehler, kein allgemeines Muster. ## Die Dateiaufgabe mit zwei Runden: ein Lesevorgang, ein Patch Das alte `remaining_quota` im Fixture zog die units jedes Ereignisses ab. Es ignorierte den letzten Zustand pro ID und die Begrenzung `max(0, ...)`, daher verbrauchten failed- oder canceled-Aufgaben weiter Kontingent, und wiederholte Ereignisse wurden doppelt belastet. Die Aufgabe: > Use read\_file once to inspect quota.py, then return one Python code block containing only a corrected remaining\_quota(limit, events) function. Beide Modelle riefen `read_file` genau einmal für `quota.py` auf. Nach der Rückgabe des Fixtures lieferten beide dieselbe Patch-Logik: letztes Ereignis pro ID behalten, units nur für reserved oder succeeded summieren und `max(0, limit - consumed)` zurückgeben. **Ergebnis:** je 7/7 Prüfungen, einschließlich failed-dann-reserved und Überschreitung des Limits. Das sind zwei Runden und ein Fixture. Es zeigt, dass die Modelle die richtige Datei anfordern und sie patchen; einen langen Agent-Lauf deckt es nicht ab. ## So haben wir getestet Am 12.11.2026 schickten wir vier Aufgaben an `claude-fable-5-2` und `claude-opus-5-5`, über den Messages-Endpunkt von OmniaKey. Jedes Modell/Aufgabe-Paar nutzte eine neue Unterhaltung und einen kalten Cache, mit Effort `medium`, `max_tokens` 4096 pro Anfrage, ohne System-Prompt, ohne temperature oder top\_p und mit einem Versuch. Welches Modell zuerst lief, wechselten wir je Aufgabe. Die Agent-Aufgabe nutzte ein striktes `read_file`-Tool mit `tool_choice: auto`; alles andere war eine einzelne Nutzernachricht. Der Prüfer filterte jede Python-Antwort per AST und führte sie dann in einem isolierten Prozess mit 3 Sekunden Timeout gegen 8 Nutzungs-, 14 Cursor- und 7 Agent-Fälle aus: 29 Codefälle pro Modell. Jede Anfrage lief einmal. Der erste Ledger-Prompt ließ offen, ob FAILED/CANCELED-Aufgaben in `completed_task_ids` gehören. Diese mehrdeutige Runde ersetzten wir durch einen klargestellten Wiederholungslauf pro Modell, der nur Aufgaben mit zuletzt beobachtetem SUCCEEDED zählt; die ursprünglichen Ausgaben bleiben aus den Summen der vier bewerteten Aufgaben heraus. Alle 12 Anfragen gaben HTTP 200 mit der angeforderten Modell-ID zurück und endeten mit `end_turn` oder `tool_use` und dann `end_turn`, ohne Abschneiden. Beide meldeten service tier standard. Fable meldete Geschwindigkeit standard und getrennte Thinking-Token-Zahlen; Opus meldete Geschwindigkeit fast und ließ das Thinking-Token-Feld weg. Wir ließen die Geschwindigkeit ungesetzt, und Ausgabe-Tokens enthalten bereits abgerechnetes Thinking, das fehlende Feld bei Opus sagt also nichts über null Thinking. Dieselbe Effort-Zeichenkette ist eine Einstellung, kein angeglichenes Rechenbudget. Dieser Lauf hält den Effort bei `medium`; für Ihre eigene Arbeit gehen Sie die Effort-Stufen durch, die Ihre Aufgabe braucht. Das ist ein Test mit kleinem Fixture, kein Benchmark für ein ganzes Repository oder einen lange laufenden Agent. Er sagt keine Trefferquoten für andere Aufgaben voraus. OmniaKey verkauft den Zugang zu beiden Modellen; die Preise oben sind Anthropics offizielle Listenpreise. ## Wann Fable in Frage kommt Für kurze, gut spezifizierte Arbeit beginnen Sie mit Opus 5.5. Es glich Fable bei allen 29 Codeprüfungen, und die Schätzung zu Standardtarif lag bei Fable 4,7-mal so hoch wie bei Opus. Fable 5.2 ist der nächste Kandidat für anspruchsvolles Reasoning oder lange Tool-Schleifen, nachdem Opus mit höherem Effort an Ihren echten Fällen scheitert. Das ist die Positionierung von Anthropic; dieser Lauf umfasst nur die vier kleinen Aufgaben. Testen Sie 10–20 echte Fehlschläge, bevor Sie wechseln. Der [Startbeitrag zu Fable 5.2](https://www.anthropic.com/claude-fable-and-mythos-5-2) von Anthropic ergänzt einen vom Anbieter berichteten Wert: Fable 5.2 erreichte in High 45,3 % auf FrontierCode 2.0 gegenüber 45,5 % für Opus 5.5 in Max, bei etwa der Hälfte der Kosten pro Aufgabe. Der Beitrag sagt außerdem, Fable 5.2 habe in Xhigh 49,1 % erreicht, den höchsten Wert aller getesteten veröffentlichten Modelle. Das paart Fable High mit Opus Max, einen anderen Vergleich als unseren Test mit gleichem medium. Vergleichen Sie in einem echten Projekt die API-Ausgaben mit der Zeit für Wiederholungen und Prüfung pro nutzbarer Aufgabe. Bei kleiner, schon bestehender Arbeit ist Opus die günstigere Standardwahl. Um eines der beiden Modelle in Claude Code zu nutzen, finden Sie in der [Claude-Code-Einrichtungsanleitung](https://omniakey.com/de/blog/claude-code-setup) die Base-URL und die Key-Einstellungen. Modellseiten: [Claude Fable 5.2](https://omniakey.com/de/claude-fable-5-2) und [Claude Opus 5.5](https://omniakey.com/de/claude-opus-5-5). ## Häufige Fragen ### Lohnt sich Fable 5.2 zum höheren Preis gegenüber Opus 5.5? Ziehen Sie Fable in Betracht, nachdem Opus mit höherem Effort an Ihren eigenen Fällen scheitert, und prüfen Sie, ob Fable sie verbessert; dieser Lauf gibt kein Urteil zu schwierigen Aufgaben. Bei unseren vier kleinen Aufgaben bestanden beide 29/29 Codeprüfungen; die Schätzung zu Standardtarif lag bei Fable bei $0,1457 gegenüber $0,0310 bei Opus. ### Haben Fable 5.2 und Opus 5.5 dieselben Codetests bestanden? Ja. Beide bestanden 8/8 Nutzungsfälle, 14/14 Cursorfälle und 7/7 Dateipatch-Fälle. Auch die Ledger-Antwort war bei beiden richtig, mit einem Formatunterschied: Opus fügte einen JSON-Codeblock hinzu. ### Was ist zum Programmieren günstiger, Fable 5.2 oder Opus 5.5? Zu Anthropics offiziellen Listenpreisen Opus 5.5: $4 Eingabe und $20 Ausgabe pro Million Tokens gegenüber $8 und $40. Mit unseren Tokens liegt die Schätzung zu Standardtarif bei Fable 4,7-mal so hoch wie bei Opus: $0,1457 gegenüber $0,0310 über vier Aufgaben. ### Ist Fable 5.2 schneller als Opus 5.5? Unser Lauf lässt das offen. Die beobachteten Summen waren 27,8 s für Fable und 43,6 s für Opus, aber die Antworten von Fable meldeten standard und die von Opus fast, und wir ließen die Geschwindigkeit ungesetzt. Vergleichen Sie sie erneut mit derselben Geschwindigkeitseinstellung. ### Kann ich beide Modelle in Claude Code über OmniaKey nutzen? Ja. Wir haben in diesem Lauf beide Modell-IDs über OmniaKey aufgerufen, und die [Claude-Code-Einrichtungsanleitung](https://omniakey.com/de/blog/claude-code-setup) zeigt die Base-URL und den Key. Prüfen Sie den Modellnamen nach dem Verbinden in Ihrem Client. ## Geprüfte Quellen - Anthropic: [Claude Fable 5.2 – Modellübersicht](https://platform.claude.com/docs/en/models/fable-5-2/overview) - Anthropic: [Introducing Claude Fable 5.2 and Mythos 5.2](https://www.anthropic.com/claude-fable-and-mythos-5-2) - Anthropic: [Claude Opus 5.5 – Modellübersicht](https://platform.claude.com/docs/en/models/opus-5-5/overview) - Anthropic: [Modellübersicht](https://platform.claude.com/docs/en/models/overview) - Anthropic: [Preise](https://platform.claude.com/docs/en/about-claude/pricing) Alle geprüft am 12.11.2026.