Fable 5.2 vs. Opus 5.5: Coding, Praxisfälle und Kosten
Fable 5.2 und Opus 5.5 im Vergleich: konkrete Aufgaben, Vergleichsvideos, High gegen Max, Cache-Kosten und die passende Modellwahl.
EvoLink TeamProduktteamIn diesem Artikel
Für Teams, die Modellzugang und Kosten über EvoLink verwalten, geht es um die passende Konfiguration für eine konkrete Aufgabe. Eine gewöhnliche Repository-Änderung, eine schwierige Migration und ein Rechercheagent können unterschiedliche Einstellungen rechtfertigen. Der Vergleich soll zeigen, wo ein besseres Ergebnis die tatsächlich lieferbare Arbeit verändert.
Öffentliche Praxisbeispiele zeigen unterschiedliche Ergebnisse
Konkrete Beispiele erleichtern die Auswahl. Die ersten drei Vergleiche sind einzelne, von ihren Autoren berichtete Durchläufe; der vierte ist ein Anthropic-Experiment. Keiner wurde von EvoLink reproduziert oder bildet die durchschnittliche Leistung im Alltag ab.
Fehler in einem vorhandenen Plugin finden und beheben
Entwickler Octavio Aranda ließ beide Modelle echte Plugin-Fehler finden, reproduzieren und Korrekturen vorschlagen. Nach eigener Aussage verwendete er dieselben Anweisungen und denselben Effort. Beide fanden dieselben sechs Fehler im Ziel-Plugin.
| Vom Autor berichtetes Ergebnis | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Zeit | 2,9 Minuten | 6,6 Minuten |
| Kosten zu API-Tarifen | ≈ $0.76 | ≈ $2.78 |
| Korrekturen mit Tests des anderen Modells | Alle bestanden | Ein Test fehlgeschlagen |
Eine Glas-Pool-Szene mit höherer Rechnung
Mr Tactical veröffentlichte einen Videovergleich einer Glas-Pool-Szene.
| Vom Autor berichtetes Ergebnis | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Zeit | 68 Minuten | 90 Minuten |
| Kosten | $14.39 | $57.87 |
Entscheiden Sie bei einem visuellen Prototyp, ob zusätzliche Details für das Briefing relevant sind. Für eine ausgewählte Szene kann weitere Arbeit sinnvoll sein; zur Ideenfindung reichen womöglich günstigere Entwürfe.
Cathedral of Ice: früher fertig, aber teurer
Tony, bekannt als EnvolDev, berichtet vom gleichen Cathedral-of-Ice-Prompt für beide Modelle.
| Vom Autor berichtetes Ergebnis | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Zeit | 3 Std. 11 Min. 26 Sek. | 1 Std. 56 Min. 52 Sek. |
| Kosten | $45.97 | $81.10 |
Ein großes Formalisierungsprojekt mit unterschiedlichem Abschluss
Hier unterscheidet sich der Abschluss einer anspruchsvollen Aufgabe. Die spezialisierte Infrastruktur, Ausgangsmaterialien und Verifikation grenzen den Fall von gewöhnlichem Coding ab.
Die Beispiele sprechen für unterschiedliche Entscheidungen. Eine geprüfte Korrektur, bevorzugte visuelle Details, kürzere Wartezeit und der Abschluss eines festgefahrenen Projekts sind verschiedene Ziele. Wählen Sie das für die Aufgabe wichtige Ergebnis und vergleichen Sie die Kosten dorthin.
Unterschiede, die Ihre Modellauswahl beeinflussen
Die regulären Claude-API-Spezifikationen liegen zunächst nah beieinander.
| Reguläre API-Spezifikation | Opus 5.5 | Fable 5.2 |
|---|---|---|
| Modell-ID | claude-opus-5-5 | claude-fable-5-2 |
| Kontextfenster | 1M tokens | 1M tokens |
| Maximale Ausgabe regulärer Nachrichten | 128K tokens | 128K tokens |
| Ein- und Ausgabe | Text und Bilder → Text | Text und Bilder → Text |
| API-Standard-Effort | medium | high |
| Neue Eingaben je Million Token (USD) | $4 | $8 |
| Ausgaben je Million Token (USD) | $20 | $40 |
Fable bietet in diesem Vergleich kein größeres Kontextfenster. Fehlt eine relevante Datei oder enthält die Aufgabenbeschreibung widersprüchliche Anforderungen, bleibt dieses Problem nach einem Modellwechsel bestehen. Prüfen Sie zunächst, ob beide Kandidaten die nötigen Informationen erhalten.
Auch Standard-Effort verändert den Vergleich: Ohne Angabe verwendet die API Medium bei Opus und High bei Fable. Das beschreibt Standardanfragen, ersetzt aber nicht den Vergleich der tatsächlich verwendeten Opus-Konfiguration mit geeigneten Fable-Einstellungen.
Benchmarks zeigen Vorteile und eine relevante Ausnahme
Anthropic veröffentlicht folgende Evaluationsergebnisse.
| Evaluation | Opus 5.5 | Fable 5.2 |
|---|---|---|
| FrontierCode 2.0 | 45.5% | 49.1% (Xhigh) |
| FrontierSWE v2 | 62.3% | 69.9% |
| AutomationBench | 42.5% | 51.4% |
| AA-Briefcase v1.1 Rubrikbewertung | 61.2% | 66.1% |
| AA-Briefcase v1.1 Elo | 1800 | 1785 |
Das spricht dafür, Fable bei schwierigerer Arbeit zu evaluieren und die Abnahmekriterien beizubehalten. Prüfen Sie bei Code Verhalten und Tests, bei Analysen Belege, Berechnungen und die Erfüllung des Briefings. Ein höherer Gesamtwert entscheidet nicht, welche Fehler für Ihre Anwendung wichtig sind.
Fable High mit Ihrer tatsächlichen Opus-Konfiguration vergleichen
Höhere Tokenpreise und niedrigere Aufgabenkosten können zusammen auftreten, weil Konfigurationen unterschiedlich viel Arbeit und Token verbrauchen. Das Ergebnis gilt für diese Evaluation und beweist keine gleichartige Ersparnis gegenüber Opus Medium bei gewöhnlichen Coding-Aufgaben.
Wenn Sie Opus für schwierige Arbeit bereits auf Max stellen, ist Fable High ein sinnvoller Testkandidat. Liefert Opus Medium bereits akzeptierte Ergebnisse, klären Sie zuerst das Verbesserungsziel: Abschlussrate, Prüfaufwand oder Zeit bis zum nutzbaren Ergebnis. So wird ein attraktiver Benchmark nicht automatisch zur Budgeterhöhung.
Die passende Rolle im Coding-Workflow
| Aufgabe | Ausgangspunkt | Grund für einen Wechsel |
|---|---|---|
| Klare Änderung mit zuverlässigen Tests | Bisherige Opus-Konfiguration behalten | Fable spart ausreichend Gesamtzeit oder Korrekturaufwand |
| Festgefahrene Migration oder Refaktorierung | Fable High gegen aktuelles Opus testen | Verhalten bleibt erhalten und dieselben Prüfungen bestehen |
| Schwierige Architekturentscheidung | Pläne vor der Implementierung vergleichen | Plan erfüllt die Anforderungen und führt zu einer brauchbaren Änderung |
| Review einer wichtigen Codeänderung | Fable als zusätzlichen Reviewer evaluieren | Nachprüfbare Funde ohne übermäßige Fehlalarme |
Das sind Ausgangspunkte für Tests. Entscheidend ist, ob ein Modellwechsel die Ergebnisse dieser Aufgabenklasse verbessert.
Bei einer Service-Migration mit wiederkehrenden Kompatibilitätsfehlern erhalten beide Kandidaten Schnittstellenvertrag, Implementierung, relevante Tests und die bekannten Fehler. Sie sollen Ursache erklären, einen Plan vorschlagen und die kleinste brauchbare Änderung umsetzen. Die Abnahme prüft Kompatibilität und Verhalten auch außerhalb des sichtbaren fehlgeschlagenen Tests.
Bei Code-Reviews verlangen Sie für jeden Fund Position, konkreten Auslöser, Folgefehler und Beleg. Zählen Sie bestätigte Funde, übersehene Defekte und die Zeit zur Prüfung von Fehlalarmen. Eine lange Bedenkenliste kann Wartenden zusätzliche Arbeit machen, ohne die Änderung zu verbessern.
Doppelte Tokenpreise bedeuten nicht immer doppelte Anfragekosten
Die folgenden Rechenbeispiele verwenden je Modell identische abgerechnete Tokenmengen.
| Rechenbeispiel | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 100K neue Eingabe- und 10K abgerechnete Ausgabe-Token | $0.60 | $1.20 |
| 800K vorhandene Cache-Lese-Token + 100K neue Eingaben + 10K Ausgaben | $0.76 | $1.36 |
Die zweite Zeile setzt einen vorhandenen Cache-Präfix voraus und schließt dessen frühere Erstellungskosten aus. Beide Zeilen enthalten keine Werkzeuge, Wiederholungen oder anderen Gebühren. Es sind Berechnungen anhand regulärer Tarife und keine gemessenen Aufgabenergebnisse.
Für ein vollständiges Coding-Projekt zählen auch fehlgeschlagene Anfragen und weitere Versuche. Vergleichen Sie sämtliche Workflowkosten geteilt durch die Anzahl akzeptierter Aufgaben und erfassen Sie menschliche Prüfzeit separat. Eine teurere Konfiguration kann durch weniger wiederholte Fehler die Kosten je akzeptiertem Ergebnis senken. Mehr Erkundung ohne bessere Abnahme bringt dagegen wenig Nutzen.
Erfassen Sie Cache-Erstellung und Wiederverwendung. Eine Anfrage mit warmem Cache hilft bei der Analyse wiederkehrender Arbeit; die erste Anfrage gehört trotzdem zu den Projektkosten.
Fable an Entscheidungspunkten und Opus für die Umsetzung
In einer selbst kontrollierten Anwendung reicht auch eine explizite Übergabe: Anforderungen, Plan, Entscheidungen, offene Fragen und Testergebnisse. Das ausführende Modell soll Abweichungen zwischen Plan und Realität melden. Fordern Sie zusätzliche Prüfung dort an, wo stärkere Urteilskraft benötigt wird, statt jeden kleinen Schritt automatisch prüfen zu lassen.
Vergleichen Sie die Kombination mit Opus allein und Fable allein. Zählen Sie Planung und Prüfung neben der Umsetzung mit. Ein schlechter Plan bleibt durch einen günstigeren Executor möglicherweise falsch; die Übergabe muss Annahmen infrage stellen können.
Der native Advisor ist eine Anthropic-Funktion von Claude Code. Verfügbarkeit über andere API-Kanäle muss separat geprüft werden. Eine eigene Planübergabe setzt kein gleichnamiges Gateway-Werkzeug voraus.
Beim Modellwechsel den Aufgabenstatus übergeben
Halten Sie bei wechselnden Modellen den Aufgabenstatus in normalen Dokumenten fest: akzeptierte Anforderungen, geänderte Dateien, Prüfungen und offene Probleme. Testen Sie dann den tatsächlichen Wechsel in Ihrer Anwendung einschließlich Historie und Zusammenfassungen.
Aus dem Vergleich eine EvoLink-Modellentscheidung machen
Beginnen Sie mit einer Routineaufgabe, einer Aufgabe, bei der Opus Schwierigkeiten hatte, und einer längeren Werkzeugsequenz. Halten Sie Eingaben und Abnahmekriterien konstant. Vergleichen Sie die aktuelle Opus-Konfiguration mit Fable High und verändern Sie Effort erst nach beobachtetem Nutzen. Wiederholen Sie variable Aufgaben und bewahren Sie die Anzahl akzeptierter Ergebnisse auf.
Behalten Sie Opus, wo es weiterhin gute Ergebnisse zu angemessenen Kosten liefert. Leiten Sie aus gemessenen Fable-Verbesserungen konkrete Eskalationsregeln ab, etwa für eine Aufgabenklasse oder einen wiederkehrenden Fehler. So bleibt die Modellstrategie erklärbar und wartbar.
Häufige Fragen
Ist Fable 5.2 beim Programmieren besser als Opus 5.5?
Bei den oben gezeigten Coding-Benchmarks erzielt es höhere Werte. Ob es Ihren Workflow verbessert, hängt von Aufgabe, Effort, Werkzeugen und Abnahmekriterien ab.
Ist Fable immer teurer?
Die regulären Preise für neue Eingaben und Ausgaben sind höher. Vollständige Aufgabenkosten hängen auch von Verbrauch, Cache, Wiederholungen und Werkzeugen ab. Der offizielle Vergleich Fable High gegen Opus Max zeigt, warum die ganze Konfiguration zählt.
Ist ein Vergleich nur fair, wenn beide Modelle auf Max stehen?
Vergleichen Sie die tatsächlich einsetzbaren Einstellungen mit klaren Budgets und Qualitätsanforderungen. Ein Vergleich der Leistungsgrenzen kann sinnvoll sein, beantwortet aber eine andere Frage als die beste Produktionskonfiguration.
Hat Fable ein größeres Kontextfenster?
Beide geben 1M Token an. Prüfen Sie, ob das Modell den relevanten Kontext korrekt nutzt; Kapazität allein ist kein Qualitätsnachweis.
Kann Fable planen, während Opus den Code schreibt?
Ja, das ist ein prüfbarer Workflow mit explizitem Plan und verifizierbarem Ergebnis. Rechnen Sie beide Modelle und die Korrektur einer schlechten Übergabe mit ein.
Wann sollte ich bei Opus bleiben?
Wenn Ihre Konfiguration Qualitäts- und Zeitziele erfüllt und der Kandidat keinen lohnenden Vorteil bietet. Ein neues Modell ändert die Abnahmekriterien einer bereits erfolgreichen Aufgabe nicht.
