Fable 5.2, 5.1 oder Opus 5.5: Wann lohnt sich der Wechsel?

Fable 5.2 ist der günstigere Upgrade-Kandidat für bestehende Fable-5.1-Aufgaben. Für viele neue Aufgaben bleibt Opus 5.5 jedoch der preiswertere Ausgangspunkt. Entscheidend ist, ob das teurere Modell ein abgenommenes Ergebnis zu geringeren Gesamtkosten liefert oder eine Anforderung erfüllt, an der das günstigere scheitert.

Dies ist ein Vergleich dokumentierter Funktionen und Kosten, geprüft am 10. November 2026, mit nachvollziehbaren Berechnungen. Er ist weder ein Geschwindigkeitsbenchmark noch eine Aussage über gemessene Erfolgsquoten. Ofox veröffentlicht diesen Artikel und bietet die Modelle über seinen API-Katalog an. Daraus folgt nicht, dass eines davon für Ihre Arbeitslast am besten geeignet ist.

Welche Unterschiede tatsächlich bestehen

Quellen: die offiziellen Modelltabellen für Fable 5.2 und Fable 5.1 sowie die Preisreferenz. Da die Obergrenzen gleich sind, unterscheidet der Wunsch nach einem größeren Kontextfenster diese drei Modelle nicht.

Der datierte Ofox-Katalog nennt für diese Felder dieselben Standardtarife unter anthropic/claude-fable-5.2, anthropic/claude-fable-5.1 und anthropic/claude-opus-5.5. Verglichen werden Listenpreise, keine Lieferantenpreise und keine Rechnung. Anbietertypen und Funktionsverfügbarkeit können sich unterscheiden. Dokumentieren Sie deshalb neben dem Modellnamen auch die Route.

Bei Fable 5.2 sind reguläre Eingabe und Ausgabe 20 % günstiger als bei 5.1. Pro ungecachtem Eingabe- oder Ausgabe-Token kostet es doppelt so viel wie Opus 5.5, während Cache-Lesen gleich viel kostet. Keine dieser Aussagen bestimmt die Kosten einer abgeschlossenen Agent-Aufgabe: Ausgabelänge, Cache-Verhalten, Versuche und Tool-Arbeit können abweichen.

Drei nachrechenbare Kostenszenarien

Die folgenden Tokenbudgets sind synthetische Beispiele, keine gemessenen Ausgaben. Alle verwenden synchrone Standardpreise in USD, ohne Batch-Rabatt, Fast Mode oder separat berechnete Tools. Ausgabe bedeutet die gesamte abgerechnete Ausgabe einschließlich Reasoning, soweit berechnet. Cache-Leseszenarien lassen die frühere Cache-Schreibanfrage weg und dürfen nicht als Rechnung für die gesamte Sitzung gelten.

Die letzte Zeile zeigt, weshalb die pauschale Aussage „Fable kostet doppelt so viel“ bei einer überwiegend aus dem Cache bedienten Anfrage nicht stimmt. Der Cache-Anteil kostet sowohl bei 5.2 als auch bei Opus 5.5 $0.02. Nur restliche Eingabe und Ausgabe unterliegen dem höheren Fable-Tarif. Das Kostenverhältnis der Anfrage liegt deshalb bei etwa 1,23 statt 2.

Die mittlere Zeile lässt sich so berechnen:

from decimal import Decimal as D

rates = {
    "fable52": (D("8"), D("40"), D("0.20")),
    "fable51": (D("10"), D("50"), D("0.25")),
    "opus55": (D("4"), D("20"), D("0.20")),
}
for name, (input_rate, output_rate, read_rate) in rates.items():
    cost = (1000 * input_rate + 4000 * output_rate
            + 19000 * read_rate) / D("1000000")
    print(name, cost)

