Claude Opus 4.7 Best Practices

Die meisten Leute upgraden auf Opus 4.7 auf die faule Tour. Sie ändern die Modell-ID und arbeiten genau so weiter wie mit Opus 4.6.

Dabei lassen sie eine Menge liegen.

Anthropics eigene Empfehlungen für Opus 4.7 sind subtil, aber wichtig: Das Modell denkt bei höherem Effort mehr nach, ist selektiver bei Tool-Aufrufen und Subagenten, liest Anweisungen wörtlicher, und arbeitet besser, wenn du es wie einen kompetenten Ingenieur behandelst, dem du eine Aufgabe delegierst, statt wie einen Pair-Programmer, den du alle dreißig Sekunden korrigierst.

Diese Seite ist die praktische Version davon. Sie kombiniert Anthropics Launch-Empfehlungen, die Claude Code Docs und die Muster, die in echten Engineering-Workflows zählen.

Für die Release-Übersicht, schau dir Claude Opus 4.7 an. Für domänenspezifische Beispiele, Claude Opus 4.7 Anwendungsfälle.

Schneller Gewinn

Wenn du eine sofort bessere Gewohnheit mit Opus 4.7 willst, nutze das:

Here is the task, the constraint set, the files that matter, and the definition of done.
Do the full job, validate before you report back, and call out missing information instead of guessing.

Diese eine Änderung macht einen Unterschied, weil Opus 4.7 am besten funktioniert, wenn der erste Turn genug Raum zum Denken, Planen und Ausführen lässt, ohne dass du fünf korrigierende Follow-ups brauchst.

1. Behandle Opus 4.7 als Delegierten, nicht als Pair-Programmer

Das ist die wichtigste Änderung im mentalen Modell.

Ältere Coding-Workflows sahen oft so aus:

1. vagen Prompt eingeben
2. auf einen Teilversuch warten
3. eine weitere Klarstellung hinzufügen
4. den Ansatz korrigieren
5. eine weitere Einschränkung hinzufügen

Dieser Stil ist teuer bei Opus 4.7, weil jeder neue User-Turn Reasoning-Overhead hinzufügt und das Modell in eine interaktivere Schleife zwingt, als es für harte Arbeit eigentlich will.

Das bessere Muster ist:

1. die Aufgabe klar im ersten Turn formulieren
2. die echten Einschränkungen und Abnahmekriterien einschließen
3. das Modell die Arbeit weiterführen lassen, bevor du unterbrichst
4. das Ergebnis an einem sinnvollen Checkpoint überprüfen statt jeden Schritt zu mikromanagen

Schlechter erster Turn:

Help me fix auth.

Guter erster Turn:

Fix the OAuth redirect loop where successful login returns users to /login instead of /dashboard.

Constraints:
- keep the existing session format
- do not change provider configuration
- update tests if needed

