Claude Opus 5 im Praxiseinsatz: Mit dem Effort-Regler Rechenleistung gezielt dosieren

Claude Opus 5 ist Anthropics Premium-Modell für komplexe Programmieraufgaben, Agenten und den Unternehmenseinsatz. Es erschien am 24. Juli 2026 mit einem klaren Versprechen: ein großer Teil der Leistungsfähigkeit von Fable 5 zum bisherigen Opus-Preis.

Preislich ist der Wechsel von Opus 4.8 unkompliziert. Für den Produktivbetrieb gilt das nicht uneingeschränkt. Thinking ist nun standardmäßig aktiv, der Effort-Wert bestimmt den Arbeitsaufwand über Text und Tools hinweg, und ein altes Ausgabelimit kann eine Aufgabe abbrechen, bevor das Modell seine Überlegungen abgeschlossen hat.

Claude Opus 5 ist das Premium-Modell für den Alltag – nicht das absolute Maximum

Opus 5 passt zu schwieriger Arbeit, die täglich anfällt. Sonnet 5 ist die bessere Wahl, wenn Durchsatz und Latenz im Vordergrund stehen. Fable 5 sollte Aufgaben vorbehalten bleiben, die in einer Opus-Evaluierung bereits gescheitert sind und bei denen die Folgen dieses Fehlers den Tokenaufschlag um den Faktor 2 rechtfertigen.

Diese Hierarchie entspricht auch Anthropics aktueller Positionierung. Der aktuelle Modellleitfaden empfiehlt unentschlossenen Entwicklern, komplexes agentisches Coding und Unternehmensaufgaben zunächst mit Opus 5 anzugehen und erst für die höchstmögliche Leistungsfähigkeit auf Fable 5 zu wechseln.

Opus 5 bietet ein Kontextfenster mit 1 Million Token und eine maximale synchrone Ausgabe von 128,000 Token. Das Kontextfenster umfasst das Material, das ein Modell während einer Anfrage berücksichtigen kann; es garantiert nicht, dass jedes Token gleich viel Aufmerksamkeit erhält. Das Ausgabelimit schließt verborgenes Thinking und die sichtbare Antwort gemeinsam ein – ein wichtiger Punkt bei der Migration.

Die Modell-ID lautet claude-opus-5. Verfügbar ist das Modell über die Claude API, Amazon Bedrock, Google Cloud und Microsoft Foundry. In der Claude-App hat Anthropic es zum Standard für Max und zum leistungsstärksten Modell für Pro gemacht.

Das ist keine Rangfolge für alle Zeiten. Es ist eine Routing-Richtlinie, die auch den nächsten Modellwechsel überstehen kann: Jeder Wechsel beruht auf Ergebnissen aus dem eigenen Workload, nicht auf der Treue zu einer Modellklasse.

Bei Benchmarks zählt der Preis pro erfolgreicher Aufgabe

Das relevante Benchmark-Ergebnis von Opus 5 lautet nicht, dass das Modell überall gewinnt. Entscheidend ist vielmehr, dass es häufig zum gleichen akzeptierten Ergebnis kommt – bei geringeren Kosten pro Durchlauf.

Anthropic veröffentlicht fünf Ergebnisse, die für diese Entscheidung maßgeblich sind:

• Im Frontier-Bench v0.1 erzielt Opus 5 mehr als die doppelte Leistung von Opus 4.8 – bei niedrigeren Kosten pro Aufgabe.
• Im CursorBench 3.2 erreicht Opus 5 mit Effort max ein Ergebnis innerhalb von 0.5% des Fable-5-Spitzenwerts, und das bei halbierten Kosten pro Aufgabe.
• Im ARC-AGI 3 ist der Wert dreimal so hoch wie der des nächstbesten Modells in Anthropics Vergleich.
• Im Zapier AutomationBench liegt die Erfolgsquote bei rund dem 1.5-Fachen des nächstbesten Modells zu denselben Kosten pro Aufgabe. Selbst auf der niedrigsten Effort-Stufe besteht es noch mehr Aufgaben als jedes andere Modell in diesem Vergleich.
• Im OSWorld 2.0 übertrifft es das beste Computer-Use-Ergebnis von Fable 5 zu etwas mehr als einem Drittel der Kosten.

