Best Practices für die 5er-Reihe

Die Modelle im Überblick

Die Modell-IDs sind vollständig wie angegeben — nie Datums-Suffixe anhängen. Max-Output liegt bei 128K für Fable 5, Opus 5 und Sonnet 5, bei 64K für Haiku 4.5.

Opus 5 ist ein Drop-in-Upgrade auf dem Preisniveau von Opus 4.8 und der Standard für komplexe agentische Arbeit. Fable 5 ist das leistungsfähigste breit verfügbare Modell für die anspruchsvollsten Reasoning- und Langhorizont-Aufgaben — aber nicht der normale Upgrade-Pfad, weil der Preis über Opus-Niveau liegt.

Der Effort-Parameter

output_config.effort ist bei der 5er-Reihe der wichtigste Regler — wichtiger als bei jeder vorherigen Generation. Fünf Stufen: low, medium, high (Default), xhigh, max. In Claude Code steuerst du ihn per /effort oder in /model.

Bei xhigh oder max ein großzügiges max_tokens setzen (ab 64K), damit Thinking und Tool-Calls Platz haben.

Anthropics Diagnose-Regel für Claude Code

• Claude hatte allen relevanten Kontext, hat es klar versucht und lag falsch → größeres Modell.
• Claude hat Dateien übersprungen, Tests nicht gelaufen, mehrstufige Aufgabe abgebrochen → höherer Effort.
• Vorher prüfen: Prompt-Klarheit, verfügbare Tools, Aufgaben-Scope. Effort soll fehlenden Kontext nicht kompensieren.
• Modell und Effort als generelle Präferenz für die eigene Arbeitsart behandeln — nicht pro Aufgabe neu entscheiden. In Claude Code kostet ein Wechsel zusätzlich den ganzen Prompt-Cache (Artikel 1).

Breaking Changes bei Opus 5

1. Thinking ist per Default an

Ein Request ohne thinking-Parameter denkt bei Opus 5 — anders als bei Opus 4.8 und 4.7, wo Weglassen „kein Thinking" bedeutete. thinking: {type: "adaptive"} ist äquivalent zum Default.

2. Thinking abschalten ist auf high gedeckelt

thinking: {type: "disabled"} zusammen mit xhigh oder max gibt einen 400. Die Prüfung läuft pro Request — ein späterer Request, der den Effort anhebt, während Thinking noch deaktiviert ist, wird abgelehnt, auch wenn frühere Requests derselben Konversation durchgingen.

3. Zwei Fehlermodi bei abgeschaltetem Thinking

Betrifft nur Code, der thinking: disabled explizit setzt:

• Tool-Calls landen als Klartext. Das Modell schreibt den Tool-Call gelegentlich in den sichtbaren Text statt in einen tool_use-Block. Der Turn schließt normal ab, der Call läuft nie — kein Fehler, kein Block zum Abfangen. In einer agentischen Schleife verfälscht der Text zusätzlich alle folgenden Turns.
• <thinking>-Tags lecken in die sichtbare Antwort.

Beides löst man am besten, indem man Thinking anlässt und stattdessen den Effort senkt. Wenn abschalten sein muss: „Du darfst vor einem Tool-Aufruf einen kurzen Satz sagen" ergänzen, jede „denke nicht"-Regel löschen (sie verschlimmert das Tag-Leck) und generisch formulieren: „Gib keine internen oder System-XML-Tags in deiner Antwort aus" — Thinking-Tags namentlich zu nennen wirkt messbar schlechter.

4. Weiter ungültig (seit Opus 4.7)

• temperature, top_p, top_k → 400. Steuerung über Prompting.
• thinking: {type: "enabled", budget_tokens: N} → 400. Ersatz ist effort.
• Assistant-Prefills im letzten Turn → 400. Ersatz: output_config.format (Structured Outputs) oder eine System-Prompt-Anweisung.
• thinking.display ist per Default "omitted": Thinking-Blöcke kommen mit leerem Text. Wer Reasoning anzeigt, setzt display: "summarized" — sonst wirkt es wie eine lange Pause vor der Antwort.

