Richtig prompten in Claude Code: Effort-Level, Verifikations-Loops und was Sie aus Ihren Prompts löschen sollten

Wer in Claude Code konstant gute Ergebnisse will, dreht nicht an der Formulierung des Prompts, sondern an drei Dingen: dem Effort-Level, dem Kontext und einer Prüfung, die das Modell selbst ausführen kann. Überdenkt Opus 5 eine lange, komplexe Aufgabe, ist die Lösung meistens kontraintuitiv – nicht mehr Nachdenken, sondern weniger: dieselbe Aufgabe auf «medium» oder «low» Effort lösen lassen.

Seit dem Release von Opus 5 tauchen dieselben Fragen immer wieder auf: Warum performt das Modell schlechter als sein Vorgänger? Warum ist es so langsam? Warum überdenkt es einfache Dinge? Und warum wurde Claude Code eigentlich langsamer? Für jede dieser Fragen gibt es eine belegbare Antwort – und in fast allen Fällen liegt die Ursache nicht im Modell, sondern in Prompts, Konfigurationen und Gewohnheiten, die aus der Zeit älterer Modelle stammen. Dieser Artikel ordnet die Ursachen und beschreibt das Setup, mit dem wir selbst arbeiten.

Was hat sich mit Claude Opus 5 konkret geändert?

Opus 5 ist kein inkrementelles Update, und mehrere Änderungen wirken direkt darauf, wie Prompts wirken:

Die wichtigste Konsequenz steht in Anthropics eigener Dokumentation: Opus 5 setzt zusätzlichen Effort zuverlässiger in bessere Ergebnisse um als jedes frühere Opus-Modell – weshalb die gewählte Stufe mehr Gewicht hat als früher, in beide Richtungen.

Warum performt Opus 5 schlechter als das Vorgängermodell?

Weil viele Prompts noch für ein Modell geschrieben sind, das es nicht mehr gibt. Die folgenden fünf Muster waren bei Opus 4.x hilfreich und sind bei Opus 5 aktiv schädlich:

Dazu kommt ein Verhalten, das schnell wie «schlechtere Qualität» aussieht: Scope-Erweiterung. Opus 5 fügt Schritte hinzu, die nicht verlangt waren, und wendet eigenes Urteil darüber an, was die Aufgabe eigentlich sein sollte. Bei eng gefassten Aufgaben ist das kein Feature, sondern ein Diff, den niemand reviewen wollte. Die Gegenmassnahme ist eine explizite Scope-Regel im Prompt oder in CLAUDE.md:

Liefere, was verlangt wurde, im verlangten Umfang. Triff Routine-
Entscheidungen selbst und frage nur nach, wenn unterschiedliche
Lesarten zu materiell anderer Arbeit führen würden. Wenn ein
besserer Weg existiert, sag es in einem Satz und mach dann
trotzdem das, was verlangt wurde.

Überdenkt Opus 5 – und was hilft dagegen?

Ja. Und der wirksamste Gegenzug ist, die Aufgabe auf einer niedrigeren Stufe zu lösen.

Das Muster ist gut dokumentiert: Bei langen, komplexen Aufgaben und hohen Effort-Stufen beginnt das Modell, offensichtlich korrekte Lösungswege zu hinterfragen, zusätzliche Refactorings anzustossen und Änderungen ausserhalb des vergebenen Scopes vorzunehmen. Anthropic beschreibt für die Vorgängermodelle bereits, dass max bei strukturierten oder weniger intelligenzsensitiven Aufgaben zu Überdenken führen kann; unabhängige Benchmarks berichten für Opus 5 bei Coding-Aufgaben ein Leistungsoptimum im mittleren Effort-Bereich, mit abnehmenden bis negativen Erträgen darüber.

Die Praxisregel: Wenn Opus 5 bei einer langen, komplexen Aufgabe überdenkt, lösen Sie dieselbe Aufgabe auf medium oder low. Das ist kein Qualitätsverzicht, sondern häufig eine Qualitätssteigerung – und spart nebenbei einen erheblichen Teil der Tokens und der Wartezeit.

Zwei Details, die regelmässig für Verwirrung sorgen:

1. Effort ist ein Verhaltenssignal, kein Token-Budget. Auch auf low denkt das Modell bei ausreichend schweren Problemen – nur weniger tief als auf high.
2. Effort steuert nicht die Antwortlänge. Auf Opus 5 verkürzt ein niedrigeres Effort-Level die sichtbare Antwort nicht zuverlässig. Wer kürzere Antworten will, muss sie verlangen: «Halte Antworten fokussiert und knapp. Halte Disclaimer kurz und verwende den Grossteil der Antwort auf die eigentliche Sache.»

Ein dritter Punkt betrifft alle, die aus Kostengründen Thinking abschalten wollen: Bei Opus 5 geht das nur bis Effort high, und mit abgeschaltetem Thinking treten gelegentlich Artefakte auf – Tool-Calls, die als Text statt als strukturierter Aufruf erscheinen, oder interne XML-Tags in der sichtbaren Antwort. Thinking aktiviert auf low schlägt Thinking deaktiviert bei vergleichbaren Kosten.

Warum ist Opus 5 so langsam?

Die Frage ist berechtigt, hat aber selten eine einzige Ursache. In der Reihenfolge ihrer Häufigkeit:

1. Effort steht auf high oder xhigh, obwohl medium reichen würde. Der grösste und am schnellsten wirksame Hebel. In Claude Code über /effort umschaltbar.
2. Der Kontext ist voll. Das Kontextfenster enthält jede Nachricht, jedes gelesene File und jede Kommandoausgabe. Die Leistung sinkt, während es sich füllt – das Modell «vergisst» frühere Anweisungen und macht mehr Fehler. /clear zwischen unabhängigen Aufgaben, /compact <fokus> an Zwischenständen.
3. Recherche läuft im Hauptkontext statt in Subagenten. Eine breite Codebasis-Untersuchung liest Dutzende Files – alle landen in Ihrem Kontext. Subagenten haben ein eigenes Kontextfenster und melden nur die Zusammenfassung zurück.
4. Zu viele MCP-Server und Tools sind aktiv. Jedes Tool-Schema kostet Kontext bei jedem Turn.
5. Ungefragte Subagenten-Delegation. Opus 5 delegiert bereitwillig; bei kleinen Aufgaben vervielfacht das Kosten und Zeit. Eine Regel in CLAUDE.md hilft: nur delegieren, wenn die Teilaufgabe gross und wirklich unabhängig ist, und niemals zur Selbstprüfung.
6. Veraltete Version oder Plattform-Störung. claude --version und claude update, dann /doctor, dann die Statusseite.

Warum wurde Claude Code langsamer und schlechter?

Für die Phase März bis April 2026 gibt es dazu eine offizielle, ungewöhnlich transparente Antwort. Anthropic hat in einem Postmortem vom 23. April 2026 drei unabhängige Produkt-Änderungen offengelegt, die sich überlagerten und je einen anderen Teil des Traffics trafen:

• 4. März: Der Default für den Reasoning-Effort in Claude Code wurde von high auf medium gesenkt – als Reaktion auf sehr lange Denkzeiten, bei denen die Oberfläche eingefroren wirkte. Anthropic bezeichnete das später als falschen Trade-off und machte es rückgängig.
• 26. März: Eine Änderung sollte ältere Gedankengänge aus über eine Stunde inaktiven Sessions einmalig entfernen. Ein Bug führte dazu, dass das für den Rest der Session in jedem Turn passierte – Claude wirkte vergesslich und wiederholte sich. Behoben am 10. April.
• 16. April: Ein Verbosity-Limit im System-Prompt («Text zwischen Tool-Calls maximal 25 Wörter», «finale Antworten maximal 100 Wörter»). Ablationen während der Untersuchung zeigten rund 3 % Qualitätsverlust. Zurückgenommen am 20. April.

Modellgewichte und API-Schicht waren nicht betroffen. Für die Praxis steckt darin eine Lektion, die weit über den Vorfall hinausreicht: Harte Kürzungsvorgaben im System-Prompt kosten Qualität. Wenn Anthropics eigenes Verbosity-Limit messbar geschadet hat, gilt dasselbe für dieselbe Anweisung in Ihrer CLAUDE.md. Steuern Sie Länge über Stil-Wünsche («fokussiert und knapp»), nicht über harte Wortobergrenzen für die Arbeit selbst.

Wie sieht ein guter Prompt in Claude Code aus?

Der grösste Unterschied liegt nicht in der Formulierung, sondern in der Menge an brauchbarem Kontext und einem prüfbaren Zielzustand:

Für grössere Vorhaben gilt die Reihenfolge Explore → Plan → Code → Commit: erst im Plan-Modus lesen und verstehen lassen, dann einen Plan schreiben lassen, dann implementieren. Bei kleinen, klar umrissenen Änderungen ist der Plan-Modus reiner Overhead – wenn Sie den Diff in einem Satz beschreiben können, überspringen Sie ihn.

Opus 5 spielt seine Stärke besonders dann aus, wenn es die vollständige Aufgabenspezifikation vorab bekommt und dann laufen darf. Für grössere Features lohnt sich deshalb ein zweistufiges Vorgehen: In einer ersten Session lassen Sie sich befragen («Interviewe mich im Detail zu technischer Umsetzung, UX, Edge Cases und Trade-offs, dann schreib eine vollständige Spec nach SPEC.md»), in einer zweiten, frischen Session wird die Spec umgesetzt. Die neue Session hat sauberen Kontext, und Sie haben ein schriftliches Referenzdokument.

Verifikations-Loops: der Hebel mit dem grössten Effekt

Claude hört auf, wenn die Arbeit fertig aussieht. Ohne eine Prüfung, die es selbst ausführen kann, ist «sieht fertig aus» das einzige verfügbare Signal – und Sie sind die Verifikationsschleife: Jeder Fehler wartet darauf, dass Sie ihn bemerken.

Ein Verifikations-Loop ist alles, was ein lesbares Bestanden/Nicht-Bestanden liefert: eine Testsuite, ein Build-Exitcode, ein Linter, ein Skript, das die Ausgabe gegen eine Fixture diffed, ein Browser-Screenshot gegen ein Design. Es gibt vier Eskalationsstufen, wie hart diese Prüfung das Ende einer Runde blockiert:

Der Skill-Weg ist der, der sich am stärksten verzinst: Sie schreiben die Prüfprozedur einmal in einfacher Sprache auf – so, wie Sie sie einem neuen Teammitglied am ersten Tag erklären würden – und legen sie als SKILL.md ab. Anthropic beschreibt in Building verification loops in Claude Code with Skills vier Einsatzformen: eigenständig (manuell aufgerufen, etwa für Security-Audits), eingebettet (läuft automatisch im Workflow des erzeugenden Skills mit), verkettet (ein Skill triggert den nächsten) und PR-integriert (läuft in GitHub Actions bei jedem Pull Request). Der praktische Einstieg: Notieren Sie eine Woche lang, welche Korrektur Sie Claude wiederholt von Hand mitgeben – genau das gehört als Skill festgehalten.

Wichtig bleibt die Beweislage: Lassen Sie sich das Testergebnis, das ausgeführte Kommando oder den Screenshot zeigen, statt sich auf «erledigt» zu verlassen. Belege zu lesen ist schneller, als die Prüfung selbst zu wiederholen – und es funktioniert auch für Sessions, bei denen Sie nicht zugesehen haben.

Kontext ist die knappste Ressource

Fast alle Best Practices für Claude Code folgen aus einer einzigen Beobachtung: Das Kontextfenster füllt sich schnell, und die Leistung sinkt, während es sich füllt. Ein Debugging-Durchlauf kann Zehntausende Tokens erzeugen. Vier Gewohnheiten machen den Unterschied:

• /clear zwischen unabhängigen Aufgaben. Die «Kitchen-Sink-Session», in der Sie zwischen drei Themen hin- und herspringen, ist der häufigste Selbstschaden.
• Nach zwei erfolglosen Korrekturen abbrechen. Wenn Sie dasselbe Problem zweimal korrigiert haben und es immer noch falsch ist, ist der Kontext mit gescheiterten Ansätzen verschmutzt. /clear und ein besserer Erstprompt, der das Gelernte enthält, schlagen fast immer die lange Session mit angehäuften Korrekturen.
• Recherche in Subagenten auslagern. «Untersuche mit Subagenten, wie unser Auth-System Token-Refresh handhabt» hält den Hauptkontext für die Implementierung frei.
• Untersuchungen eng fassen. Ein unscharfes «schau dir das mal an» führt zu Hunderten gelesener Files.

Was gehört in CLAUDE.md – und was nicht

