Claude Opus 4.7 Best Practices

Most people upgrade to Opus 4.7 the lazy way. They change the model ID and keep working exactly like they did on Opus 4.6.

That leaves a lot on the table.

Anthropic's own guidance for Opus 4.7 is subtle but important: the model thinks more at higher effort, is more selective about tool calls and subagents, reads instructions more literally, and performs better when you treat it like a capable engineer you are delegating to rather than a chatty pair programmer you steer every thirty seconds.

This page is the practical version of that advice. It combines Anthropic's launch guidance, the Claude Code docs, and the patterns that matter in real engineering workflows.

For the release breakdown, see Claude Opus 4.7. For domain-specific examples, see Claude Opus 4.7 use cases.

Quick Win

If you want one immediately better habit with Opus 4.7, use this:

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.

That single shift matters because Opus 4.7 performs best when the first turn gives it enough room to think, plan, and execute without needing five corrective follow-ups.

1. Treat Opus 4.7 Like a Delegate, Not a Pair Programmer

This is the most important mental model change.

Older coding workflows often looked like this:

1. give a vague prompt
2. wait for a partial attempt
3. add one more clarification
4. correct the approach
5. add another constraint

That style is expensive on Opus 4.7 because every new user turn adds reasoning overhead and shifts the model into a more interactive loop than it actually wants for hard work.

The better pattern is:

1. state the job clearly in the first turn
2. include the real constraints and acceptance criteria
3. let the model carry the work further before you interrupt
4. review the result at a meaningful checkpoint instead of micromanaging every step

Bad first turn:

Help me fix auth.

Good first 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

This is not prompt-engineering theater. It is just a better handoff.

2. Front-Load the First Turn

Anthropic's best-practices post on Opus 4.7 keeps coming back to this: if the job is real, give the model the full brief up front.

The first turn should usually include:

• the actual task
• what success looks like
• what must not change
• which files, services, or directories matter
• any existing references or patterns to match
• how the result should be validated

You are trying to eliminate two failure modes:

• under-specification: the model has to guess what you meant
• turn-by-turn patching: the model keeps paying reasoning cost to incorporate corrections that should have been in the original brief

Good structure:

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]

This pattern works for coding, review, security, docs, and multimodal work.

3. Use xhigh as the Default, Not max

Opus 4.7 added a new xhigh effort tier and Claude Code moved the default there for a reason.

xhigh is the best default for most intelligence-sensitive coding work because it captures most of the upside of deeper reasoning without the worst "runaway thought" behavior that max can trigger on longer tasks.

Practical rule:

If you are unsure, start at xhigh.

Drop to high when:

• you are running several sessions at once
• the task is hard but not existential
• you want better spend control

Move to max only when:

• the task is unusually difficult
• the cost of being wrong is high
• you actually need the model's ceiling, not just "probably better"

The common mistake is leaving max on because it feels safer. It usually is not. It often just makes the model slower and more verbose than necessary.

4. Prompt for the Thinking Rate You Want

Opus 4.7 uses adaptive thinking, which means the model decides when to think harder and when to move quickly. That is usually good. It is still steerable.

When you want more thought:

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

When you want less thought:

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

Use this sparingly. Do not stack twelve meta-instructions. One or two lines are enough.

Good use cases for more thinking:

• architecture changes
• migrations
• code review
• security and risk analysis
• investigations with incomplete evidence

Good use cases for less thinking:

• a targeted edit in a file you already named
• quick reference questions
• simple mechanical refactors

5. Tell Opus 4.7 When to Use Tools

Anthropic explicitly says Opus 4.7 uses tools less often by default and reasons more before acting. That is usually an improvement. It also means the model may inspect less than you expect unless you tell it otherwise.

If you want aggressive investigation, say so.

Instead of:

Review this service for bugs.

Use:

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.

This matters for:

• code review
• debugging
• security review
• large codebase investigation
• source-backed writing

The model is not "bad at tools" now. It is simply more selective. Give it the policy you want.

6. Tell It When to Use Subagents