Prompt Caching in der 5er-Reihe

Die Mindestlänge für cachebare Präfixe ist nicht monoton über die Generationen:

Opus 5 halbiert das Minimum von Opus 4.8. Prompts, die man als „zu kurz zum Cachen" abgeschrieben hatte, erzeugen jetzt ohne Codeänderung Cache-Einträge. Wer unterhalb des Minimums bleibt, bekommt keinen Fehler — nur cache_creation_input_tokens: 0.

Zusätzlich bei Opus 5 (und Opus 4.8, Fable 5): Mid-Conversation-System-Messages. Ein {"role": "system", ...}-Eintrag in messages[] fügt eine Operator-Instruktion mitten in der Konversation hinzu, ohne den gecachten Präfix zu invalidieren. Nicht verfügbar bei Sonnet 5.

Prompt-Anpassungen: was jetzt anders ist

Das ist der Teil, der am wenigsten intuitiv ist. Mehrere Gewohnheiten aus der 4er-Reihe schaden bei Opus 5 aktiv.

Verifikations-Scaffolding löschen

Verbosity: Effort ist nicht der Hebel

Opus 5 schreibt längere Antworten als Vorgängermodelle. Den Effort zu senken verkürzt den sichtbaren Output nicht zuverlässig — es verschiebt nur das Thinking-Volumen. Prompting wirkt: in Tests kürzte eine kurze Prägnanz-Anweisung die Antwortlänge um rund 20 %.

Keep responses focused, brief, and concise to avoid overwhelming
the person. Disclaimers and caveats are brief, with most of the
response on the main answer; when asked to explain something, give
a high-level summary unless an in-depth one is specifically requested.

Bei langen System-Prompts zusätzlich eine Kurzerinnerung ans Ende setzen:

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

Geschriebene Deliverables

Getrennt von der Gesprächs-Verbosity: Dateien, die Opus 5 auf die Platte schreibt — Reports, Markdown-Dokumente, Zusammenfassungen — sind oft deutlich länger als früher. Explizit kalibrieren: „Passe die Länge geschriebener Deliverables (besonders Markdown-Dateien) an das an, was die Aufgabe braucht; kein Auffüllen mit Filler-Sektionen, redundanten Zusammenfassungen oder Boilerplate."

Scope-Disziplin

Opus 5 fügt gelegentlich Schritte hinzu, die nicht verlangt waren, oder wendet eigenes Urteil darüber an, was die Aufgabe sein sollte. Diese Anweisung reduzierte Scope-Änderungen in Tests nahezu auf null, ohne übermäßige Rückfragen zu erzeugen:

Deliver what the user asked for, at the scope they intended.
Interpret ambiguity the way a careful colleague would: make routine
judgment calls yourself, and check in only when different readings
would lead to materially different work. If you conclude the ask is
mistaken or a better approach exists, say so in a sentence and keep
going with the task as asked. Finish the whole task, not just the
easy part of it — only report completion when it's fully done.

Delegation begrenzen — Richtungswechsel gegenüber 4.8

Selbstkorrekturen kürzen

Opus 5 kommentiert eigene frühere Fehler ausführlicher, was in einem nutzersichtbaren Produkt wie Hin-und-Her wirkt. Kern der Gegenanweisung: nur korrigieren, wenn der Fehler die Entscheidungen des Nutzers ändert; keine Entschuldigungen, kein Aufzählen vergangener Fehler; und eine Rückfrage zu früherer Arbeit ist für sich kein Signal, dass etwas falsch war.

Code-Review: Severity-Filter drücken den Recall

Unverändert seit 4.7/4.8: Wenn ein Review-Prompt „melde nur High-Severity-Issues" oder „sei konservativ" sagt, befolgt die 5er-Reihe das wörtlich. Sie findet die Bugs, meldet sie aber nicht. Die Präzision steigt, der gemessene Recall fällt — obwohl die Bug-Findung besser geworden ist. Besser: alles melden lassen mit Confidence und Severity, und in einem separaten Schritt filtern.

