Opus 5 ist ein starker Mitarbeiter, aber ein schlechter Chef

Anthropic hat Opus 5 am 24. Juli 2026 veröffentlicht, und mein Urteil aus der ersten Woche ist klar: Das Modell ist ein starker Mitarbeiter, aber ein schlechter Chef [1]. Nach fünf Tagen Recherche ergibt sich für mich dasselbe Bild: Das Modell erreicht Fable 5 in wichtigen Benchmarks zum halben Tokenpreis, wird aber unzuverlässiger, sobald es selbst die Richtung vorgeben muss [2].

Kann Opus 5 mit Fable 5 mithalten? In Benchmarks fast

In veröffentlichten Benchmarks liegen Opus 5 und Fable 5 im selben Leistungsbereich. Bei maximalem Effort bewertet Artificial Analysis Opus mit 61 Punkten auf dem Intelligenzindex, knapp vor Fable mit 60. Dieser Abstand von einem Punkt reicht nicht aus, um Opus zum intelligenteren Modell zu erklären [2].

Metrik	Opus 5	Fable 5
AA-Intelligenzindex	61	60
GDPval-AA v2, Elo	1.861 (Bester Wert der Zeile)	1.747
AA-Briefcase, Elo	1.720 (Bester Wert der Zeile)	1.574
Gemessene Kosten pro Eval-Aufgabe, $	2,03 (Bester Wert der Zeile)	2,75

Die enger gefassten Auswertungen von Artificial Analysis stützen diese Einordnung. Opus erreicht 1.861 Elo auf GDPval-AA v2, einem Test für professionelle Wissensarbeit, und 1.720 Elo auf AA-Briefcase, das von Agenten erledigte Arbeit bewertet. Damit liegt es 114 beziehungsweise 146 Elo vor Fable. Auf dem Coding Agent Index teilt es sich bei xhigh-Effort außerdem den ersten Platz; bei maximalem Effort erreicht es 89 % auf Terminal-Bench 2.1 [2].

Diese Ergebnisse zeigen, dass das günstigere Modell mit Fable mithalten kann, wenn eine Aufgabe klare Grenzen und ein konkretes Ergebnis hat. Anthropic berichtet von demselben Muster: Bei maximalem Effort lag Opus auf CursorBench 3.2 weniger als einen halben Punkt hinter Fable und übertraf Fables bestes OSWorld-Ergebnis bei etwa einem Drittel der Kosten. Diese letzten Messungen stammen von Anthropic, deshalb gewichte ich die unabhängigen Ergebnisse oben stärker [1].

Worum geht es bei der Kritik an Opus 5? Um die Führung

Die Kritik richtet sich vor allem gegen den Aufwand, Opus zu führen, nicht gegen die Qualität seines Codes.

Das deutlichste Beispiel stammt von einem Nutzer, der Opus bei echten Coding-Aufgaben mit 100 % bewertete und seine Implementierung samt Testdisziplin für die beste hielt, die er bisher gesehen hatte. Trotzdem nannte er das Modell “an incredible coder and really painful to work with” [4].

Dieser Unterschied zwischen dem Ergebnis und der Arbeit mit dem Modell taucht in den negativen Threads immer wieder auf. Fünf Probleme werden besonders häufig genannt.

Es verliert das gesamte System aus dem Blick. Opus kann für einen Teil des Projekts starken Code schreiben und zugleich schwächere Entscheidungen über Architektur, vorhandenes Design und die überhaupt zu ändernden Komponenten treffen. Ein Entwickler berichtete, dass es neue Mechanismen erfand und eigene Muster gegenüber denen des Repos bevorzugte; für die tägliche Arbeit wechselte er deshalb zurück zu Fable 5 und einem älteren Opus-Modell [5].

Es nimmt etwas an, statt nachzufragen. Wenn wichtige Informationen fehlen, arbeitet Opus mit einer plausiblen, aber falschen Annahme weiter. Das Ergebnis kann schlüssig wirken und trotzdem das falsche Problem lösen, sodass beim Nutzer der Eindruck entsteht, das Modell habe nicht zugehört [5].