Anthropic also says Opus 4.7 spawns fewer subagents by default. Again, that is usually rational. It is not always what you want.

If the job benefits from parallelism, say so in the first turn.

Example:

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.

Good times to force parallelism:

• review several independent files
• compare several docs or logs
• audit different domains separately: frontend, backend, database
• read the codebase in parallel before implementation

Bad times to force parallelism:

• a single-file fix
• tightly coupled edits
• tasks where the output of step B depends on step A

Opus 4.7 is more judicious by default. That is fine. You still need to specify your orchestration policy when the workflow depends on it.

7. Reduce User Turns on Interactive Work

This is one of Anthropic's clearest recommendations and one of the easiest to ignore.

Every extra user turn adds overhead. If you are working interactively, batch your questions and corrections instead of drip-feeding them.

Bad:

Actually change the schema too.

then:

Also update tests.

then:

Do not touch the billing UI.

Better:

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

That does not mean "never interrupt." It means interrupt at useful boundaries, not every few seconds.

8. Use Auto Mode Only When the Brief Is Good

Auto mode and Opus 4.7 are a strong pairing for long tasks, but only when the scope is clear.

Auto mode makes the most sense when:

• the task is well specified
• the repo or environment is familiar
• you trust the general direction
• you want fewer permission interruptions

Auto mode is a bad fit when:

• the task touches production or shared infrastructure
• the objective is still fuzzy
• you expect lots of human judgment calls
• the environment itself is untrusted or unknown

The sequence that works:

1. write a good first-turn brief
2. verify the plan looks sane
3. switch to auto mode for execution if the task is well-bounded

Do not use auto mode to compensate for a weak brief. That just lets the model move faster in the wrong direction.

9. Cut Permission Friction Instead of Clicking Through It

One of Boris Cherny's best launch-day tips for Opus 4.7 was operational, not model-level: if the model is going to run longer and more autonomously, the old permission workflow becomes the bottleneck.

There are two clean fixes:

Auto mode for well-bounded work

If the task is clear and the environment is trusted, auto mode removes most of the "approve, approve, approve" loop while keeping background safety checks in place.

Good fit:

• long refactors in a familiar repo
• implementation work with a clear definition of done
• investigations where you trust the overall direction

Bad fit:

• unknown environments
• production-sensitive work
• vague tasks where the model still needs heavy steering

For the deeper mechanics, see Claude Code Auto Mode and the official permission mode docs.

/fewer-permission-prompts for repeated safe commands

Boris also called out a new /fewer-permission-prompts skill. The idea is simple: scan what Claude has repeatedly been blocked on, then turn the obviously safe, repetitive commands into explicit permission rules instead of clicking through them forever.

That is a much better Opus 4.7 workflow than either extreme:

• manually approving the same harmless command 20 times
• jumping straight to full bypass mode

The right target is not "no safety." It is "fewer pointless interruptions."

10. Use Recaps and Focus Mode for Long Autonomous Runs

Opus 4.7 is better when you let it run. That makes two UI-level habits much more valuable.

Recaps

Claude Code shipped recaps in 2.1.108, right before Opus 4.7. Boris highlighted them for a reason: if you come back to a long-running session after ten minutes or two hours, a short recap is better than trying to reconstruct state from scrollback.

Recaps are especially useful when:

• you background a task
• you return to a session later in the day
• a long run touched many files or phases
• you want the "what happened / what's next" summary fast

Think of recaps as session re-entry, not just summarization.

Focus mode

Boris also called out the new focus mode in the CLI. The timing makes sense: once you trust Opus 4.7 to investigate, edit, and verify more independently, transcript detail can become visual noise.

Focus mode is useful when:

• you care about the end result more than the live transcript
• the model is running a long sequence of commands correctly
• you want to review the final state, not watch every intermediate action

That is a workflow change worth making. Stronger models shift the bottleneck from "can it do the work?" to "how much of the work do I actually need to watch?"

11. Configure Effort Deliberately

Boris's thread also reinforced something Anthropic's docs now make much clearer: treat effort as a first-class control, not a hidden setting.

Practical rule:

• lower effort for fast answers and lower spend
• higher effort for harder engineering and review work
• do not assume "highest effort" is always the best workflow

That matters more on Opus 4.7 because adaptive thinking lets the model scale up or down much more naturally than the old fixed-budget style.

Keep these defaults:

• low or medium for quick edits and lightweight Q&A
• high when you want a cheaper but still capable working tier
• xhigh for serious day-to-day engineering
• max for genuinely hard, high-cost-to-be-wrong tasks

If you ignore effort, you are leaving one of the biggest Opus 4.7 controls unused.

12. Start a New Session When the Task Changes

Opus 4.7 has a 1M context window. That does not mean you should keep every job in one immortal session.

Anthropic's own session-management guidance is straightforward: when the task changes, start a new session.

Use the current session when:

• the next step is part of the same task
• the current context is still relevant
• rereading the same files would be wasteful

Start a new session when:

• you are switching to a different task
• the session has collected several failed approaches
• you have corrected the model two or three times already
• the context now contains more noise than signal

Use the tools aggressively:

• /clear for unrelated tasks
• /rewind when the last branch of work was wrong
• /compact at natural milestones, not in the middle of fragile debugging
• subagents for investigation, so the main thread stays clean

Large context helps. Context rot is still real.

13. Give Opus 4.7 a Verification Harness

This point came through clearly in Boris's thread and it lines up with Anthropic's own guidance: if you want the biggest jump from Opus 4.7, give it a way to check whether it actually succeeded.

One of the best traits in Opus 4.7 is that it is more willing to verify its own work. Help it.

Add explicit validation language:

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

This is especially important for:

• migrations
• auth changes
• concurrency fixes
• security review
• document-based analysis

The model is more self-checking than earlier versions. You still want "done" to mean something concrete.

Concrete examples of a verification harness:

• backend work: a test command, curl check, or typed build
• frontend work: a browser check, screenshot diff, or lint/build pass
• refactors: compile + test + grep for the old API surface
• docs or content: a checklist of claims to verify against source material

Without a verification path, longer autonomy mostly means longer unverified execution. With one, it becomes useful autonomy.

14. Use Task Budgets for Longer Runs

Anthropic introduced task budgets as a public beta because longer agentic work needs a model-visible budget, not just a hard output cap it cannot see.

If you run agents or API workloads, test task budgets on:

• longer refactors
• research + implementation jobs
• background automation
• code review and repair loops

The best practice is not "always use the biggest budget." It is:

• give the model enough room to finish
• keep the budget finite
• measure which classes of work actually need more

This becomes more important on Opus 4.7 because the model is happy to spend more thought at higher effort on hard runs.

15. Tune for Token Reality, Not Marketing Pricing

Opus 4.7 kept Opus 4.6's list price. That does not mean your workload costs the same.

Your real cost is affected by:

• the new tokenizer
• the higher reasoning spend at higher effort levels
• the larger image pipeline
• how many user turns you create
• how often the model has to recover from ambiguous prompts

Best practices here are simple:

• benchmark on your real workloads
• test high versus xhigh
• use smaller effort on smaller jobs
• downsample images you do not need at full fidelity
• stop treating repeated user clarification as free

Some partners reported better quality at lower effort than Opus 4.6 needed. That is where cost savings come from in practice.

16. Three Prompt Templates Worth Keeping

Template 1: High-Stakes Implementation

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]

Template 2: Review and Investigation

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

Template 3: Document-Heavy Analysis

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. The Biggest Mistakes to Avoid

The habits that waste Opus 4.7 most often are:

• vague first turns
• leaving max on for routine work
• keeping default permission friction even after you know which commands are safe
• ignoring recaps and then reorienting manually inside long sessions
• watching every transcript line when focus mode would make review easier
• assuming the model will investigate aggressively without being told to
• assuming it will fan out to subagents automatically the way older workflows did
• letting unrelated tasks pile into one session
• judging cost only by list price instead of actual token behavior

Most of the "Opus 4.7 is too expensive" complaints are actually workflow complaints wearing a pricing label.

Sources

• 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

Related Pages

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