Cache-Erstellung wird separat berechnet. Die veröffentlichten Schreibpreise für 5 Minuten betragen der Reihe nach $10, $12.50 und $5 pro Million Token, für 1 Stunde $16, $20 und $8. Berücksichtigen Sie die passende Schreibgebühr, tatsächliche Cache-Fehltreffer und Ablaufzeiten bei der Sitzungsschätzung. Kalkulieren Sie nicht jeden Schritt als Cache-Treffer, nur weil der Code eine Cache-Anweisung enthält.

Wie viel zusätzliche Ausgabe würde die Ersparnis gegenüber 5.1 aufheben?

Angenommen, eine 5.1-Aufgabe verbraucht wie in der ersten Zeile 20.000 ungecachte Eingabe- und 4.000 Ausgabe-Token. Die berechneten Kosten liegen bei $0.40. Dieselbe Eingabe kostet bei 5.2 $0.16; bis zum gleichen Gesamtbetrag bleiben $0.24. Bei $40 pro Million Ausgabe-Token reicht das für 6.000 Ausgabe-Token.

Unter genau diesen Annahmen könnte 5.2 gegenüber dem 5.1-Beispiel 50 % mehr Ausgabe erzeugen und gleich viel kosten. Würden Eingabe und Ausgabe im selben Verhältnis wachsen, erlaubte die Preissenkung um 20 % dagegen 25 % mehr Tokenvolumen bis zum Kostengleichstand. Die unterschiedlichen Prozentsätze beantworten unterschiedliche Fragen; keiner sagt das tatsächliche Modellverhalten voraus.

Deshalb sollte die erste Migrationsmessung Tokenkategorien für dieselbe Aufgabe erfassen. Ein günstigerer Tarif und eine höhere Rechnung können gleichzeitig zutreffen, wenn das neue Modell mehr arbeitet, erneut ansetzt oder zusätzliche Tools nutzt. Der API-Leitfaden erklärt, welche Antwortfelder aufzubewahren sind.

Nach Aufgabe und Abnahmekriterium auswählen

Dies sind Auswahlregeln, keine Leistungsbefunde eines eigenen Modellwettbewerbs. Eine Rechnungsextraktion sollte etwa ein Ergebnis mit fehlender Rechnungs-ID oder falscher Summe zurückweisen, auch wenn der Text flüssig klingt. Eine Repository-Reparatur sollte relevante Tests bestehen und sachfremde Änderungen vermeiden. Ein Recherchebericht sollte jede wesentliche Aussage mit einer zugänglichen Quelle verbinden und offene Widersprüche in den Belegen erhalten.

Die offizielle Anleitung zur Modellwahl empfiehlt, für die meisten Arbeitslasten mit Opus zu beginnen und zu eskalieren, wenn die Evaluation weiterhin unzureichend ausfällt. Der Wert der Fable-Klasse liegt in der Arbeit, die abgenommen werden kann, nicht in einer höheren Versionsnummer an sich.

Kosten pro abgenommener Aufgabe statt nur pro Aufruf vergleichen

Teilen Sie für vergleichbare Aufgaben die gesamten API- und Tool-Ausgaben durch die Zahl abgenommener Ergebnisse. Behalten Sie abgelehnte, unvollständige und manuell reparierte Aufgaben in der Kostenrechnung. Werden Fehlschläge ausgeschlossen, erscheint ein schwaches Modell künstlich günstig.

Als Rechenbeispiel kostet ein Opus-Versuch $0.16 und ein Fable-Versuch $0.32, entsprechend unserer ersten synthetischen Zeile. Bei angenommenen Abnahmequoten von 50 % und 90 % ergäben sich vereinfacht $0.32 beziehungsweise etwa $0.356 pro abgenommenem Versuch. Die höhere Abnahmequote würde den Preisunterschied nicht automatisch ausgleichen. Diese Quoten sind für die Berechnung erfunden, keine gemessenen Modellergebnisse.