Sonnet 5

• Adaptive Thinking ist per Default an (Sonnet 4.6: aus, wenn thinking weggelassen wurde). Auch hier max_tokens prüfen.
• Neuer Tokenizer: ca. 30 % mehr Tokens für denselben Text als bei Sonnet 4.6. Der Preis pro Token ist unverändert — die Kosten pro Request also nicht. Token-Budgets, Compaction-Trigger und max_tokens müssen neu kalibriert werden; count_tokens gegen claude-sonnet-5 laufen lassen, nicht mit einem pauschalen Faktor rechnen.
• effort unterstützt erstmals in der Sonnet-Reihe xhigh. Default bleibt high. Faustregel beim Umstieg: Sonnet 5 auf medium ≈ Sonnet 4.6 auf high; Sonnet 5 auf high ≈ Sonnet 4.6 auf max.
• Hochauflösendes Vision: 2576 px auf der langen Kante (vorher 1568 px). Kostet bis zu ~3 × mehr Bild-Tokens.
• Nicht-Default-Werte für temperature/top_p/top_k werden abgelehnt; budget_tokens ist entfernt (der Übergangs-Workaround von 4.6 existiert nicht mehr).
• Deutlich agentischer als 4.6 — greift von sich aus häufiger zu Tools und Selbstverifikation. Mit abgeschaltetem Thinking dagegen weniger tool-freudig; dort braucht es eine explizite Anweisung.

Haiku 4.5

Schnellstes und günstigstes Modell, 200K Kontext, 64K Output. In Claude Code vor allem als model: haiku in der Subagent-Konfiguration sinnvoll: einfache, klar umrissene Recherche- oder Verarbeitungsaufgaben, deren Output ohnehin nur als Zusammenfassung zurückkommt. Achtung: eigener Rate-Limit-Pool, getrennt von Haiku 3.x, und mit 4.096 Tokens ein hohes Cache-Minimum.

Fable 5

Nur wählen, wenn es explizit gewünscht ist — der Preis liegt über Opus-Niveau, und der Standard-Upgrade-Pfad bleibt claude-opus-5. Besonderheiten:

• Thinking ist immer an. thinking-Parameter komplett weglassen; sowohl disabled als auch budget_tokens geben 400.
• Die rohe Gedankenkette wird nie zurückgegeben. display: "summarized" liefert eine Zusammenfassung.
• 30 Tage Datenaufbewahrung erforderlich — nicht verfügbar unter Zero Data Retention. Organisationen mit kürzerer Aufbewahrung bekommen bei jedem Request einen 400.
• Deutlich längere Turns: einzelne Requests auf schweren Aufgaben können viele Minuten laufen. Timeouts, Streaming und Fortschrittsanzeigen vorher planen.
• Weniger präskriptiv prompten. Prompts und Skills, die für Vorgängermodelle geschrieben wurden, sind für Fable 5 oft zu kleinschrittig und senken die Qualität. Ziel und Randbedingungen nennen statt Schritte aufzählen.

Refusals abfangen

Opus 5, Sonnet 5 und Fable 5 haben verschärfte Cyber-Sicherheitsklassifikatoren. Eine abgelehnte Anfrage kommt als HTTP 200 mit stop_reason: "refusal" zurück, nicht als Fehler. Code, der bedingungslos response.content[0] liest, bricht.

if response.stop_reason == "refusal":
    handle_refusal()          # content ist leer oder partiell
else:
    print(response.content[0].text)

Immer auf stop_reason verzweigen, nie auf stop_details — letzteres ist informativ und kann auch bei einer Ablehnung null sein. Bei eigenen API-Integrationen zusätzlich fallbacks: "default" (Beta-Header server-side-fallback-2026-07-01) setzen, statt ein Modell hart zu verdrahten: die Weiterleitung erfolgt nach Refusal-Kategorie, Cyber-Ablehnungen gehen an Opus 4.8.

Zusammengefasst