Claude Opus 4.7 Best Practices

Die meisten Leute steigen auf Opus 4.7 um, indem sie einfach die Modell-ID ändern und genau wie vorher weiterarbeiten.

Das lässt viel auf dem Tisch liegen.

Anthropics eigene Guidance für Opus 4.7 ist subtil aber wichtig: Das Modell denkt bei höherem Effort tiefer nach, ist selektiver bei Tool-Calls und Subagenten, liest Anweisungen wörtlicher, und funktioniert besser, wenn du es behandelst wie einen fähigen Entwickler, dem du delegierst, statt wie einen Pair-Programmer, den du alle dreißig Sekunden dirigierst.

Diese Seite ist die praktische Version dieser Hinweise. Sie verbindet Anthropics Launch-Guidance, die Claude-Code-Docs und die Muster, die in echten Engineering-Workflows zählen.

Für den Release-Überblick, siehe Claude Opus 4.7. Für domänenspezifische Beispiele, siehe Claude Opus 4.7 use cases.

Schneller Gewinn

Eine sofortige Verbesserung mit Opus 4.7 ist dieser Prompt:

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.

Das macht einen Unterschied, weil Opus 4.7 am besten funktioniert, wenn der erste Turn genug Raum gibt, um zu denken, zu planen und auszuführen, ohne fünf korrigierende Folgeanfragen zu brauchen.

1. Behandle Opus 4.7 wie einen Delegierten, nicht wie einen Pair-Programmer

Das ist die wichtigste Denkmodell-Änderung.

Ältere Coding-Workflows sahen oft so aus:

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

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

Das bessere Muster:

1. den Job im ersten Turn klar formulieren
2. echte Einschränkungen und Abnahmekriterien mit einschließen
3. das Modell die Arbeit weiter tragen lassen, bevor du unterbrichst
4. das Ergebnis an einem sinnvollen Checkpoint prüfen, statt jeden Schritt zu kontrollieren

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 keine Prompt-Engineering-Showeinlage. 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 der Job real ist, gib dem Modell das vollständige Briefing gleich zu Beginn.

Der erste Turn sollte in der Regel enthalten:

• den eigentlichen Task
• wie Erfolg aussieht
• was sich nicht ändern darf
• welche Dateien, Services oder Verzeichnisse relevant sind
• bestehende Referenzen oder Muster, die eingehalten werden sollen
• wie das Ergebnis validiert werden soll

Du willst zwei Fehlermodi eliminieren:

• Unterspezifikation: das Modell muss raten, was du meinst
• Turn-für-Turn-Patching: das Modell zahlt Reasoning-Kosten für Korrekturen, die ins originale Briefing gehört hätten

Gute Struktur:

Task:
[was gebaut, gefixt, geprüft oder untersucht werden soll]

Constraints:
- [was wahr bleiben muss]
- [was vermieden werden muss]

Relevant context:
- [Dateien, Routes, Services, Tickets, Docs]

Definition of done:
- [beobachtbares Ergebnis]
- [Verifikationsschritt]

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

3. xhigh als Standard verwenden, nicht max

Opus 4.7 hat ein neues xhigh-Effort-Tier eingeführt, und Claude Code hat den Standard aus gutem Grund dorthin verschoben.

xhigh ist der beste Standard für die meisten intelligenz-sensitiven Coding-Arbeiten, weil es den größten Teil des Mehrwerts von tieferem Reasoning herausholt, ohne das "Runaway Thought"-Verhalten, das max bei längeren Tasks auslösen kann.

Praktische Regel:

Bei Unsicherheit mit xhigh anfangen.

Zu high wechseln, wenn:

• mehrere Sessions gleichzeitig laufen
• der Task schwer, aber nicht existenziell ist
• bessere Ausgabenkontrolle gewünscht ist

Zu max nur wechseln, wenn:

• der Task ungewöhnlich schwierig ist
• die Kosten eines Fehlers hoch sind
• wirklich die Obergrenze des Modells gebraucht wird, nicht nur "wahrscheinlich besser"

Der häufige Fehler ist, max anlassen, weil es sich sicherer anfühlt. Das ist es meistens nicht. Es macht das Modell oft nur langsamer und geschwätziger als nötig.