Dabei handelt es sich um vom Anbieter veröffentlichte Einführungsergebnisse, nicht um eine allgemeingültige Bestenliste für jedes Repository, Richtliniendokument oder jeden Browser-Workflow. Sie liefern einen Richtwert dafür, dass zusätzliche Token über den Effort-Regler in akzeptierte Arbeit umgesetzt werden können. Wie viele Wiederholungen der eigene Agent benötigt, wie oft ein Mensch eine Antwort ablehnt oder ob ein schnelleres, etwas schwächeres Ergebnis besser zum Service-Level-Ziel passt, lässt sich daraus nicht ablesen.

Die Kosten pro erfolgreicher Aufgabe erfassen diese fehlenden Faktoren. Dafür werden die Tokenkosten aller Versuche, Gebühren für Tool-Aufrufe, produktrelevante Latenz und menschliche Prüfung addiert. Anschließend wird die Summe durch die Zahl der Ausgaben geteilt, die die eigene Akzeptanzregel erfüllen.

Bei einem Coding-Agenten kann Erfolg bedeuten, dass alle Tests bestehen, der Diff im vereinbarten Umfang bleibt und die Prüfung ohne Korrekturschleife abgeschlossen wird. Bei einem Betriebsagenten könnte die Vorgabe lauten: Datensatz korrekt aktualisiert, richtige Freigabe angefordert und keine unbelegte Aktion ausgeführt. Das Bewertungsschema muss das Ergebnis festlegen, bevor Effort-Stufen verglichen werden.

Nicht die vermeintliche Intelligenz des Modells ist die Kennzahl, sondern das akzeptierte Ergebnis zu bekannten Kosten.

Eine feste Arbeitslast kostet $9, $22.50 oder $45

Bei identischem Tokenprofil liegt Opus 5 genau zwischen dem befristeten Preis von Sonnet 5 und dem von Fable 5.

Als Beispiel dienen 100 Aufgaben. Jede sendet 20,000 Eingabetoken und erhält 5,000 Ausgabetoken. Damit verbraucht das gesamte Aufgabenpaket 2 Millionen Eingabetoken und 500,000 Ausgabetoken:

• Sonnet 5 kostet zum Einführungspreis von $2 für die Eingabe und $10 für die Ausgabe insgesamt $9.
• Opus 5 kostet bei $5 für die Eingabe und $25 für die Ausgabe $22.50.
• Fable 5 kostet bei $10 für die Eingabe und $50 für die Ausgabe $45.

Die Rechnung basiert auf Anthropics aktuellen API-Preisen. Der Tarif von $2/$10 für Sonnet 5 gilt bis zum 31. August 2026; danach beträgt der Standardpreis $3/$15. Nicht eingerechnet sind Prompt-Caching, Batch-Rabatte, Websuche, Codeausführung, Wiederholungen sowie Änderungen des Tokenverbrauchs durch das Modell oder die Effort-Stufe.

In diesem kleinen Maßstab kostet Opus $13.50 mehr als Sonnet, Fable wiederum $22.50 mehr als Opus. Verhindert Opus über das gesamte Aufgabenpaket nur eine Korrektur im Wert von mehr als $13.50, ist der Sonnet-Aufpreis bereits gerechtfertigt. Für den nächsten Schritt zu Fable müssten mehr als $22.50 an Fehler- oder Prüfkosten entfallen.

