Opus 5 Migration, wenn Denken plötzlich der Standard ist

Opus 5 ist am 24. Juli 2026 erschienen. Wenn Du die 4.8-Migration gemacht hast, erinnerst Du Dich an ein entspanntes Playbook: model-Feld tauschen, fertig, null Breaking Changes. Diesmal ist es anders. Der Namenswechsel ist immer noch eine Zeile, aber dahinter stehen zwei echte Verhaltensänderungen, von denen eine als harter 400-Error zurückkommt, und eine dritte, die Deine bestehenden Prompts schlechter macht statt besser.

Das Gute vorweg: der Preis bleibt bei 5 Dollar pro Million Input-Tokens und 25 Dollar Output, exakt wie 4.8. Du zahlst für ein deutlich stärkeres Modell dasselbe. Dieser Playbook ist für Dich, wenn Du API-Code hast, Claude Code als Daily Driver nutzt, oder Agenten betreibst, die bisher auf 4.8 liefen.

Schritt 1, der Namenswechsel

Such den model-String in Deiner Codebase und tausch ihn.

grep -rn "claude-opus-4-8" src/
# jeden Treffer auf claude-opus-5 umstellen

Die ID heißt claude-opus-5, ohne Datums-Suffix, gleiches Schema wie claude-opus-4-8 und claude-sonnet-5. Eine Sache ist neu: es gibt keine separate 1M-Variante mehr. Bei 4.8 musstest Du claude-opus-4-8[1m] schreiben, wenn Du das große Kontextfenster wolltest. Bei Opus 5 ist 1 Million Token gleichzeitig Default und Maximum, es gibt schlicht nichts Kleineres. Wenn Du irgendwo eine [1m]-Schreibweise stehen hast, fliegt die raus.

Maximale Ausgabe sind 128k Tokens. Verfügbar ist das Modell auf der Claude API, in Amazon Bedrock (als anthropic.claude-opus-5), auf Google Cloud und in Microsoft Foundry. Opus 4.8 bleibt überall erreichbar, Du wirst also nicht zwangsmigriert.

In Claude Code brauchst Du mindestens v2.1.219. Auf Max, Team Premium, Enterprise pay-as-you-go und der API ist Opus 5 bereits der Default-Opus. Wenn Deine Version älter ist, läuft claude update und danach /model zur Kontrolle.

Schritt 2, Thinking läuft jetzt immer mit

Das ist die eigentliche Migration, und sie passiert ohne dass Du eine Zeile änderst.

Auf Opus 4.8 lief eine Anfrage ohne Thinking, solange Du nicht ausdrücklich thinking: {"type": "adaptive"} gesetzt hast. Auf Opus 5 läuft dieselbe Anfrage mit Thinking. Das Modell entscheidet selbst, wann und wie tief es nachdenkt, gesteuert über den effort-Parameter. Der alte Wert bleibt gültig, thinking: {"type": "adaptive"} ist jetzt einfach identisch mit dem Default.

Der Haken hängt woanders: max_tokens ist eine harte Obergrenze für die gesamte Ausgabe, also Denken plus sichtbare Antwort. Denk-Tokens sind nicht von diesem Limit ausgenommen. Wenn Du auf 4.8 mit max_tokens: 16000 gefahren bist und das ohne Thinking gereicht hat, teilen sich jetzt zwei Verbraucher dasselbe Budget. Im schlimmsten Fall denkt das Modell und die Antwort wird abgeschnitten.

# Opus 4.8, lief ohne Thinking
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    messages=[{"role": "user", "content": "..."}],
)

# Opus 5, gleiche Anfrage, Thinking laeuft mit
# und zaehlt gegen dieselben 16000
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[{"role": "user", "content": "..."}],
)

Geh Deine Workloads durch, die bisher ohne Thinking liefen, und zieh max_tokens hoch. Als Faustzahl kalkuliere 30 bis 50 Prozent über dem, was Du bisher an reiner Antwort gebraucht hast, und miss danach nach statt zu raten.

Schritt 3, der 400er den Du kennen musst

thinking: {"type": "disabled"} gibt es weiterhin, aber nur noch bis effort-Level high. Kombinierst Du es mit xhigh oder max, kommt ein 400-Error zurück. Auf Opus 4.8 waren das noch zwei unabhängige Schalter, hier ist es einer.

Das ist der Grund, warum diese Migration nicht blind durchläuft. Wenn Du irgendwo Thinking abschaltest und gleichzeitig hohen Effort fährst, bricht der Request. Nicht subtil, nicht langsamer, sondern sofort.