CLAUDE.md wird bei jeder Session geladen. Jede Zeile kostet also dauerhaft Kontext, und eine überladene Datei führt dazu, dass echte Regeln untergehen. Der Test für jede Zeile: Würde Claude ohne diese Zeile Fehler machen? Wenn nicht, streichen.

Wenn Claude etwas trotz Regel dauernd falsch macht, ist die Datei meistens zu lang und die Regel geht im Rauschen unter. Wissen, das nur manchmal gebraucht wird, gehört nicht in CLAUDE.md, sondern in Skills – die lädt Claude bei Bedarf, ohne jede Session zu belasten.

Prompt-Vorlage zum Kopieren

Für eine typische Implementierungsaufgabe deckt diese Struktur die vier Dinge ab, die zählen: Ort, Muster, Scope und Prüfung.

Ziel: [was am Ende funktionieren soll, in einem Satz]

Kontext:
- Relevante Files: @src/... , @tests/...
- Orientiere dich am bestehenden Muster in [Datei]
- Ausserhalb des Scopes: [was nicht angefasst werden soll]

Vorgehen:
- Erst lesen und verstehen, dann implementieren
- Keine neuen Dependencies

Verifikation:
- Schreib zuerst einen Test, der das Problem reproduziert
- Führe [Kommando] aus und iteriere, bis es besteht
- Zeig mir die Testausgabe, nicht nur eine Erfolgsmeldung

Was in dieser Vorlage bewusst fehlt: «Prüfe deine Arbeit nochmals», «sei gründlich», «denk sorgfältig nach», «du bist ein Senior-Entwickler». Rollen-Prompts und Doppelprüfungs-Anweisungen bringen bei aktuellen Modellen nichts – und die Verifikationsanweisungen schaden bei Opus 5 aktiv.

Troubleshooting: Symptom, Ursache, Massnahme

Fazit

Die drei häufigsten Beschwerden über Opus 5 – zu langsam, überdenkt, schlechter als vorher – haben eine gemeinsame Wurzel: Das Modell arbeitet gründlicher und eigenständiger als seine Vorgänger, und Prompts aus der alten Zeit verstärken genau das, was ohnehin schon passiert. Wer die Verifikations- und Doppelprüfungs-Sätze streicht, den Scope explizit begrenzt, das Effort-Level als primäre Steuerung nutzt statt es auf Default stehen zu lassen, und dem Modell eine Prüfung gibt, die es selbst ausführen kann, bekommt aus demselben Modell deutlich bessere und schnellere Ergebnisse.

Die kürzeste Merkregel für den Alltag: Überdenkt es, geh runter auf medium. Weiss es zu wenig, geh hoch aufs grössere Modell. Und gib ihm immer etwas, woran es selbst merkt, ob es fertig ist.

Sie wollen KI-gestützte Entwicklung und Automatisierung nicht als Experiment, sondern als belastbaren Prozess im Unternehmen? Lassen Sie uns sprechen.

Quellen

• Anthropic – Prompting Claude Opus 5 – Verbosity, Scope, Über-Verifikation, Subagenten-Delegation, Thinking deaktiviert.
• Anthropic – What's new in Claude Opus 5 – Thinking standardmässig aktiv, 1 Mio. Token Kontext, Effort-Restriktion, Preise.
• Anthropic – Effort – die fünf Stufen, Empfehlungen für Opus 5, Effort mit Tool-Nutzung und Prompt-Caching.
• Anthropic – Best practices for Claude Code – Verifikation, Plan-Modus, Kontext-Management, CLAUDE.md, Failure Patterns.
• Anthropic – Building verification loops in Claude Code with Skills – die vier Einsatzformen von Verifikations-Skills.
• Anthropic – An update on recent Claude Code quality reports (23. April 2026) – Effort-Default, Caching-Bug, Verbosity-Limit mit ca. 3 % Qualitätsverlust.
• Anthropic – Choosing a Claude model and effort level in Claude Code – Modell versus Effort, die Diagnosefrage.
• Anthropic – Prompt engineering best practices for 2026 – was heute weniger nötig ist (XML-Tags, Rollen-Prompts) und was bleibt.
• SitePoint – Claude Opus 5 is most efficient at medium effort (FrontierCode) – unabhängiger Benchmark mit Leistungsoptimum im mittleren Effort-Bereich.
• InfoQ – Anthropic traces six weeks of Claude Code quality complaints to three product changes – Einordnung des Postmortems.