4. Die gewünschte Thinking-Rate einfordern

Opus 4.7 nutzt adaptives Thinking, das heißt, das Modell entscheidet selbst, wann es tiefer nachdenkt und wann es schnell vorankommt. Das ist normalerweise gut. Und 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.

Sparsam einsetzen. Nicht zwölf Meta-Anweisungen stapeln. Eine oder zwei Zeilen reichen.

Gute Fälle für mehr Thinking:

• Architekturänderungen
• Migrationen
• Code-Review
• Security- und Risikoanalyse
• Untersuchungen mit unvollständigen Belegen

Gute Fälle für weniger Thinking:

• ein gezielter Edit in einer bereits genannten Datei
• schnelle Referenzfragen
• einfache mechanische Refactors

5. Opus 4.7 sagen, wann es Tools nutzen soll

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

Wenn aggressive Untersuchung gewünscht ist, direkt so sagen.

Statt:

Review this service for bugs.

Besser:

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
• Untersuchungen in großen Codebases
• quellengestütztes Schreiben

Das Modell ist nicht "schlecht mit Tools". Es ist einfach selektiver. Ihm die gewünschte Policy mitgeben.

6. Sagen, wann Subagenten genutzt werden sollen

Anthropic sagt auch, dass Opus 4.7 standardmäßig weniger Subagenten spawnt. Auch das ist meistens rational. Nicht immer das, was man will.

Wenn der Job von Parallelismus profitiert, im ersten Turn so sagen.

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 für erzwungenen Parallelismus:

• mehrere unabhängige Dateien prüfen
• mehrere Docs oder Logs vergleichen
• verschiedene Domänen separat auditieren: Frontend, Backend, Datenbank
• die Codebase parallel lesen, bevor implementiert wird

Schlechte Zeiten für erzwungenen Parallelismus:

• ein einzelner Datei-Fix
• eng gekoppelte Edits
• Tasks, bei denen der Output von Schritt B von Schritt A abhängt

Opus 4.7 ist standardmäßig bedachter. Das ist gut. Die Orchestrierungsrichtlinie muss aber trotzdem spezifiziert werden, 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 verursacht Overhead. Fragen und Korrekturen bündeln 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 heißt nicht "nie unterbrechen." Es heißt: an sinnvollen Grenzen unterbrechen, nicht alle paar Sekunden.

8. Auto-Modus nur bei gutem Briefing nutzen

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

Auto-Modus macht am meisten Sinn, wenn:

• der Task gut spezifiziert ist
• das Repo oder die Umgebung vertraut sind
• die allgemeine Richtung vertraut ist
• weniger Genehmigungsunterbrechungen erwünscht sind

Auto-Modus passt schlecht, wenn:

• der Task Produktions- oder geteilte Infrastruktur berührt
• das Ziel noch unklar ist
• viele menschliche Urteilsanrufe erwartet werden
• die Umgebung nicht vertraut oder unbekannt ist

Die Reihenfolge, die funktioniert:

1. ein gutes First-Turn-Briefing schreiben
2. den Plan auf Sinnhaftigkeit prüfen
3. für die Ausführung auf Auto-Modus wechseln, wenn der Task klar begrenzt ist

Auto-Modus nicht nutzen, um ein schwaches Briefing zu kompensieren. Das lässt das Modell nur schneller in die falsche Richtung rennen.

9. Permission-Friction abbauen statt durchklicken

Einer von Boris Chernys besten Launch-Day-Tipps für Opus 4.7 war betrieblicher Natur, nicht modellseitig: wenn das Modell länger und autonomer laufen wird, wird der alte Permission-Workflow zum Engpass.

Zwei saubere Lösungen:

Auto-Modus für klar begrenzte Arbeit

Wenn der Task klar und die Umgebung vertraut ist, entfernt Auto-Modus den größten Teil der "bestätigen, bestätigen, bestätigen"-Schleife, während Sicherheitsprüfungen im Hintergrund aktiv bleiben.

Gut geeignet:

• lange Refactors in einem vertrauten Repo
• Implementierungsarbeit mit klarer Definition of Done
• Untersuchungen, bei denen die allgemeine Richtung vertraut ist

Schlecht geeignet:

• unbekannte Umgebungen
• produktionssensitive Arbeit
• vage Tasks, bei denen das Modell noch intensiv gesteuert werden muss

Für die tiefere Mechanik, siehe Claude Code Auto Mode und die offiziellen Permission-Mode-Docs.

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

Boris hat auch ein neues /fewer-permission-prompts-Skill hervorgehoben. Die Idee ist simpel: scannen, wobei Claude wiederholt blockiert wurde, dann die offensichtlich sicheren, repetitiven Befehle in explizite Permission-Regeln umwandeln, statt sie ewig durchzuklicken.

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

• denselben harmlosen Befehl 20 Mal manuell bestätigen
• direkt zum vollständigen Bypass-Modus springen

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

10. Recaps und Focus-Modus für lange autonome Runs

Opus 4.7 funktioniert besser, wenn man es laufen lässt. Das macht zwei UI-Level-Gewohnheiten deutlich 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 man nach zehn Minuten oder zwei Stunden zu einer langen Session zurückkommt, ist ein kurzer Recap besser als zu versuchen, den Zustand aus dem Scroll-Verlauf zu rekonstruieren.

Recaps sind besonders nützlich, wenn:

• ein Task in den Hintergrund gegeben wurde
• man später am Tag zu einer Session zurückkehrt
• ein langer Run viele Dateien oder Phasen berührt hat
• man die "Was ist passiert / Was kommt als nächstes"-Zusammenfassung schnell braucht

Recaps als Session-Wiedereinstieg denken, nicht nur als Zusammenfassung.

Focus-Modus

Boris hat auch den neuen Focus-Modus im CLI hervorgehoben. Der Timing macht Sinn: sobald man Opus 4.7 vertraut, selbständiger zu untersuchen, zu editieren und zu verifizieren, kann Transcript-Detail zu visuellem Rauschen werden.

Focus-Modus ist nützlich, wenn:

• das Endergebnis mehr zählt als das Live-Transcript
• das Modell eine lange Befehlsfolge korrekt ausführt
• man den finalen Zustand prüfen will, nicht jeden Zwischenschritt beobachten

Das ist eine Workflow-Änderung, die sich lohnt. Stärkere Modelle verschieben den Engpass von "kann es die Arbeit machen?" zu "wie viel davon muss ich eigentlich beobachten?"

11. Effort gezielt konfigurieren

Boris' Thread hat auch etwas unterstrichen, was Anthropics Docs jetzt viel klarer machen: Effort als erstklassige Steuerung behandeln, nicht als versteckte Einstellung.

Praktische Regel:

• niedrigerer Effort für schnelle Antworten und niedrigere Ausgaben
• höherer Effort für härtere Engineering- und Review-Arbeit
• nicht davon ausgehen, dass "höchster Effort" immer der beste Workflow ist

Das zählt bei Opus 4.7 mehr, weil adaptives Thinking das Modell viel natürlicher auf- und abskalieren lässt als der alte Fixed-Budget-Stil.

Diese Standards beibehalten:

• low oder medium für schnelle Edits und leichte Q&A
• high wenn ein günstigeres, aber trotzdem fähiges Arbeitstier gewünscht wird
• xhigh für ernsthaftes tägliches Engineering
• max für echte Hardfälle mit hohen Fehlerkosten

Wer Effort ignoriert, lässt eine der größten Opus-4.7-Steuerungen ungenutzt.

12. Neue Session starten, wenn der Task wechselt

Opus 4.7 hat ein 1M-Kontextfenster. Das bedeutet nicht, dass jede Aufgabe in einer unsterblichen Session gehalten werden sollte.

Anthropics eigene Session-Management-Guidance ist eindeutig: wenn der Task wechselt, neue Session starten.

Aktuelle Session weiterverwenden, wenn:

• der nächste Schritt Teil desselben Tasks ist
• der aktuelle Kontext noch relevant ist
• erneutes Lesen derselben Dateien verschwenderisch wäre

Neue Session starten, wenn:

• zu einem anderen Task gewechselt wird
• die Session mehrere gescheiterte Ansätze gesammelt hat
• das Modell zwei oder drei Mal korrigiert wurde
• der Kontext jetzt mehr Rauschen als Signal enthält

Die Tools aggressiv nutzen:

• /clear für unzusammenhängende Tasks
• /rewind wenn der letzte Arbeitsast falsch war
• /compact an natürlichen Meilensteinen, nicht mitten in fraglichem Debugging
• Subagenten für Untersuchungen, damit der Hauptfaden sauber bleibt

Großes Kontext hilft. Context Rot ist trotzdem real.

13. Opus 4.7 ein Verifikations-Harness geben

Dieser Punkt kam klar in Boris' Thread durch und stimmt mit Anthropics eigener Guidance überein: wenn der größte Sprung von Opus 4.7 gewünscht wird, ihm einen Weg geben, zu prüfen, ob es tatsächlich erfolgreich war.

Einer der besten Traits in Opus 4.7 ist, dass es bereiter ist, die eigene Arbeit zu verifizieren. Dabei helfen: 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

Besonders wichtig für:

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

Das Modell prüft mehr selbst als frühere Versionen. Trotzdem soll "fertig" etwas Konkretes bedeuten.

Konkrete Beispiele für ein Verifikations-Harness:

• Backend-Arbeit: ein Test-Befehl, curl-Check oder typisierter Build
• Frontend-Arbeit: ein Browser-Check, Screenshot-Diff oder Lint/Build-Pass
• Refactors: kompilieren + testen + grep für die alte API-Oberfläche
• Docs oder Content: eine Checkliste von zu verifizierenden Behauptungen gegen Quellmaterial

Ohne Verifikationspfad bedeutet längere Autonomie meist längere unverифizierte Ausführung. Mit einem wird daraus nützliche Autonomie.

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

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

Bei Agenten oder API-Workloads Task-Budgets testen bei:

• längeren Refactors
• Recherche + Implementierungsjobs
• Hintergrundautomatisierung
• Code-Review- und Reparaturschleifen

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

• dem Modell genug Raum geben, um fertig zu werden
• das Budget endlich halten
• messen, welche Arbeitsklassen tatsächlich mehr brauchen

Das wird bei Opus 4.7 wichtiger, weil das Modell bei höherem Effort gerne mehr Gedanken in schwierige Runs investiert.

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

Opus 4.7 hat den Listenpreis von Opus 4.6 behalten. Das bedeutet nicht, dass der Workload gleich viel kostet.

Die tatsächlichen Kosten werden beeinflusst durch:

• den neuen Tokenizer
• den höheren Reasoning-Aufwand bei höheren Effort-Levels
• die größere Bild-Pipeline
• wie viele User-Turns erstellt werden
• wie oft das Modell von vagen Prompts sich erholen muss

Best Practices hier sind simpel:

• auf echten Workloads benchmarken
• high versus xhigh testen
• niedrigeren Effort für kleinere Jobs nutzen
• Bilder downsampeln, die nicht in voller Auflösung gebraucht werden
• wiederholte User-Klarifikationen nicht als kostenlos behandeln

Einige Partner berichten bessere Qualität bei niedrigerem Effort als Opus 4.6 gebraucht hat. Dort kommen in der Praxis die Kosteneinsparungen her.

16. Drei Prompt-Vorlagen, die sich lohnen

Vorlage 1: Hochriskante 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: Dokumentenschwere 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 häufigsten Fehler

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

• vage erste Turns
• max für Routinearbeit anlassen
• Standard-Permission-Friction beibehalten, auch nachdem bekannt ist, welche Befehle sicher sind
• Recaps ignorieren und dann manuell in langen Sessions reorientieren
• jede Transcript-Zeile beobachten, wenn Focus-Modus den Review einfacher machen würde
• davon ausgehen, dass das Modell aggressiv untersucht, ohne es dazu aufzufordern
• davon ausgehen, dass es automatisch zu Subagenten auffächert, wie ältere Workflows es taten
• unzusammenhängende Tasks in einer Session aufhäufen
• Kosten nur nach Listenpreis statt tatsächlichem Token-Verhalten beurteilen

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

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-day X thread on Opus 4.7 workflow tips, April 16, 2026
• Introducing Claude Opus 4.7

Verwandte Seiten

• Claude Opus 4.7
• Claude Opus 4.7 use cases
• Claude Code Pricing and Token Usage
• Claude Code Auto Mode
• Claude Code Models