Zwei saubere Auswege. Entweder Du lässt Thinking aus und gehst mit dem Effort auf high oder darunter. Oder Du behältst den hohen Effort und nimmst das thinking-Feld einfach raus, dann greift der Default.

# Wird abgelehnt
thinking={"type": "disabled"},
output_config={"effort": "xhigh"},

# Variante A, Thinking bleibt aus, Effort runter
thinking={"type": "disabled"},
output_config={"effort": "high"},

# Variante B, Effort bleibt hoch, thinking-Feld weg
output_config={"effort": "xhigh"},

Anthropic empfiehlt Variante B, und dafür gibt es einen praktischen Grund. Mit abgeschaltetem Thinking schreibt Opus 5 gelegentlich einen Tool-Call als normalen Text in die Antwort, statt einen sauberen tool_use-Block zu senden, oder es rutschen interne XML-Tags in die sichtbare Ausgabe. Wenn Deine Pipeline Tool-Calls parst, ist das genau die Klasse Fehler, die Du erst in Produktion merkst. Thinking anlassen und die Kosten über einen niedrigeren Effort steuern ist der stabilere Weg.

Schritt 4, Effort ist der neue Hauptschalter

Die Leiter ist vollständig: low, medium, high, xhigh, max. Default ist high. Neu ist, wie viel das ausmacht. Opus 5 setzt zusätzlichen Effort zuverlässiger in bessere Ergebnisse um als jedes Opus davor, das heißt die Stufe die Du wählst wiegt schwerer als früher.

Anthropic rät: bei high anfangen und in beide Richtungen anpassen, je nach Deinen eigenen Evals. Runter wo die Qualität hält, das spart Tokens und Latenz. Hoch für die wirklich harten Sachen. Wenn Du auf xhigh oder max gehst, setz max_tokens großzügig, 64k ist ein brauchbarer Startwert, damit das Modell Platz zum Denken und Arbeiten über mehrere Tool-Calls hat.

Eine Falle speziell für Claude Code, die leicht zu übersehen ist. Bei Fable 5, Opus 4.8 und Opus 4.7 setzt Claude Code beim ersten Start den modelleigenen Default-Effort durch, auch wenn Du für ein anderes Modell mal etwas anderes eingestellt hattest. Opus 5 macht das nicht. Ein Level, den Du früher gesetzt hast, wird übernommen. Wenn Du also vor Monaten mal /effort low gefahren hast und es vergessen hast, läuft Dein Opus 5 auf low, und Du wunderst Dich, warum das gefeierte Modell so flach antwortet. Einmal /effort tippen und nachsehen kostet fünf Sekunden.

Schritt 5, den Verifikations-Satz aus Deinen Prompts löschen

Das ist der Punkt, den die meisten übersehen, weil er nichts mit der API zu tun hat.

Opus 5 prüft seine eigene Arbeit von sich aus nach, ohne dass Du es verlangst. Anthropic sagt dazu ausdrücklich: nimm Verifikations-Anweisungen raus, die Du für ältere Modelle geschrieben hast. Sätze wie "füge einen abschließenden Verifikations-Schritt hinzu" oder "nutze einen Subagenten zum Prüfen" waren auf 4.8 sinnvoll und führen auf Opus 5 zu Über-Verifikation. Das Modell prüft dann doppelt, verbraucht mehr Tokens und wird langsamer, ohne besser zu werden.

Such in Deinen System-Prompts, CLAUDE.md-Dateien und Agent-Definitionen nach genau diesen Formulierungen und streich sie. Es ist der seltene Fall, wo weniger Prompt messbar mehr Ergebnis bringt.

Drei weitere Verhaltensänderungen, die Du ohne Code-Änderung merken wirst. Antworten und geschriebene Deliverables fallen länger aus als bei 4.8. In agentischen Sessions erzählt das Modell öfter, was es gerade tut. Und in Multi-Agent-Setups delegiert es bereitwilliger an Subagenten. Nichts davon ist ein Fehler, aber wenn Deine Pipeline auf kurze Antworten oder eine bestimmte Ausgabeform baut, lauf einmal Deine wichtigsten Pfade durch.

Schritt 6, die kleineren Neuerungen

Das Prompt-Cache-Minimum sinkt von 1.024 auf 512 Tokens. Prompts, die auf 4.8 zu kurz zum Cachen waren, erzeugen jetzt Cache-Einträge, ohne dass Du irgendwas änderst. Wenn Du viele kurze, wiederkehrende System-Prompts fährst, ist das stille Ersparnis.