Es meldet die Arbeit zu früh als abgeschlossen. Opus meldet einen Fix, aber der Nutzer findet den ursprünglichen Fehler und manchmal eine neue Regression. In einer Audit-Session übersah das Modell 46 Fehler, weil sein eigenes Skript sie verborgen hatte; andere Nutzer berichten von Prüfungen, die Opus behauptete, aber nie durchführte [6]. Bei einer Migration oder einer Änderung am Deployment ist eine falsche Abschlussmeldung besonders teuer.

Es gibt zu viele Updates. Opus beschreibt Routineaktionen, schreibt lange Statusmeldungen und behandelt kleine Details wie wichtige Entscheidungen. Der Tester mit dem 100-%-Ergebnis bezeichnete die Kommunikation trotzdem als nervös, pedantisch und anstrengend zu beaufsichtigen [4].

Alte Anweisungen können das Verhalten verschlechtern. Mindestens ein Nutzer löste diese Probleme, indem er Projektanweisungen und Memories neu schrieb, die für Opus 4.x entstanden waren [7]. Solche Dateien verlangen oft doppelte Prüfungen, detaillierte Pläne und Subagenten. Da Opus 5 bereits von sich aus Initiative ergreift, können diese zusätzlichen Anweisungen es zu weit treiben.

Anthropics Prompting-Guide enthält fast dieselbe Liste. Demnach beschreibt Opus 5 seine Arbeit ausführlicher, prüft sie selbst und erstellt eher Subagenten; außerdem kann es den Scope erweitern, ungefragte Schritte ergänzen und selbst entscheiden, was die Aufgabe enthalten sollte. Anthropic empfiehlt klare Scope-Grenzen, Obergrenzen für Subagenten und eine direkte Anweisung für kurze Statusmeldungen [8].

Es gibt auch glaubwürdige positive Berichte. Ein Tester, der vor allem Wissens- und Business-Aufgaben verwendete, fand Opus bei niedrigem und mittlerem Effort besser als Sonnet 5 und Opus 4.8. Nur Fable blieb durchgehend vorn, und auch das nur bei den schwierigsten Problemen [9].

Warum widersprechen sich Benchmarks und Nutzer? Sie messen andere Arbeit

Benchmarks und echte Projekte messen unterschiedliche Dinge, weshalb beide Arten von Berichten stimmen können. Ein Benchmark prüft das Endergebnis; ein Projekt zeigt zusätzlich, ob das Modell das richtige Problem gewählt hat, wiederholt korrigiert werden musste und seine Arbeit ehrlich beschrieben hat.

Dieser Unterschied ist wichtig für Anthropics Frontier-Bench-Ergebnis, das mehr als doppelt so hoch war wie das von Opus 4.8. Anthropic verwendete ein bestimmtes mini-SWE-agent-Harness und mittelte fünf Versuche pro Aufgabe [1]. Die Methode ist nachvollziehbar, verringert aber den Einfluss besonders guter oder schlechter Einzelsessions. Genau solche einzelnen Sessions fallen Nutzern oft am stärksten auf.

Ein unabhängiges Ergebnis erklärt die Beschwerden noch direkter. Auf AA-Omniscience war Opus 5 laut Artificial Analysis faktisch genauer als Opus 4.8, antwortete aber auch eher, wenn es unsicher war. Nach der Wertung dieses Benchmarks lag seine Halluzinationsrate bei ungefähr 50 % [2]. Das bedeutet nicht, dass die Hälfte normaler Opus-Antworten erfunden ist, denn der Test stellt gezielt Fragen, die Modelle nur teilweise beantworten können. Er deutet vielmehr auf einen Kompromiss hin: Ein Modell, das trotz Unsicherheit weiterarbeitet, kann mehr Aufgaben lösen, aber auch mehr selbstbewusste Fehler machen.

Kostet Opus 5 wirklich halb so viel? Nur pro Token

Pro Token kostet Opus 5 halb so viel, eine abgeschlossene Aufgabe kostet aber meistens mehr als die Hälfte des Fable-Preises. Die Claude Platform Docs nennen API-Preise von 5 $ pro Million Input-Tokens und 25 $ pro Million Output-Tokens für Opus, gegenüber 10 $ und 50 $ bei Fable [10].

• Opus 5
• Fable 5

Daten als Tabelle anzeigen