Bei 10,000 Aufgaben mit demselben Profil steigen die Summen auf $900, $2,250 und $4,500. Opus liegt nun $1,350 über Sonnet; Fable schlägt mit weiteren $2,250 zu Buche. Eine Routing-Entscheidung, die im Prototyp kaum ins Gewicht fällt, wird im Produktivbetrieb zum eigenen Budgetposten.

Fast Mode verdeutlicht den Unterschied. Opus 5 läuft damit etwa 2.5-mal schneller, kostet mit $10/$50 aber das Doppelte. Das Beispiel mit 100 Aufgaben käme auf $45 und damit auf dieselben reinen Tokenkosten wie Fable 5. Der Aufpreis lohnt sich, wenn die kürzere Antwortzeit einen entsprechenden Produktwert hat – nicht als pauschaler Geschwindigkeitsschalter.

Der Effort-Regler ist eine Richtlinie, kein Tokenbudget

Der Ausgangspunkt ist high. Diese Stufe ist der Standard in der Claude API und in Claude Code. Anthropic weist ausdrücklich darauf hin, dass ein gesetztes high genauso wirkt wie ein ausgelassener Effort-Parameter.

Effort steuert, wie viel Arbeit Claude in die gesamte Antwort investiert. Dazu zählen sichtbarer Text, Thinking, Tool-Aufrufe und Funktionsargumente. Eine niedrigere Stufe kann Tokenverbrauch und Tool-Aktivität senken, eine höhere kann eine gründlichere Erkundung ermöglichen. Weil es sich um ein Verhaltenssignal und nicht um eine feste Obergrenze handelt, kann auch eine schwierige Anfrage mit low Thinking auslösen.

Die fünf Stufen erfüllen unterschiedliche Aufgaben:

low eignet sich für günstige, klar begrenzte Arbeit. Dazu gehören Klassifikation, Extraktion, einfache Umformungen und eng umrissene Aufgaben für Subagenten, deren Ergebnis leicht zu prüfen ist. Ein Triage-Agent, der ein Ticket der richtigen Warteschlange zuweist, passt besser als ein Agent, der das Ticket vollständig löst.

medium ist die ausgewogene Stufe für den Produktivbetrieb. Sie passt zu routinemäßiger, toolgestützter Arbeit mit bekanntem Ablauf und wechselnden Eingaben – etwa dem Zusammenfassen eines Kundendatensatzes, dem Entwurf einer Standardantwort oder der Anwendung einer klar definierten Arbeitsanweisung. Wenn Tokenkosten oder Latenz wichtig werden, ist sie der erste Schritt unterhalb des Standards.

high ist der Standard für anspruchsvolle tägliche Arbeit. Dazu zählen Codeänderungen, differenzierte Analysen und mehrstufige Agenten, bei denen Fehler sorgfältiges Denken rechtfertigen. Hier sollte die erste Messung stattfinden, denn alle höheren und niedrigeren Stufen lassen sich damit vergleichen.

xhigh ist für lang laufende Aufgaben gedacht. Anthropic beschreibt diese Stufe für agentische oder Coding-Aufgaben, die länger als 30 Minuten laufen und Tokenbudgets in Millionenhöhe beanspruchen können. Sie passt zu wiederholter Erkundung, zahlreichen Tool-Aufrufen oder Plänen, die über eine lange Ausführung hinweg erhalten bleiben müssen.

max ist die Ausnahmestufe. Sie setzt dem Tokenverbrauch keine Grenzen, um die höchstmögliche Leistungsfähigkeit zu erreichen. Angebracht ist sie erst dann, wenn xhigh scheitert oder der Wert des Ergebnisses wichtiger ist als die Tokeneffizienz.

Zwei Fehler sind besonders naheliegend.

Erstens eignet sich Effort nicht dazu, die Textlänge zu steuern. Laut Anthropics Dokumentation verkürzt eine andere Effort-Stufe die sichtbare Antwort von Opus 5 nicht zuverlässig. Die gewünschte Länge gehört in den Prompt.

