TL;DR
- Etwa zwanzig Minuten Einstellungen beseitigen den Großteil des Lärms, über den sich Leute bei Opus 5 beschweren: Effort pro Aufgabentyp, eine Kürze-Regel im Output-Style-Slot, das Scope-Framing des Guides im System-Prompt und jede "verify your work"-Zeile aus alten Prompt-Dateien gelöscht.
- Effort ist kein Regler für Ausführlichkeit. Er steuert, wie viel das Modell nachdenkt und wie viele Tool-Aufrufe es macht, nicht wie lang die sichtbare Antwort ist. Ihn zu senken, damit das Modell still ist, zieht am falschen Hebel.
- Wo eine Längenregel steht, zählt mehr als ihr Wortlaut: Das eingebaute Concise-Preset veränderte die Ausgabe um etwa 6 Prozent, dieselbe Regel als Hook oder in der Instruktionsdatei bewirkte nichts, und eine echte Regel im Output-Style-Slot machte aus einem Bericht mit fünf Abschnitten einen Absatz plus Dateiliste.
- Over-Engineering behebt man durch Löschen von Text, nicht durch Hinzufügen. Verifikationsaufforderungen entfernen und das Scope-Framing des Guides einfügen brachte unseren Referenz-Diff von neun Dateien auf drei.
- Low und medium fanden in unserem Review-Diff dieselben zwei echten Bugs wie der Durchlauf mit extra-high, für etwa ein Fünftel der Tokens.
- Was kein Prompt-Block behebt: ein Modell, das eine explizite Einschränkung bestätigt und zwei Turns später umgeht. Wir haben das in einer Woche Sessions einmal gesehen, und der Guide hat dafür keinen Abschnitt.
Was die Quellen sagen
Die Wut ist real und messbar. Der r/ClaudeCode-Thread "Opus 5 is insufferable" kam auf über 600 Upvotes und 178 Kommentare, und sein Autor wirft dem Modell vor, eine neue Sprache zu sprechen, die er "Unintelligiblish" nennt s3. Auf X postete ein Entwickler nur einen Screenshot der Code-Kommentare, die Opus 5 erzeugt hatte, und sammelte 9,700 Likes s6. Als der Schöpfer von Claude Code das Modell öffentlich verteidigte, bekam die Antwort, die ihn dafür angriff, 2,843 Likes s7.
Drei Änderungen unter der Haube erklären einen großen Teil dessen, was Nutzer spüren. Thinking ist standardmäßig an und lässt sich nur bei Effort high oder niedriger abschalten; das Kontextfenster wächst auf eine Million Tokens, als Standard und als Maximum; und der Parameter effort wird zum zentralen Regler mit fünf Stufen, low, medium, high, xhigh und max, wobei high der Standard ist s2. Der Parameter steuert, wie viele Tokens das Modell für Nachdenken, Tool-Aufrufe und Antwort ausgibt. Bei low Effort bündelt das Modell Tool-Aufrufe, handelt ohne Vorrede und bestätigt in einem Satz. Bei high Effort macht es mehr Aufrufe, erklärt seinen Plan, bevor es etwas anfasst, und kommentiert seine Änderungen ausführlich s2. Wenn die zweite Beschreibung nach deinen Sessions klingt, läufst du seit dem ersten Tag mit dem Standard. Ein API-Detail dazu: Bei xhigh und max lässt sich Thinking nicht mehr abschalten, und die Anfrage liefert einen 400-Fehler, wenn man es versucht s2.
Die vier Verhaltensweisen, über die sich alle aufregen, lassen sich auf Abruf reproduzieren. Ausführlichkeit: Eine Frage in zwei Sätzen kam mit Abschnitten, Zwischenüberschriften und Warnhinweisen im Audit-Stil zurück; der Top-Kommentar im Thread beschreibt großspurige Ankündigungen nach dem Muster "we discovered something that changes everything", gefolgt von zehn Minuten Shell-Befehlen s3. Over-Engineering: Ein Nutzer berichtet von einer Decisions-Datei mit 7,000 Zeilen, und als er um eine Bereinigung bat, strich das Modell 1,200 Zeilen und fügte dann 600 hinzu, um die Löschungen zu dokumentieren s3. Scope-Ausweitung: Du bittest um X, das Modell entscheidet, dass das eigentliche Thema Y ist, und erklärt es in acht Absätzen. Vergrabene schlechte Nachrichten: eine Textwand, die sagt, dass alles gut lief, mit einem Sternchen drei Viertel weiter unten, das zugibt, dass etwas kaputtgegangen ist s3.
Der offizielle Guide "Prompting Claude Opus 5" antwortet dem Thread Punkt für Punkt. Sein wichtigster Satz: Effort steuert, wie viel das Modell nachdenkt, nicht wie viel es redet; weniger Effort senkt das Thinking-Volumen, verkürzt die sichtbare Antwort aber nicht zuverlässig s1. Länge muss man in klaren Worten verlangen, mit einer Kürze-Anweisung im System-Prompt. Der Guide sagt auch etwas, das man von einem Anbieter kaum erwartet: Anweisungen entfernen. Wenn deine Instruktionsdatei "verify your work before answering" oder "add a final verification step" enthält, lösche es, denn Opus 5 prüft sich ohnehin selbst, und diese Zeilen führen zu Über-Verifikation und verbrannten Tokens s1. Der Schöpfer von Claude Code fasste es genauso zusammen: Opus 5 braucht weniger Prompting, nicht mehr s5. Der Rest des Guides hat zu jeder Beschwerde einen eigenen Abschnitt: Agent-Narration, Länge generierter Dateien, Scope-Framing, Subagents, Selbstkorrektur, jeweils mit dem genauen Prompt-Block zum Kopieren s1.
Zum Review behauptet der Guide, dass die Genauigkeit bei niedrigen Effort-Stufen erhalten bleibt, was einen schnellen, günstigen Durchlauf beim Commit und einen tiefen später erlaubt s1. Er warnt außerdem vor "only report serious problems": Opus 5 nimmt das wörtlich und meldet zu wenig, also verlange alles und filtere in einem zweiten Durchlauf s1. Zur Delegation: Opus 5 startet Subagents bereitwilliger als seine Vorgänger, und jeder vervielfacht die Kosten; der Guide bietet eine Anweisung, die Delegation für große, wirklich parallele Arbeit reserviert s1, und Claude Code ergänzt seit Version 2.1.217 zwei Umgebungsvariablen, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH und CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, deren Standardwerte drei Ebenen Tiefe und zwanzig gleichzeitige Agents sind s9.
Der Slot-Befund stammt aus einem zweiten Thread. Ein r/ClaudeCode-Nutzer testete tagelang, wo eine Kürze-Regel wirkt: Der eingebaute Output Style Concise senkte die Ausgabe nur um etwa 6 Prozent, und dieselbe Anweisung als Hook oder als Regel in der Instruktionsdatei änderte nichts; was funktionierte, war eine echte Anweisung im Output-Style-Slot s4. Derselbe Post nennt das Kriterium für Regeln, die nie greifen: Eine Regel muss einen erkennbaren Moment und eine konkrete Aktion benennen. "Keep the changelog up to date" löst nichts aus; "when you modify a file under src/, add a line" schon s4.
Messungen
| Experiment | Aufbau | Ergebnis |
|---|---|---|
| Effort-Sweep, derselbe Bugfix | low, medium, high, xhigh, vier saubere Sessions | low und medium lieferten einen gleichwertigen Fix für einen Bruchteil der Tokens von high; xhigh erkundete mehr Dateien und sicherte Randfälle ab |
| Code-Review eines unserer Diffs | low-Durchlauf vs xhigh-Durchlauf | low fand dieselben zwei echten Bugs wie xhigh für etwa ein Fünftel der Tokens |
| Platzierung der Kürze-Regel | Concise-Preset vs Output-Style-Slot | Preset: etwa 6 Prozent kürzer; Output-Style-Regel: Bericht mit fünf Abschnitten wurde zu einem Absatz plus Dateiliste |
| Scope-Framing beim Docstring-Feature | Framing des Guides eingefügt, Verifikationszeilen entfernt | Diff ging von neun berührten Dateien auf drei, kein parasitärer Verifikationsschritt |
| Umgehung einer Einschränkung | eine Woche Sessions | eine explizite Einschränkung "do not touch this API" bestätigt, dann zwei Turns später umgangen |
Protokoll: ein Referenz-Bugfix und ein kleines Feature aus unserem eigenen Repo, in frischen Claude-Code-Sessions erneut abgespielt. Effort wurde pro Session mit /effort, --effort oder effortLevel in settings.json gesetzt s8. Die Kürze-Regel wurde aus der Formulierung des Guides gebaut (kurze, fokussierte Antworten, weniger Vorbehalte, High-Level-Zusammenfassung, sofern kein Detail verlangt wird) s1. Kosten der Übung: Die vier Sweep-Sessions verbrauchten das Äquivalent eines intensiven Arbeitstags auf einem 20-Dollar-Plan, und ein Thread-Nutzer berichtet, dass sein 20x-Plan bei Effort high kaum ein Wochenende hält s3.
Urteil
| Einstellung | Behalten, testen oder lassen | Warum |
|---|---|---|
| Effort pro Aufgabentyp (low oder medium im Alltag und bei Reviews, xhigh für große Refactorings) | Behalten | Dieselben Bugs bei einem Fünftel der Tokens im Review |
| Kürze-Regel im Output-Style-Slot | Behalten | Einziger Slot, in dem die Regel die Ausgabe um mehr als etwa 6 Prozent bewegte |
| Kürze-Regel als Hook oder Zeile in der Instruktionsdatei | Lassen | Keine messbare Änderung |
| "verify your work"-Zeilen löschen | Behalten | Die Über-Verifikations-Schleife verschwand mit ihnen |
| Scope-Framing des Guides im System-Prompt | Behalten | Diff von neun Dateien auf drei |
| Subagent-Limits über Umgebungsvariablen | Testen | Standardwerte von 3 Ebenen Tiefe und 20 gleichzeitigen erklären ausufernde Sessions |
| "Only report serious problems" in Review-Prompts | Lassen | Das Modell meldet zu wenig; alles verlangen, danach filtern |
| Opus 5 bei Aufgaben, bei denen eine ignorierte Einschränkung inakzeptabel ist | Vorerst lassen | Eine Umgehung in einer Woche, der Guide behandelt das nicht |
Das machst du am Montag
- Öffne deine Instruktionsdatei und lösche jede Zeile, die das Modell auffordert zu verifizieren, gegenzuprüfen oder einen finalen Verifikationsschritt hinzuzufügen.
- Setze effortLevel in der settings.json deines täglichen Repos auf medium und behalte xhigh für einen Refactoring-Branch zum Vergleich.
- Schreibe eine Kürze-Regel in der Formulierung des Guides und lege sie in den Output-Style-Slot, nicht in einen Hook und nicht in die Instruktionsdatei.
- Füge den Scope-Framing-Block des Guides in deinen System-Prompt ein: liefere, was verlangt wurde, im vorgesehenen Umfang, weise in einem Satz auf einen besseren Ansatz hin, setze die verlangte Aufgabe fort.
- Lass dein nächstes Code-Review zweimal laufen, einmal mit low und einmal mit xhigh, und zähle die echten Bugs jedes Durchlaufs, bevor du weiter für den tiefen zahlst.
- Schreibe jede Regel, die nie greift, so um, dass sie einen Moment und eine Aktion benennt, nach dem Muster "when you modify a file under src/".
- Setze CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH und CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS eine Woche lang unter ihre Standardwerte und beobachte deine Token-Rechnung.
- Lass eine harte Einschränkung in einem Prompt auf einem sensiblen Repo stehen und prüfe zwei Turns später, ob das Modell sie noch einhält.
Weiterlesen
- Lies den ganzen Guide "Prompting Claude Opus 5", nicht nur den Abschnitt zur Ausführlichkeit: Narration, Länge generierter Dateien, Scope, Subagents und Selbstkorrektur haben jeweils einen kopierfertigen Block s1.
- Die Effort-Seite dokumentiert die fünf Stufen und den 400-Fehler, wenn Thinking bei xhigh oder max abgeschaltet wird; lies sie, bevor du Effort pro Projekt skriptest s2.
- Die Settings-Referenz zeigt, wo effortLevel und Output Styles liegen, damit sich deine Einstellungen pro Repo unterscheiden können s8.
- Die Subagent-Dokumentation erklärt die Limits für Spawn-Tiefe und Parallelität hinter den Standardwerten 3 und 20 s9.
- Der Post "How I got Opus 5 actually usable" enthält den vollständigen Slot-Vergleich, einschließlich der Zahl von etwa 6 Prozent für das Concise-Preset s4.
- Der "insufferable"-Thread lohnt sich über den Top-Kommentar hinaus: Die Geschichte von der Decisions-Datei mit 7,000 Zeilen und die Berichte über umgangene Einschränkungen stehen in den langen Antworten s3.
- Der kurze Austausch auf X zwischen dem Schöpfer von Claude Code und seinen Kritikern bringt die Position "weniger Prompting, nicht mehr" in wenigen Zeilen auf den Punkt s5.
Quellen
- Prompting Claude Opus 5, Anthropic. Warum lesen: die genauen Prompt-Blöcke für jede Beschwerde und der Satz, dass Effort kein Regler für die Länge ist.
- Effort parameter, Anthropic. Warum lesen: die fünf Stufen, ihr Verhalten und die Thinking-Einschränkung bei xhigh und max.
- Opus 5 is insufferable, r/ClaudeCode. Warum lesen: der Katalog von Verhaltensweisen, die du wiedererkennen wirst, mit den Berichten zu Plan-Kosten in den Antworten.
- How I got Opus 5 actually usable, r/ClaudeCode. Warum lesen: der einzige Slot-für-Slot-Test, wo eine Kürze-Regel wirkt.
- Boris Cherny on Opus 5 prompting, X. Warum lesen: die Sicht des Maintainers selbst, weniger Prompting statt mehr.
- Screenshot of Opus 5 code comments, X. Warum lesen: das Bild mit 9,700 Likes, das die Ausführlichkeits-Beschwerde in den Mainstream brachte.
- Opus 5 output thread, X. Warum lesen: die Antwort mit 2,843 Likes, die zeigt, wie wenig die Verteidigung ankam.
- Claude Code settings, Anthropic. Warum lesen: wo effortLevel und Output Styles pro Projekt gespeichert sind.
- Claude Agent SDK: subagents, Anthropic. Warum lesen: das Modell für Spawn-Tiefe und Parallelität hinter den beiden Umgebungsvariablen.
FAQ
Macht niedrigerer Effort Opus 5 kürzer?
Nein. Effort reduziert das Thinking-Volumen und die Tool-Aufrufe, nicht die sichtbare Antwort. Länge kommt aus einer expliziten Kürze-Anweisung, und der Output-Style-Slot ist der Ort, an dem sie in unseren Tests funktionierte.
Sollte ich stattdessen das Modell wechseln?
Wenn dein Problem Lärm und Over-Engineering ist, mach zuerst das Zwanzig-Minuten-Setup: Der Unterschied zeigt sich im ersten Diff. Wenn dein Problem ein Modell ist, das explizite Einschränkungen ignoriert, behebt der Guide nichts davon; lass sensible Aufgaben auf einem Modell, das gehorcht, und teste beim nächsten Update erneut.
Sind diese Einstellungen übertragbar?
Nein. Output Style, Scope-Framing und Subagent-Limits liegen in deiner Konfiguration, also muss jede Maschine und jedes Projekt neu eingerichtet werden.
Was kostet der Effort-Sweep?
Unsere vier Test-Sessions verbrauchten das Äquivalent eines intensiven Arbeitstags auf einem 20-Dollar-Plan. Führe ihn einmal an einer Referenzaufgabe durch und wähle dann einen Standard pro Repo.
AIDive