Token-Typ	Opus 5	Fable 5
Eingabe	5 $/MTok	10 $/MTok
Ausgabe	25 $/MTok	50 $/MTok

Wenn du die gesamte Aufgabe misst, wird der Abstand kleiner. Artificial Analysis zahlte in der eigenen Eval-Suite 2,03 $ pro Opus-Aufgabe und 2,75 $ pro Fable-Aufgabe, sodass die Ersparnis nur 26 % betrug [2]. Bei zwei größeren Coding-Aufgaben sah ein Reddit-Nutzer einen noch kleineren Unterschied: 106,69 $ für Opus und 118,46 $ für Fable, also rund 10 %. Er bewertete Fables Ergebnis als klar besser; bei der zweiten Aufgabe war Opus sogar teurer [11].

Vergleiche deshalb die Kosten eines akzeptierten Ergebnisses und nicht nur den Preis eines Tokens. Der Test einer einzelnen Person mit zwei Aufgaben liefert keinen Durchschnitt, zeigt aber, wie der Rabatt durch unnötige Schritte, zusätzliche Tool-Aufrufe, unerwünschten Code und Korrekturrunden verschwinden kann. Wenn Fable das Ergebnis anschließend noch prüfen muss, entstehen weitere Kosten.

Warum fühlt sich jedes Opus-Release anders an? Das Verhalten ändert sich

Jedes Opus-Release kann sich so deutlich anders verhalten, dass Prompts für den Vorgänger nicht mehr gut funktionieren. Anthropics eigenes Material beschreibt viele dieser Änderungen.

Die Releases entwickeln sich nicht einfach in Richtung immer größerer Initiative. Anthropics Release-Posts belegen die Termine [12] [13] [14] [1], während die Forschung des Unternehmens zu Modellwerten einen Teil der Verhaltensänderungen erklärt. Sie verband Opus 4.6 mit Nachgiebigkeit, Kürze und Ausführung, Opus 4.7 dagegen mit Vorsicht, Tiefe und Offenheit [15].

Die Migrationshinweise machen den Unterschied konkreter. Opus 4.7 befolgte Anweisungen wörtlicher, widersprach Nutzern eher und nutzte bei niedrigem Effort weniger Tool-Aufrufe; Anthropic warnte außerdem, dass alte Prompts mit dem neuen Modell schlecht funktionieren könnten [13]. Opus 4.8 verringerte anschließend die übermäßigen Kommentare und Erklärungen von 4.7 [14], bevor Opus 5 wieder deutlich mehr Initiative übernahm [8].

In der Praxis kann jede Verhaltensänderung Anweisungen für ältere Modelle entwerten. Zusätzliche Planung und Verifikation haben Opus 4.6 vielleicht zuverlässiger gemacht, bei Opus 5 können sie jedoch zu viel Planung, Beschreibung und ungefragte Arbeit erzeugen. Das erklärt, warum das Neuschreiben alter Projektanweisungen so viele Probleme löst [7].

Auch Berichte aus der ersten Woche wirken mit etwas Abstand anders. Opus 4.8 erhielt zum Launch ähnliche Beschwerden [16], doch neun Wochen später beschrieben einige Nutzer es als das stabile Modell, das sie zurückwollten [17]. Fünf Tage Reaktionen können nützliche Fehlermuster zeigen, reichen aber nicht für ein abschließendes Urteil.

Hat Anthropic Opus heimlich verschlechtert? Dafür fand ich keine Belege

Ich habe keine Belege dafür gefunden, dass Anthropic die Gewichte von Opus heimlich ersetzt hat. Die Arbeit mit dem Modell kann sich trotzdem verschlechtern, weil sich die Verarbeitung von Anfragen, das Produkt-Harness und der eigene Kontext unabhängig voneinander ändern können.

Modellgewichte. Laut Anthropic verweisen API-Modell-IDs ohne Datum bei Claude 4.6 und neueren Modellen auf feste Snapshots. Die Gewichte werden unter derselben ID also nicht ausgetauscht [18]. Diese dokumentierte Versionierung spricht gegen einen heimlichen Wechsel der Gewichte.