Zweitens sollte nicht jede schwierig wirkende Aufgabe direkt mit max beginnen. Dann lässt sich nicht mehr feststellen, ob high ebenfalls bestanden hätte, und jede spätere Kostendiskussion bleibt hypothetisch. Maßgeblich ist die niedrigste Stufe, die das Ziel zuverlässig erreicht – nicht der höchste Wert, den man kaufen kann.

Wer Opus 5, Sonnet 5 oder Fable 5 einsetzen sollte

Für die meisten Käufer ist ein einziges Modell für alle Anfragen die falsche Wahl. Sinnvoller sind ein Standardmodell und ein eng begrenzter Eskalationspfad.

Startup-Gründer mit Finanzierung und einem Agentenprodukt

Sonnet 5 übernimmt Interaktionen mit hohem Volumen, die leicht zu prüfen sind. Opus 5 passt zu Schritten, die planen, widersprüchlichen Kontext abgleichen oder nach einem Tool-Fehler wieder auf Kurs kommen müssen.

Das Risiko besteht darin, Opus vorsichtshalber für jede einzelne Interaktion einzusetzen. Folgen die meisten Anfragen einem vorhersehbaren Ablauf, wird der Aufpreis für Arbeit bezahlt, die ihn nie benötigt hat. Der günstige Pfad sollte breit bleiben, der Opus-Pfad den folgenreichen Schritten vorbehalten sein.

Komplexe Orchestrierung startet mit Opus auf high. Eine bekanntermaßen schwierige Klasse wechselt erst dann auf xhigh, wenn die höhere Akzeptanzquote den zusätzlichen Tokenverbrauch ausgleicht. Eine Aufgabe geht erst an Fable, nachdem Opus an einer repräsentativen Variante gescheitert ist und die geschäftlichen Folgen den um den Faktor 2 höheren Stückpreis rechtfertigen.

CTO im Mittelstand, der die Modellschicht standardisiert

Opus 5 wird zum Premium-Standard, das Modell-Routing bleibt jedoch in der Richtlinie sichtbar. Verantwortliche für einen Workload sollten benennen können, warum eine Aufgabe Sonnet, Opus oder Fable nutzt und welche Evaluierung diesen Pfad ändern würde.

Eine Migration aller Opus-4.8-Anfragen ist nicht damit erledigt, nur einen Modellnamen auszutauschen. Das standardmäßige Thinking verändert Ausgabeverhalten und Tokenverbrauch. Bestehende max_tokens-Werte, der Aufbau zwischengespeicherter Unterhaltungen und Verifizierungs-Prompts müssen ebenfalls geprüft werden.

Die Analyse zu Claude Sonnet 5 liefert die sinnvolle Untergrenze: Sonnet gewinnt, solange die akzeptierte Ausgabe beim aktuellen Preis Bestand hat. Fable markiert die Obergrenze. Dazwischen bleibt Opus der Standardpfad, bis eine der beiden Alternativen bei einem konkret benannten Workload nachweislich besser abschneidet.

Erfahrener Operations-Verantwortlicher, der Geschäftsprozesse automatisiert

Opus passt zu Aufgaben, die System- oder Richtliniengrenzen überschreiten. Eine Anfrage zu lesen, ein Konto zu prüfen, eine Regel anzuwenden und über die notwendige Freigabe durch einen Menschen zu entscheiden, ist anspruchsvoller als eine Zusammenfassung: Jeder Schritt verändert die Folgen des nächsten.

Für stabile Abläufe mit begrenzten Tools reicht medium. Wenn Ausnahmen, uneindeutige Datensätze oder widersprüchliche Richtlinientexte häufig vorkommen, ist high angemessen. Unumkehrbare Aktionen behalten eine menschliche Freigabe, auch wenn die Benchmarks stark ausfallen. Ein besseres Modell senkt den routinemäßigen Prüfaufwand, beseitigt aber nicht die Verantwortlichkeit.