Relevant areas:
- src/lib/auth.ts
- src/middleware.ts
- app/login/*

Definition of done:
- login succeeds
- user lands on /dashboard
- no redirect loop
- tests pass

Das ist kein Prompt-Engineering-Theater. Es ist einfach ein besseres Briefing.

2. Den ersten Turn vorladen

Anthropics Best-Practices-Post zu Opus 4.7 kommt immer wieder darauf zurück: Wenn die Aufgabe echt ist, gib dem Modell das vollständige Briefing von Anfang an.

Der erste Turn sollte normalerweise enthalten:

• die eigentliche Aufgabe
• wie Erfolg aussieht
• was sich nicht ändern darf
• welche Dateien, Services oder Verzeichnisse relevant sind
• alle vorhandenen Referenzen oder Muster, die zu befolgen sind
• wie das Ergebnis validiert werden soll

Du versuchst, zwei Fehlermodi zu vermeiden:

• Unterbestimmung: Das Modell muss raten, was du meinst
• Turn-für-Turn-Flicken: Das Modell zahlt immer wieder Reasoning-Kosten, um Korrekturen einzubauen, die im ursprünglichen Briefing hätten stehen sollen

Gute Struktur:

Task:
[what to build, fix, review, or investigate]

Constraints:
- [what must stay true]
- [what must be avoided]

Relevant context:
- [files, routes, services, tickets, docs]

Definition of done:
- [observable outcome]
- [verification step]

Dieses Muster funktioniert für Coding, Review, Security, Docs und multimodale Arbeit.

3. xhigh als Standard nutzen, nicht max

Opus 4.7 hat eine neue xhigh-Effort-Stufe hinzugefügt, und Claude Code hat den Standard dorthin verschoben, aus gutem Grund.

xhigh ist der beste Standard für die meisten intelligence-sensitiven Coding-Aufgaben, weil es die meisten Vorteile tieferen Reasonings nutzt, ohne das schlimmste "ausufernde Gedanken"-Verhalten, das max bei längeren Tasks auslösen kann.

Praktische Regel:

Wenn du unsicher bist, starte mit xhigh.

Auf high wechseln, wenn:

• du mehrere Sessions gleichzeitig ausführst
• die Aufgabe schwer, aber nicht existenziell ist
• du bessere Kostenkontrolle willst

Zu max wechseln nur, wenn:

• die Aufgabe ungewöhnlich schwierig ist
• die Kosten eines Fehlers hoch sind
• du wirklich die Obergrenze des Modells brauchst, nicht nur "wahrscheinlich besser"

Der häufige Fehler ist, max laufen zu lassen, weil es sicherer wirkt. Das ist es meistens nicht. Oft macht es das Modell nur langsamer und geschwätziger als nötig.

4. Den gewünschten Denkrhythmus im Prompt angeben

Opus 4.7 nutzt adaptives Denken, was bedeutet, dass das Modell selbst entscheidet, wann es tiefer denkt und wann es sich beeilt. Das ist meistens gut. Es ist trotzdem steuerbar.

Wenn du mehr Nachdenken willst:

This problem is subtle. Think carefully and step by step before acting.
Verify assumptions before you edit anything.

Wenn du weniger Nachdenken willst:

Prioritize a direct answer over deep reasoning.
Be concise and only inspect additional files if necessary.

Nutze das sparsam. Staple nicht zwölf Meta-Anweisungen. Ein oder zwei Zeilen reichen.

Gute Anwendungsfälle für mehr Nachdenken:

• Architekturveränderungen
• Migrationen
• Code Review
• Sicherheits- und Risikoanalyse
• Untersuchungen mit unvollständigen Hinweisen

Gute Anwendungsfälle für weniger Nachdenken:

• ein gezieltes Edit in einer Datei, die du bereits genannt hast
• schnelle Referenzfragen
• einfache mechanische Refactors

5. Opus 4.7 sagen, wann es Tools nutzen soll

Anthropic sagt explizit, dass Opus 4.7 Tools standardmäßig weniger oft nutzt und mehr nachdenkt, bevor es handelt. Das ist meistens eine Verbesserung. Es bedeutet aber auch, dass das Modell weniger untersucht als du vielleicht erwartest, wenn du es nicht anders sagst.

Wenn du aggressive Untersuchung willst, sag das.

Statt:

Review this service for bugs.

Nutze:

Review this service for bugs.
Read the relevant implementation files before concluding.
Use search and file reads aggressively where needed.
Do not rely on assumptions if you can verify them from the codebase.

Das zählt für:

• Code Review
• Debugging
• Security Review
• Untersuchung großer Codebases
• quellengestütztes Schreiben

Das Modell ist jetzt nicht "schlecht mit Tools". Es ist einfach selektiver. Gib ihm die Richtlinie, die du willst.

6. Sagen, wann es Subagenten nutzen soll

Anthropic sagt auch, dass Opus 4.7 standardmäßig weniger Subagenten spawnt. Auch das ist meistens vernünftig. Es ist nicht immer das, was du willst.

Wenn die Aufgabe von Parallelismus profitiert, sag das im ersten Turn.

Beispiel:

Use subagents when the work naturally splits.
Spawn multiple subagents in the same turn when fanning out across independent files or domains.
Do not spawn a subagent for work you can complete directly in one response.

Gute Zeiten, Parallelismus zu erzwingen:

• mehrere unabhängige Dateien reviewen
• mehrere Docs oder Logs vergleichen
• verschiedene Domains separat prüfen: Frontend, Backend, Datenbank
• die Codebase parallel lesen, bevor du implementierst

Schlechte Zeiten, Parallelismus zu erzwingen:

• ein Single-File-Fix
• eng gekoppelte Edits
• Aufgaben, bei denen die Ausgabe von Schritt B von Schritt A abhängt

Opus 4.7 ist standardmäßig umsichtiger. Das ist okay. Du musst trotzdem deine Orchestrierungsrichtlinie angeben, wenn der Workflow davon abhängt.

7. User-Turns bei interaktiver Arbeit reduzieren

Das ist eine der klarsten Empfehlungen von Anthropic und eine der einfachsten, die man ignoriert.

Jeder zusätzliche User-Turn fügt Overhead hinzu. Wenn du interaktiv arbeitest, bündle deine Fragen und Korrekturen, statt sie tropfenweise zu geben.

Schlecht:

Actually change the schema too.

dann:

Also update tests.

dann:

Do not touch the billing UI.

Besser:

Update the auth flow and schema, update tests, but do not modify the billing UI.
Keep the session format unchanged.

Das bedeutet nicht "unterbrech nie". Es bedeutet: unterbrech an nützlichen Grenzen, nicht alle paar Sekunden.

8. Auto Mode nur nutzen, wenn das Briefing gut ist

Auto Mode und Opus 4.7 sind eine starke Kombination für lange Aufgaben, aber nur wenn der Umfang klar ist.

Auto Mode macht am meisten Sinn, wenn:

• die Aufgabe gut spezifiziert ist
• das Repo oder die Umgebung bekannt ist
• du der allgemeinen Richtung vertraust
• du weniger Berechtigungs-Unterbrechungen willst

Auto Mode passt schlecht, wenn:

• die Aufgabe Produktion oder geteilte Infrastruktur berührt
• das Ziel noch unklar ist
• du viele menschliche Urteilsaufrufe erwartest
• die Umgebung selbst nicht vertrauenswürdig oder unbekannt ist

Die Reihenfolge, die funktioniert:

1. ein gutes First-Turn-Briefing schreiben
2. prüfen, ob der Plan vernünftig aussieht
3. für die Ausführung auf Auto Mode wechseln, wenn die Aufgabe gut abgegrenzt ist

Nutze Auto Mode nicht, um ein schwaches Briefing zu kompensieren. Das lässt das Modell nur schneller in die falsche Richtung laufen.

9. Permission-Reibung beseitigen, statt durchzuklicken

Einer der besten Tipps von Boris Cherny zum Launch von Opus 4.7 war operativ, nicht auf Modellebene: Wenn das Modell länger und autonomer laufen wird, wird der alte Berechtigungs-Workflow zum Engpass.

Es gibt zwei saubere Lösungen:

Auto Mode für gut abgegrenzte Arbeit

Wenn die Aufgabe klar und die Umgebung vertrauenswürdig ist, entfernt Auto Mode die meisten "approve, approve, approve"-Schleifen, während er Hintergrund-Sicherheitsprüfungen aufrechterhält.

Passt gut:

• lange Refactors in einem bekannten Repo
• Implementierungsarbeit mit klarer Definition of Done
• Untersuchungen, bei denen du der allgemeinen Richtung vertraust

Passt schlecht:

• unbekannte Umgebungen
• produktionssensitive Arbeit
• vage Aufgaben, bei denen das Modell noch intensives Steering braucht

Für die tiefere Mechanik, schau dir Claude Code Auto Mode und die offiziellen Permission Mode Docs an.

/fewer-permission-prompts für wiederholte sichere Befehle

Boris hat auch ein neues /fewer-permission-prompts-Skill hervorgehoben. Die Idee ist einfach: Scann, wobei Claude wiederholt blockiert wurde, und mache die offensichtlich sicheren, repetitiven Befehle zu expliziten Berechtigungsregeln, statt für immer durchzuklicken.

Das ist ein viel besserer Opus 4.7-Workflow als beide Extreme:

• denselben harmlosen Befehl 20 Mal manuell zu genehmigen
• direkt in den vollständigen Bypass-Modus zu springen

Das richtige Ziel ist nicht "keine Sicherheit". Es ist "weniger sinnlose Unterbrechungen".

10. Recaps und Focus Mode für lange autonome Läufe nutzen

Opus 4.7 ist besser, wenn du es laufen lässt. Das macht zwei UI-Level-Gewohnheiten viel wertvoller.

Recaps

Claude Code hat Recaps in 2.1.108 eingeführt, kurz vor Opus 4.7. Boris hat sie aus gutem Grund hervorgehoben: Wenn du nach zehn Minuten oder zwei Stunden zu einer lang laufenden Session zurückkommst, ist ein kurzes Recap besser als der Versuch, den Status aus dem Scrollback zu rekonstruieren.

Recaps sind besonders nützlich, wenn:

• du eine Aufgabe in den Hintergrund legst
• du später am Tag zu einer Session zurückkommst
• ein langer Lauf viele Dateien oder Phasen berührt hat
• du schnell die "Was ist passiert / Was kommt als nächstes"-Zusammenfassung willst

Denk an Recaps als Session-Wiedereinstieg, nicht nur als Zusammenfassung.

Focus Mode

Boris hat auch den neuen Focus Mode im CLI hervorgehoben. Das Timing macht Sinn: Wenn du Opus 4.7 vertraust, selbständiger zu untersuchen, zu bearbeiten und zu verifizieren, kann das Transkript-Detail zu visuellem Rauschen werden.

Focus Mode ist nützlich, wenn:

• du dich mehr für das Endergebnis interessierst als für das Live-Transkript
• das Modell eine lange Befehlssequenz korrekt ausführt
• du den Endzustand überprüfen willst, nicht jede Zwischenaktion beobachten

Das ist eine Workflow-Änderung, die sich lohnt. Stärkere Modelle verschieben den Engpass von "Kann es die Arbeit tun?" zu "Wie viel der Arbeit muss ich eigentlich beobachten?"

11. Effort bewusst konfigurieren

Boris' Thread hat auch etwas bestätigt, das Anthropics Docs jetzt viel deutlicher machen: Behandle Effort als eine erstklassige Kontrolle, nicht als versteckte Einstellung.

Praktische Regel:

• niedrigerer Effort für schnelle Antworten und geringere Ausgaben
• höherer Effort für schwereres Engineering und Review-Arbeit
• nicht annehmen, dass "höchster Effort" immer der beste Workflow ist

Das zählt mehr bei Opus 4.7, weil adaptives Denken dem Modell erlaubt, viel natürlicher auf- und abzuskalieren als der alte Stil mit festem Budget.

Diese Standardwerte behalten:

• low oder medium für schnelle Edits und leichtes Q&A
• high wenn du eine günstigere, aber noch leistungsfähige Arbeitsstufe willst
• xhigh für ernsthaftes tägliches Engineering
• max für wirklich schwierige, fehlerkostenanfällige Aufgaben

Wenn du Effort ignorierst, lässt du eine der größten Opus 4.7-Kontrollen ungenutzt.

12. Eine neue Session starten, wenn sich die Aufgabe ändert

Opus 4.7 hat ein 1M-Kontextfenster. Das bedeutet nicht, dass du jede Aufgabe in einer unsterblichen Session halten solltest.

Anthropics eigene Session-Management-Empfehlungen sind klar: Wenn sich die Aufgabe ändert, starte eine neue Session.

Aktuelle Session nutzen, wenn:

• der nächste Schritt Teil derselben Aufgabe ist
• der aktuelle Kontext noch relevant ist
• dieselben Dateien nochmal zu lesen verschwenderisch wäre

Neue Session starten, wenn:

• du zu einer anderen Aufgabe wechselst
• die Session mehrere fehlgeschlagene Ansätze gesammelt hat
• du das Modell bereits zwei oder drei Mal korrigiert hast
• der Kontext jetzt mehr Rauschen als Signal enthält

Die Tools aggressiv nutzen:

• /clear für unverbundene Aufgaben
• /rewind wenn der letzte Arbeitsast falsch war
• /compact an natürlichen Meilensteinen, nicht mitten in fragilen Debugging-Sessions
• Subagenten für Untersuchungen, damit der Hauptthread sauber bleibt

Großer Kontext hilft. Kontext-Verfall ist trotzdem real.

13. Opus 4.7 einen Verifikationsrahmen geben

Dieser Punkt kam in Boris' Thread klar durch und deckt sich mit Anthropics eigener Empfehlung: Wenn du den größten Sprung von Opus 4.7 willst, gib ihm eine Möglichkeit zu prüfen, ob es wirklich erfolgreich war.

Eine der besten Eigenschaften von Opus 4.7 ist, dass es bereitwilliger seine eigene Arbeit verifiziert. Hilf ihm.

Explizite Validierungssprache hinzufügen:

Before you report done:
- verify assumptions you relied on
- run the relevant tests
- check the final changed files for consistency
- list remaining risk, if any

Das ist besonders wichtig für:

• Migrationen
• Auth-Änderungen
• Concurrency-Fixes
• Security Review
• dokumentenbasierte Analyse

Das Modell prüft sich selbst mehr als frühere Versionen. Du willst trotzdem, dass "fertig" etwas Konkretes bedeutet.

Konkrete Beispiele für einen Verifikationsrahmen:

• Backend-Arbeit: ein Testbefehl, curl-Check oder typisierter Build
• Frontend-Arbeit: ein Browser-Check, Screenshot-Diff oder Lint/Build-Pass
• Refactors: Compile + Test + grep nach der alten API-Oberfläche
• Docs oder Content: eine Checkliste von Behauptungen, die gegen Quellmaterial zu verifizieren sind

Ohne einen Verifikationspfad bedeutet längere Autonomie meist nur längere ungeprüfte Ausführung. Mit einem wird es nützliche Autonomie.

14. Task-Budgets für längere Läufe nutzen

Anthropic hat Task-Budgets als Public Beta eingeführt, weil längere agentische Arbeit ein modellsichtbares Budget braucht, nicht nur ein hartes Output-Cap, das es nicht sehen kann.

Wenn du Agenten oder API-Workloads ausführst, teste Task-Budgets für:

• längere Refactors
• Research + Implementierungs-Jobs
• Hintergrund-Automation
• Code Review und Repair-Schleifen

Die Best Practice ist nicht "immer das größte Budget nutzen". Es ist:

• dem Modell genug Raum geben, um fertig zu werden
• das Budget endlich halten
• messen, welche Klassen von Arbeit wirklich mehr brauchen

Das wird bei Opus 4.7 wichtiger, weil das Modell bereit ist, bei höherem Effort mehr Gedanken für schwierige Läufe auszugeben.

15. Auf Token-Realität tunen, nicht auf Marketing-Preise

Opus 4.7 hat Opus 4.6's Listenpreis behalten. Das bedeutet nicht, dass deine Workload gleich viel kostet.

Deine echten Kosten werden beeinflusst durch:

• den neuen Tokenizer
• die höheren Reasoning-Ausgaben bei höheren Effort-Stufen
• die größere Bild-Pipeline
• wie viele User-Turns du erzeugst
• wie oft das Modell sich von unklaren Prompts erholen muss

Best Practices hier sind einfach:

• auf echten Workloads benchmarken
• high versus xhigh testen
• kleineren Effort für kleinere Jobs nutzen
• Bilder downsampeln, die du nicht in voller Auflösung brauchst
• aufhören, wiederholte Nutzerklärungen als kostenlos zu behandeln

Einige Partner berichteten bessere Qualität bei niedrigerem Effort als Opus 4.6 brauchte. Das ist, wo Kosteneinsparungen in der Praxis herkommen.

16. Drei Prompt-Vorlagen, die es wert sind, behalten zu werden

Vorlage 1: High-Stakes-Implementierung

Implement [task].

Constraints:
- [must preserve]
- [must avoid]

Relevant files:
- [file/path]
- [file/path]

Working style:
- think carefully before acting
- verify assumptions from code, not guesses
- use subagents only when the work naturally splits

Definition of done:
- [observable outcome]
- [test or verification]

Vorlage 2: Review und Untersuchung

Investigate [problem].

Use tools and file reads aggressively where needed.
Do not guess if the codebase can answer the question.

I want:
- root cause
- files involved
- likely fix
- edge cases or risks

Vorlage 3: Dokumenten-intensive Analyse

Review these materials and produce a decision memo.

Requirements:
- separate facts from interpretation
- call out ambiguity explicitly
- list what evidence is missing
- cite the exact source section when possible

17. Die größten Fehler zu vermeiden

Die Gewohnheiten, die Opus 4.7 am häufigsten verschwenden:

• vage erste Turns
• max für Routinearbeit laufen lassen
• Standard-Permission-Reibung beibehalten, selbst nachdem du weißt, welche Befehle sicher sind
• Recaps ignorieren und dann manuell in langen Sessions reorientieren
• jede Transkriptzeile beobachten, wenn Focus Mode den Review einfacher machen würde
• annehmen, dass das Modell ohne Anweisung aggressiv untersucht
• annehmen, dass es automatisch auf Subagenten auffächert, wie es ältere Workflows taten
• unverbundene Aufgaben in eine Session stapeln
• Kosten nur am Listenpreis statt am tatsächlichen Token-Verhalten messen

Die meisten "Opus 4.7 ist zu teuer"-Beschwerden sind eigentlich Workflow-Beschwerden mit einem Preis-Etikett.

Quellen

• Best practices for using Claude Opus 4.7 with Claude Code
• Using Claude Code: session management and 1M context
• Claude Code best practices docs
• Claude Code permission modes
• Claude Code changelog
• Claude Code commands
• Boris Cherny, Launch-Tag X-Thread zu Opus 4.7 Workflow-Tipps, 16. April 2026
• Introducing Claude Opus 4.7

Verwandte Seiten

• Claude Opus 4.7
• Claude Opus 4.7 Anwendungsfälle
• Claude Code Preise und Token-Nutzung
• Claude Code Auto Mode
• Claude Code Modelle