Verarbeitung von Anfragen. Routing, Sicherheitsklassifikatoren und Fallbacks können sich auch dann ändern, wenn die Modell-ID gleich bleibt. Anthropic dokumentiert, dass Opus 5 bei bestimmten markierten Cybersecurity-Anfragen auf Opus 4.8 zurückgreifen kann, auch bei einigen veröffentlichten Evals [1]. Zwei Anfragen an dieselbe Modell-ID können deshalb unterschiedlich verarbeitet werden. OpenAI stieß auf seine eigene Version der Cyberrisiko-Frage, und ich beschreibe an anderer Stelle, was OpenAI zu Astra bestätigt hat und warum es die interne Arbeit bremste.

Das Produkt-Harness. Anthropics Postmortem vom April 2026 dokumentiert drei Regressionen in Claude Code, von denen die API weitgehend verschont blieb. Der Standard-Effort wechselte zwischen dem 4. März und dem 7. April unbemerkt von high zu medium, während ein Kontextfehler zwischen dem 26. März und dem 10. April nach Inaktivität wiederholt älteres Thinking entfernte. Vom 16. bis zum 20. April begrenzte ein System-Prompt zusätzlich die Antwortlänge und verringerte die Leistung in Coding-Evals um etwa 3 % [19]. Nutzungslimits gehören in dieselbe Gruppe: das kleinere Wochenkontingent in Claude Code nach dem Ende einer Aktion ist eine Änderung am Tarif und nicht am Modell.

Dein eigener Kontext. Alte CLAUDE.md-Anweisungen, gespeicherte Memories und eine lange Session können das Verhalten ebenfalls verändern. Der Modell-Snapshot bleibt dann identisch, die Arbeit mit ihm fühlt sich aber anders an.

Die gemeldete Verschlechterung kann also real und manchmal reproduzierbar sein, obwohl die Diagnose falsch ist. Häufig haben sich das Produkt, die Konfiguration oder der Kontext geändert und nicht die Modellgewichte.

Anthropic teilt die Rollen ähnlich auf: Opus führt aus, Fable berät

Anthropic verwendet dieselbe grundlegende Arbeitsteilung wie mein Vergleich mit Mitarbeiter und Chef. Das Advisor-Tool verbindet ein günstigeres Modell für die Ausführung mit einem stärkeren Modell, das die Richtung vorgeben kann. In der Dokumentation sind Opus 5 der Executor und Fable 5 der Advisor.

Der Advisor kann die laufende Session lesen, einen Plan vorschlagen und die Arbeit während der Aufgabe korrigieren. Deshalb empfiehlt Anthropic ihn für Design, Architektur und Risikobewertung. Er muss mindestens so fähig sein wie der Executor, doch mehr Beratung ist nicht automatisch besser: Zu viele Aufrufe machen die Aufgabe langsamer und teurer, ohne das Ergebnis zu verbessern [20].

Vorgabe

• Du Ziel, Grenzen, Abnahmekriterien

gibt Richtung vor

Richtung

• Fable 5 Architektur, begrenzte Aufgaben

begrenzte Aufgaben

Ausführung

• Opus 5 Code, Tests, Verifikation

Implementierung und Testergebnisse

Prüfung

• Fable 5 Prüfung an Meilensteinen

Diese Aufteilung gibt jedem Modell eine klare Verantwortung. Du definierst Ziel und Grenzen, Fable erstellt den Plan und prüft wichtige Meilensteine, und Opus implementiert die begrenzte Arbeit zu einem niedrigeren Tokenpreis. Ich habe diese Aufteilung seitdem bei großen Multi-Agent-Features eingesetzt und das Ergebnis in meinem Vergleich von Claude und Codex bei großen Features dem von Codex gegenübergestellt.

Der Vergleich hat Grenzen. Anthropic hält Opus nicht für unfähig zur Planung, und Claude Code enthält einen offiziellen opusplan-Modus, in dem Opus plant, während Sonnet ausführt [21]. Auch Fable ist kein perfekter Chef. Anthropics Prompting-Guide warnt, dass es zu viel planen, ungefragt refaktorieren und kleine Aufgaben vergrößern kann; eine Erklärung für den Grund der Änderung hilft ihm, beim Ziel zu bleiben [23].