Fable ist nur dann plausibel, wenn die Aufgabe zugleich ungewöhnlich schwierig und ungewöhnlich wertvoll ist. Wird jedes Ergebnis ohnehin von einem Menschen geprüft, kann eine bessere Prüfoberfläche mehr bewirken als der zusätzliche Modellaufschlag.

Technischer Solo-Entwickler

Solange sich die Produktform noch verändert, ist Sonnet 5 der richtige Startpunkt. Schwieriges Debugging, Architekturprüfungen und dateiübergreifende Implementierungen wechseln zu Opus 5. Der Unterschied zahlt sich vor allem dann aus, wenn ein Fehlversuch den Kontext teuer neu aufbauen würde – nicht bei einer kleinen Änderung.

Die breitere Anbieterwahl bleibt davon getrennt. GPT-5.6 und Claude Sonnet 5 unterscheiden sich nicht nur in der Modellqualität, sondern auch in ihren Ausführungssystemen. Opus 5 stärkt Anthropics Premium-Pfad, macht Orchestrierung, Tool-Berechtigungen oder Observability aber nicht austauschbar.

Für alle vier Zielgruppen kippt die Entscheidung am selben Punkt: Ein Upgrade lohnt sich, sobald die gemessenen Fehler- und Prüfkosten den Modellaufschlag übersteigen. Solange niemand diese Kosten gemessen hat, ist eine Evaluierung vor der Eskalation die sichere geschäftliche Entscheidung.

Die Migration von Opus 4.8 bringt zwei Verhaltensbrüche

Der Wechsel von claude-opus-4-8 zu claude-opus-5 behält denselben Stückpreis von $5/$25 bei, aber nicht dasselbe Laufzeitverhalten.

Der erste Bruch ist das standardmäßige Thinking. Opus 4.8 konnte ohne Thinking laufen, sofern es in der Anfrage nicht aktiviert wurde. Opus 5 entscheidet standardmäßig selbst, wann und wie intensiv es denkt. Da max_tokens Thinking und sichtbare Antwort gemeinsam begrenzt, kann ein Limit, das für Opus 4.8 bequem ausreichte, einen Opus-5-Agenten vor Abschluss seiner Arbeit abbrechen.

Der zweite Bruch betrifft das Zusammenspiel von Thinking und Effort. Deaktiviert eine Anfrage Thinking und setzt zugleich xhigh oder max, antwortet die API mit HTTP 400. Muss Thinking deaktiviert bleiben, darf Effort höchstens auf high stehen; alternativ ist bei höheren Effort-Stufen das Feld zum Deaktivieren von Thinking zu entfernen.

Anthropic warnt außerdem, dass Opus 5 bei deaktiviertem Thinking gelegentlich einen Tool-Aufruf als normalen Text ausgeben oder interne XML-Tags offenlegen kann, statt einen korrekten tool_use-Block zu senden. Thinking sollte möglichst aktiv bleiben, während der Verbrauch über Effort gesteuert wird.

Für eine ausgedehnte Coding- oder Agentenaufgabe ist folgende Python-Anfrage gültig:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Das Limit von 64,000 Token ist Anthropics empfohlener Ausgangspunkt für xhigh oder max, keine Vorgabe für jede Anfrage. Nach Beobachtung des tatsächlichen Verbrauchs und Abschlussverhaltens kann es reduziert werden.

Auch qualitative Unterschiede sind zu erwarten. Laut Anthropic schreibt Opus 5 tendenziell längere Ergebnisse, berichtet während Agentensitzungen häufiger über Fortschritte, delegiert eher an Subagenten und überprüft seine Arbeit ohne separate Anweisung. Das kann nützlich sein; eine Agentenoberfläche, Log-Pipeline oder Orchestrierungsschicht, die auf das zurückhaltendere Verhalten von Opus 4.8 ausgelegt ist, muss unter Umständen angepasst werden.