Fast Mode gibt es auch für Opus 5, als Research Preview und nur auf der Claude API, nicht auf Bedrock, Google Cloud oder Microsoft Foundry. Preis 10 Dollar Input, 50 Dollar Output pro Million, also der doppelte Standardpreis für ungefähr die zweieinhalbfache Geschwindigkeit. Gleiche Rechnung wie bei 4.8: lohnt nur, wo Latenz echtes Geld oder echte UX kostet.

Zwei Beta-Features, falls Du sie brauchst. Tool-Listen lassen sich jetzt mitten im Gespräch ändern, ohne den Prompt-Cache zu verlieren, per Beta-Header mid-conversation-tool-changes-2026-07-01. Und der fallbacks-Parameter kennt einen neuen "default"-Modus, der Anthropics empfohlene Fallback-Modelle nutzt, statt dass Du selbst eine Liste pflegst, per Header server-side-fallback-2026-07-01.

Was auf Opus 5 nicht geht

Manuelles Extended Thinking mit budget_tokens gibt es nicht mehr, nur noch adaptives Thinking über den effort-Parameter. Prefill über eine vorbereitete Assistant-Nachricht wird nicht unterstützt, dafür nimmst Du Anweisungen im System-Prompt. Das Web-Fetch-Tool ist nicht verfügbar. Priority Tier gibt es für Opus 5 nicht, Opus 4.8 behält es. Und wie schon auf 4.8 werfen temperature, top_p und top_k einen 400er, sobald Du sie auf etwas anderes als den Default setzt, die gehören komplett raus.

Migrations-Checkliste, sieben Punkte

Eins, model-Feld von claude-opus-4-8 auf claude-opus-5 umstellen und dabei jede [1m]-Schreibweise entfernen.

Zwei, alle Workloads finden, die bisher ohne thinking-Feld liefen, und max_tokens hochziehen, weil Denk-Tokens jetzt mitzählen.

Drei, nach der Kombination thinking: {"type": "disabled"} plus Effort xhigh oder max suchen und auflösen, sonst 400.

Vier, temperature, top_p, top_k aus allen Requests entfernen, falls noch nicht geschehen.

Fünf, Verifikations-Anweisungen aus System-Prompts und Agent-Definitionen streichen, sie erzeugen jetzt Über-Verifikation.

Sechs, in Claude Code auf mindestens v2.1.219 gehen und einmal /effort prüfen, weil Opus 5 einen alten Level übernimmt statt den Default zu setzen.

Sieben, Kosten und Latenz auf Deinen echten Workloads neu messen. Die Effort-Stufen von 4.8 sind kein guter Ausgangspunkt mehr.

Sollst Du migrieren

Ja. Gleicher Preis, deutlich stärkeres Modell, und Opus 4.8 bleibt als Rückweg verfügbar. Die Verbesserungen liegen genau dort, wo Agent-Betrieb wehtut: langes Durchhalten über viele Tool-Calls, mehrstufiges Reasoning, Code-Review mit wenig Fehlalarmen, und Koordination mehrerer Subagenten ohne dass sie sich gegenseitig überschreiben.

Aber wink sie nicht durch. Die drei Sachen, die Dich wirklich treffen können, sind max_tokens das jetzt Denken mitzählt, der 400er bei abgeschaltetem Thinking mit hohem Effort, und die alten Verifikations-Sätze in Deinen Prompts. Alle drei findest Du in zehn Minuten mit grep.

Was als nächstes

Wenn Du von 4.7 oder früher kommst, mach zuerst die Opus 4.8 Migration und davor die Opus 4.7 Migration, da liegen die alten Breaking Changes. Wenn Du wissen willst, wie Du Modell-Releases überhaupt mitbekommst, statt sie zufällig zu entdecken, zeigt Modell-Verfügbarkeit tracken den Aufbau. Für die Kostenseite der neuen Effort-Leiter hat Claude Code Cost-Controls für Daily Driver den Mess-Workflow. Und bevor Du eine Migration produktiv nimmst, baust Du Dir am besten einen kleinen Testsatz, dafür gibt es Agent-Eval in 60 Minuten.

Source

• Anthropic, Claude Opus 5: https://www.anthropic.com/news/claude-opus-5
• What's new in Claude Opus 5: https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
• Migration Guide: https://platform.claude.com/docs/en/about-claude/models/migration-guide
• Prompting Claude Opus 5: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
• Claude Code Model Configuration: https://code.claude.com/docs/en/model-config