Trotz dieser Einschränkungen positioniert Anthropic die Modelle unterschiedlich. Das Unternehmen empfiehlt Fable 5, wenn maximale Fähigkeit zählt, und Opus 5 für das bessere Preis-Leistungs-Verhältnis bei komplexen Coding-Agenten [10]. Beim Fable-Launch erklärte Anthropic, dass Fables Vorsprung mit der Länge und Komplexität der Aufgabe wächst [22]. Als Anthropic später das nächste Fable veröffentlichte, habe ich Fable 5.1 und Opus 5 bei langen Agent-Aufgaben und beim Preis verglichen.

Dieselbe Aufteilung zeigt sich in Anthropics Analyse von rund 400.000 Claude-Code-Sessions von etwa 235.000 Nutzern. Menschen trafen ungefähr 70 % der Planungsentscheidungen, Agenten dagegen etwa 80 % der Ausführungsentscheidungen. Bei erfahrenen Nutzern lösten Prompts im Durchschnitt rund 12 Agentenaktionen und 3.200 Wörter aus, bei Einsteigern nur 5 Aktionen und 600 Wörter; die verifizierte Erfolgsquote lag bei Einsteigern um 15 % und ab mittlerer Erfahrung bei 28 % bis 33 % [24]. Auch ein proaktiveres Modell braucht klare Führung.

So würde ich Opus 5 einsetzen: Aufgabe begrenzen und Ergebnis prüfen

Ich würde Opus klar begrenzte Implementierungsarbeit geben und Fable für unklare Richtungsentscheidungen, Architektur und Reviews bei hohem Risiko einsetzen.

Auf Grundlage der verfügbaren Ergebnisse und Nutzerberichte würde ich heute so zwischen den Modellen wählen. Nach mehr eigener Nutzung passe ich die Tabelle vielleicht an. Diese eigene Nutzung steht inzwischen in ob Opus 5 wirklich so schlecht ist, wie es im Internet heißt.

Aufgabe	Modell
Klarer Bug mit Repro und Test	Opus 5
Begrenztes Feature mit Abnahmekriterien	Opus 5
Refactoring auf eine bekannte Zielarchitektur	Opus 5, danach Fable-Review
Unklare Ursache über mehrere Systeme hinweg	Fable plant, dann arbeitet Opus 5
Neue Architektur mit langer Lebensdauer	Zuerst Fable 5
Lange Agentenläufe mit mehreren Arbeitssträngen	Fable 5 als Orchestrator
Hochrisiko-Migration	Fable entwirft, Opus baut, Fable prüft

Bevor ich das Modell wechsle, würde ich die Konfiguration ändern. Lass Thinking aktiviert: Es ist der Standard, niedriger Effort mit Thinking funktioniert bei ähnlichen Kosten besser als ohne, und das Abschalten kann ungewöhnliche Tool-Aufrufe verursachen [8]. Beginne mit einem niedrigen Effort und erhöhe ihn nur, wenn die Aufgabe mehr Denkarbeit braucht, statt standardmäßig xhigh zu verwenden; Artificial Analysis hat einen großen Unterschied zwischen niedrigem und maximalem Effort gemessen [2].

Nutze für einen fairen Vergleich vollständige Modell-IDs, weil sich Aliasse ändern können [21]. Außerdem würde ich vor der Bewertung von Opus 5 alle Anweisungen entfernen, die Probleme von Opus 4.x ausgleichen sollten [8].

Ich würde mit diesem System-Prompt beginnen, statt die alte Anweisung “sei gründlich und proaktiv” zu verwenden:

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

Dieser Prompt macht aus Opus kein Fable, und das soll er auch nicht. Opus 5 ist am stärksten, wenn eine Aufgabe klare Grenzen und Abnahmekriterien hat, denn dort kann es zu einem niedrigeren Tokenpreis hervorragende Arbeit liefern. Bei einem unklaren Ziel kann dieselbe Initiative jedoch zusätzliche Arbeit, selbstbewusste Fehlannahmen und falsche Abschlussmeldungen erzeugen.

Deshalb würde ich Opus als Mitarbeiter und nicht als Chef einsetzen. Fable kann die Richtung derzeit besser festlegen und prüfen, doch das Ziel musst du weiterhin vorgeben.