Drei Details im Produktivbetrieb bestimmen die Rechnung

Effort, Caching und Geschwindigkeit beeinflussen einander. Wird nur einer dieser Faktoren isoliert optimiert, können sich die beiden anderen verschlechtern.

Effort innerhalb einer gecachten Unterhaltung konstant halten

Eine Änderung von output_config.effort zwischen Anfragen verändert Anthropics gerenderten Prompt. Die spätere Anfrage behält deshalb das gecachte Präfix nicht bei. Ein System, das Effort innerhalb einer langen Unterhaltung laufend erhöht und senkt, verliert womöglich genau die Cache-Ersparnis, die es erzielen sollte.

Für eine cacheabhängige Sitzung wird zu Beginn eine Effort-Stufe gewählt und beibehalten. Braucht eine spätere Aufgabe eine andere Stufe, gehört sie in eine neue Unterhaltung – oder der Cache-Miss wird als Teil der Eskalationskosten akzeptiert.

Opus 5 senkt die Mindestlänge eines cachefähigen Prompts von 1,024 Token bei Opus 4.8 auf 512 Token. Damit steht Caching auch für kürzere, wiederkehrende Anweisungen zur Verfügung, sofern Prompt-Präfix und Effort stabil bleiben.

Fast Mode für Latenz kaufen, nicht für Leistungsfähigkeit

Fast Mode ist etwa 2.5-mal so schnell wie der Normalbetrieb und kostet $10/$50 pro Million Token. Aus Opus wird dadurch nicht Fable. Im festen Beispiel mit 100 Aufgaben steigen die Opus-Kosten vor Caching oder Wiederholungen von $22.50 auf $45.

Fast Mode ist eine Research Preview in der Claude API. Der Modus ist derzeit nicht über Amazon Bedrock, Google Cloud oder Microsoft Foundry verfügbar. Eine Multi-Cloud-Architektur darf nicht voraussetzen, dass diese Geschwindigkeitseinstellung dem Modell überall folgt.

Die neuen Beta-Steuerungen als Beta behandeln

Tool-Änderungen während einer Unterhaltung erlauben es einer Anwendung, zwischen Turns Tools hinzuzufügen oder zu entfernen und dabei den Prompt-Cache zu erhalten. Das Feature nutzt den Beta-Header mid-conversation-tool-changes-2026-07-01.

Automatische Fallbacks können eine von einem Klassifikator markierte Anfrage an Opus 5 oder Fable 5 an ein von Anthropic empfohlenes Ersatzmodell weiterleiten, statt sie zu blockieren. Standardmäßige und explizite Fallback-Listen nutzen den Beta-Header server-side-fallback-2026-07-01.

Beide Steuerungen lösen betriebliche Probleme. Zugleich verändern sie, was eine einzelne logische Sitzung tun darf und welches Modell möglicherweise antwortet. Berechtigungsänderungen, Fehlerbehandlung und Ausgabequalität müssen getestet werden, bevor sie in einem unumkehrbaren Workflow aktiviert werden.

Vor dem Rollout alle fünf Effort-Stufen testen

Eine Evaluierung mit 375 Durchläufen reicht aus, um aus dem Effort-Regler belastbare Routing-Daten zu gewinnen: 25 repräsentative Aufgaben, fünf Effort-Stufen und drei Wiederholungen jeder Kombination.

Die Wiederholungen sind wichtig, weil ein Agent einen Durchlauf durch Glück bestehen und am nächsten Tool-Pfad scheitern kann. Entscheidender als die Größe ist die Zusammensetzung des Aufgabensatzes. Er sollte gewöhnliche Arbeit, bekannte Randfälle und Fehler umfassen, die zuvor eine menschliche Korrektur erforderten.