Das vereinfachte Modell setzt vergleichbare unabhängige Versuche voraus und lässt manuelle Reparaturen, Wartezeit und externe Tools weg. Ein realer Workflow kann ein Modell mit weniger Wiederholungen bevorzugen, weil jeder Fehlschlag teure Prüfzeit bindet. Weisen Sie diese Kosten separat mit einer ausdrücklichen Stundensatzannahme aus, statt sie in einer Behauptung zur Tokenleistung zu verstecken.

Bei gestuftem Routing messen Sie den ganzen Ablauf: Opus-Versuch, Validierung, Eskalation, Fable-Versuch und abschließende Validierung. Der Start mit dem günstigeren Modell ist nicht kostenlos, wenn fast jede Aufgabe eskaliert. Führen Sie beim Routenvergleich niemals denselben nicht idempotenten Seiteneffekt zweimal aus.

Migrationskosten vor der Umstellung einbeziehen

Fable 5.2 prüft Konversationspräfixe bei jedem Konto. Ein älterer Client, der System-Prompts oder Tools umschreibt, benötigt möglicherweise Reparaturen, auch wenn seine 5.1-Aufrufe akzeptiert wurden. Auch der Standard-Effort unterscheidet sich von Opus 5.5: Ohne explizite Einstellung vergleichen Sie medium mit high. Setzen Sie Effort ausdrücklich und legen Sie die Konfiguration offen.

Der Migrationsleitfaden nennt außerdem Unterschiede bei Aufbewahrung, Computer-Tool, Advisor und Thinking-Kompatibilität. Insbesondere gibt es für das alte Computer-Use-Tool eine Amazon-Bedrock-Ausnahme. Übertragen Sie eine plattformspezifische Inkompatibilität nicht auf alle Ofox-Routen. Die 400-Diagnose zeigt die Reparaturwege.

Beim Fallback von 5.2 auf ein älteres Modell bedeutet eine erfolgreiche Anfrage nicht zwingend, dass das 5.2-Reasoning erhalten bleibt. Speichern Sie geprüfte Aufgabenfakten und Tool-Ergebnisse getrennt. Unser Agent-Checkpoint-Leitfaden erklärt, was das empfangende Modell zum Abschluss braucht.

Einen überschaubaren Vergleich durchführen

Verwenden Sie eine feste Auswahl repräsentativer Aufgaben mit einem zurückgehaltenen Testanteil. Fixieren Sie Prompt, Eingabedateien, Tools und Abnahmekriterien vor Sichtung der Ergebnisse. Erfassen Sie pro Modell exakte ID, Route, Effort, Tokenlimit, SDK-Version, Zeitstempel, Eingabe-/Ausgabe-/Cache-Verbrauch, Tool-Kosten, Abschlussstatus und Abnahmeurteil.

Beginnen Sie für jeden Kandidaten mit seiner üblichen Produktionseinstellung und vergleichen Sie anschließend ausdrücklich Effort-Stufen, falls Kosten oder Qualität angepasst werden müssen. Gleiche Effort-Bezeichnungen sind eine Konfigurationskontrolle, kein Beleg für gleichen internen Rechenaufwand. Halten Sie auch Timeouts, Wiederholungen, Ablehnungen und fehlende Ausgabe fest; ersetzen Sie solche Fälle nicht still durch erfolgreiche Wiederholungen.

Setzen Sie 5.2 ein, wenn es Ihre Qualitätsuntergrenze erreicht und ein ausdrückliches Ziel verbessert, etwa Kosten pro abgenommener Aufgabe, Abschluss schwieriger Fälle oder Prüfaufwand. Halten Sie 5.1 nur so lange vor, wie es für einen getesteten Rollback nötig ist. Unterscheiden Sie dabei Modell-Rollback und Wiederherstellung signierter Konversationsdaten.

Weiterführende Dokumentation: Ofox-Modellkatalog, Verbrauchsaufzeichnung und native Messages. Scheitert ein Vergleichslauf nach einem Tool-Aufruf, beheben Sie den Zuordnungsfehler bei Tool-Ergebnissen, englische Anleitung, bevor Sie den Lauf als Beleg für Reasoning-Qualität werten.