Wenn der Produktivbetrieb Prompt-Caching nutzt, darf Effort während dieses Tests nicht innerhalb einer Sitzung variieren. Jede Stufe braucht ein stabiles Unterhaltungsdesign, sonst werden Cache-Misses zur unkontrollierten Variable.

Ein denkbares Ergebnis wäre: medium bewältigt routinemäßige Kontoaufgaben, high ist für Ausnahmebehandlung erforderlich und xhigh verbessert eine eng umrissene Debugging-Klasse. Daraus folgt kein flächendeckender Einsatz von xhigh, sondern drei Routen mit unterschiedlicher Wirtschaftlichkeit.

Dasselbe Verfahren entscheidet, ob Fable 5 seinen Preis verdient. Fable wird nur für jene Opus-Aufgaben getestet, die unter dem Schwellenwert bleiben. Steigert es die Akzeptanz nicht ausreichend, um den Aufpreis von $22.50 im Beispiel mit 100 Aufgaben zu decken, bleibt Opus die richtige Wahl.

Die Sicherheitsgrenze unterscheidet sich von Fable 5

Opus 5 ist bei legitimer Sicherheitsarbeit weniger restriktiv als Fable 5, aber kein uneingeschränktes Cyber-Modell.

Laut Anthropic sollen die Cyber-Klassifikatoren von Opus 5 rund 85% seltener eingreifen als bei Fable 5. Das Modell kann Schwachstellen im Quellcode finden, während Schutzmechanismen das Scannen binärer Programme nach Schwachstellen, Penetrationstests und die Erstellung von Exploits blockieren. Zudem bleibt es bei offensiver Cybersicherheit und biologischer Forschung hinter Mythos 5 zurück.

Diese Grenze ist für Debugging- und Sicherheitsagenten relevant. Eine Quellcodeprüfung kann funktionieren, während ein späterer Schritt zur Exploit-Validierung abgelehnt oder anderweitig geroutet wird. Der Workflow sollte eine Ablehnung als vorgesehenen Zustand behandeln, nicht als unerwarteten Parserfehler.

Über das Cyber Verification Program erhalten berechtigte Unternehmen und Forscher Zugriff auf eine Variante mit weniger Sicherheitsbeschränkungen. Nutzer ohne Sonderzugang sollten einen Produktiv-Workflow erst dann auf diesem Pfad aufbauen, wenn der Zugang bestätigt ist.

Anthropics interne Verhaltensprüfung bewertet das gesamte Fehlverhalten von Opus 5 mit 2.3 – dem niedrigsten Wert unter den jüngeren Modellen. Das ist ein Beleg aus Anthropics eigener Testsuite, aber keine Erlaubnis, Freigaben, Sandboxing oder Tool-Zugriffe nach dem Prinzip der geringsten Rechte zu entfernen.

Die Entscheidung

Claude Opus 5 sollte Opus 4.8 bei neuen Premium-Workloads und nach einer gestuften Migration auch bei den meisten bestehenden ersetzen. Es kostet genauso viel, skaliert über Effort zuverlässiger und nähert sich Fable 5 in mehreren relevanten Evaluierungen an.

Sonnet 5 sollte es dagegen nicht auf jeder Route mit hohem Durchsatz ersetzen, und max sollte nicht zum Standard werden. Der wirtschaftliche Vorteil entsteht durch Routing: Sonnet oder eine niedrigere Effort-Stufe für günstige, akzeptierte Arbeit; Opus high für schwierige Alltagsaufgaben; xhigh für evaluierte Langläufer; Fable nur dort, wo ein Opus-Fehler nachweislich teuer ist.

Der Effort-Regler ist wertvoll, weil er diese Richtlinie explizit macht. Er dient als Evaluierungsvariable, bleibt bei cacheabhängigen Abläufen konstant und verknüpft jede Eskalation mit einem konkret benannten Fehler.

Soll die nächste Modelländerung ebenfalls in eine belastbare Produktentscheidung übersetzt werden? Newsletter abonnieren.