How to prompt Claude Opus 5 (and the four habits to delete)
How to prompt Claude Opus 5: describe outcomes, cap verbosity, scope the task, and stop asking it to verify, re-check, and delegate.
Describe the outcome, set the boundaries, and say how long you want the answer. Then remove the instructions you wrote for older models. Anthropic's Opus 5 guidance states that "verify your work", "double-check your answer", and "use a subagent to confirm" cost tokens without improving results on this model, because it already does those things unprompted.
System requirements
Model
claude-opus-5
Available through the Claude API, Claude Code, and the Claude apps. This guide is about the prompt, not the runtime, so it applies to all three.
Thinking
On by default
Opus 5 thinks unless you disable it, and it can only be disabled at effort high or below. Requests setting thinking disabled at xhigh or max return a 400 error.
Effort control
output_config.effort
Five levels: low, medium, high (default), xhigh, max. It is a request-level setting, not a message-level one.
Context window
1M tokens, default and maximum
Instruction following and tool calling stay consistent across the window, so you do not need to re-state rules every few turns.
max_tokens
64k is a reasonable starting point at xhigh or max
This is a practical recommendation from Anthropic's effort docs, not a hard requirement. Tune it against your own workloads.
What you should already have
An eval set, however small
Most of the tuning below is a trade between cost and quality. Ten to twenty representative tasks is enough to tell you which way a change moved things.
Describe the outcome, not the procedure
Opus 5 performs best when given the complete task specification up front and left to run.
Drop the step list. A prompt that says "read file A, then read file B, compare them, write a plan, edit, test" fixes a decomposition the model would otherwise choose for itself, and spends turns confirming each step.
State what done looks like instead. Opus 5 is built for long-horizon agentic coding: multi-file features, larger refactors, end-to-end work. Anthropic notes it completes full tasks rather than leaving stubs or placeholders, which is exactly the behaviour a step list interrupts.
1. Read src/auth/session.ts
2. Read the tests
3. Compare the two
4. Write a plan and wait for approval
5. Make the edit
6. Run the testsFix the session-expiry bug in the auth module.
Preserve the existing architecture and public API.
Tests must pass when you're done.Tip
The step list is still right when the order genuinely matters, such as a migration that must run before a backfill. Prescribe sequence when sequence is the requirement, not out of habit.
Replace instructions with constraints
A constraint describes the finished work. An instruction describes a move you want made.
Constraints still hold when the model takes a different route to the answer, so they suit a model you are letting choose its own route.
Keep them checkable. "No new dependencies" can be verified from a diff. "Write clean code" cannot, and the model will spend tokens guessing what you meant.
Requirements:
- No breaking changes to the public API
- No new runtime dependencies
- Match the existing code style; no reformatting unrelated lines
- Backward compatible with the v2 payload shapeScope the task explicitly
Opus 5 can widen a task on its own judgement. Say what is out of bounds.
Anthropic calls this out directly: the model "can also expand the scope of a task, adding steps that weren't requested or applying its own judgment about what the task should be." On a narrow task that is a real cost: you asked for a bug fix and got a refactor.
The docs publish a scope-control snippet you can paste into a system prompt verbatim. It is worth reading closely: it constrains scope in both directions. It stops the model from widening the task, and equally from quietly narrowing it.
Only modify the authentication module.
Do not touch:
- Billing
- Notifications
- The database schemaDeliver what was asked, at the scope intended. Make routine
judgment calls yourself, and check in only when different
readings of the request would lead to materially different
work. If the request seems mistaken or a better approach
exists, say so in a sentence and continue with the task as
asked rather than quietly narrowing, widening, or
transforming it. Finish the whole task, and stop short of
actions that are clearly beyond what was asked.Control verbosity with the prompt, not with effort
Effort controls how much the model thinks. It does not reliably control how much it says.
Opus 5's default user-facing responses run longer than prior Opus models'. Lowering effort reduces thinking volume without reliably shortening the visible response, so reaching for the effort parameter to get shorter answers will not work. Ask for shorter answers instead.
Anthropic publishes a conciseness instruction for user-facing multi-turn products, and recommends pairing it with a short reminder near the end of a long system prompt.
Keep responses focused, brief, and concise. Keep disclaimers
and caveats short, and spend most of the response on the main
answer. When asked to explain something, give a high-level
summary unless an in-depth explanation is specifically
requested.<tone_preference>
Keep outputs reasonably concise.
</tone_preference>Maximum 5 bullet points.
Under 150 words.
Return only the code, no explanation.Tip
Files written to disk are a separate lever. Reports and Markdown documents Opus 5 authors are also longer than on prior models, so add "match the length of written documents to what the task needs; do not pad with filler sections, redundant summaries, or boilerplate."
Tune progress narration deliberately
Opus 5 narrates readily during agentic work. Describe the cadence you want rather than banning updates.
Left alone, Opus 5 announces what it is about to do before it does it, and its per-message output in agentic sessions runs longer than prior models'. In a product with a visible transcript, that is noise; in a long autonomous run where a human is watching, it is reassurance. Pick one and say so.
The lever works in both directions, and Anthropic's guidance is that positive examples of the style you want beat instructions about what not to do.
Before your first tool call, say in one sentence what you're
about to do. While working, give a brief update only when you
find something important or change direction. When you finish,
lead with the outcome: your first sentence should answer
"what happened" or "what did you find," with supporting
detail after it for readers who want it.Set effort from your evals, not from your last model
Start at the default high, then sweep. Do not carry over settings tuned for Opus 4.7 or 4.8.
The previous Opus generation's advice was "start at xhigh for coding and agentic work." That advice has changed. On Opus 5, low and medium produce strong quality at a fraction of the tokens and latency of higher settings, and Anthropic recommends using them liberally as your primary control for cost and response time wherever your evals show quality holds.
Effort is a request-level setting on output_config, and it shapes the rendered prompt, so changing it mid-conversation invalidates your cached prefix. Pick a level at the start of a session that relies on prompt caching and keep it constant.
response = client.messages.create(
model="claude-opus-5",
max_tokens=4096,
messages=[{"role": "user", "content": prompt}],
output_config={"effort": "medium"},
)const response = await client.messages.create({
model: "claude-opus-5",
max_tokens: 4096,
messages: [{ role: "user", content: prompt }],
output_config: { effort: "medium" },
});Tip
Setting effort to high is exactly the same as omitting the parameter. If you never set it, you are already on high.
Cap subagent delegation
Opus 5 delegates more readily than prior models. That is a cost multiplier on small tasks.
Opus 5 coordinates teams of subagents well. Writer-verifier patterns work, and agents rarely overwrite each other. But delegation only pays off on genuinely independent, sizeable tracks of work. Spawning three agents for a question that needs four tool calls multiplies cost and wall-clock time without improving the answer.
If your harness supports subagents, either give explicit guidance on what warrants delegation or set a deterministic cap in code. Anthropic's guidance also rules out one specific pattern: do not use subagents to verify your own work.
Delegate to a subagent only for large tasks that are genuinely
independent and parallelizable, such as a wide multi-file
investigation. Do not delegate work you can finish yourself in
a handful of tool calls, and do not use subagents to verify or
double-check your own work. If one subagent can complete the
task, use one rather than several, and keep spawn counts low.Ask for everything, then filter in a second pass
A specific and useful pattern for code review and bug-finding.
Opus 5 reviews code with high precision and recall, and its accuracy holds at lower effort levels. That makes a fast pass at review time plus a thorough pass later a practical setup.
One caveat: if your review prompt says "only report high-severity issues" or "be conservative", Opus 5 may follow that literally and report less than you wanted. Ask it to report everything, then rank and filter in a separate call.
Review this diff. Report every issue you find, at any
severity, with file and line. Do not filter.Here are the findings. Return only the ones that would change
behaviour in production, ranked most severe first.Specify the output format
Naming the shape of the deliverable removes a class of re-prompting and makes runs comparable.
If you do not say what the output should look like, you will re-prompt for it. Two runs of the same prompt also become hard to compare, which matters once you start evaluating changes.
For long documents, generated files, and reports, ask for one complete artifact rather than explanation interleaved with content. That output is easier to reuse and easier to diff between runs.
Return, in this order:
- Files changed (path + one-line reason)
- Summary (max 3 sentences)
- Risks
- Suggested follow-upsThe four habits to delete
| Delete this | Why |
|---|---|
| "Before finishing: verify correctness, check edge cases, look for regressions" | Opus 5 verifies its own work without being told. Explicit verification instructions cause over-verification; removing them cuts tokens with no loss in quality. |
| "Double-check your answer" / "re-verify before responding" | The model already catches and fixes its own mistakes. These compound with existing behaviour and add cost without improving results. |
| "Use a subagent to verify the result" | Explicitly ruled out. Verification is not what delegation is for, and it multiplies cost on work the model does anyway. |
| Legacy harness scaffolding that adds a separate verification step | Same failure mode as the prompt-level instruction, one layer down. Audit your harness, not just your prompt. |
Each of these is a habit worth having on older models, and Anthropic's Opus 5 page says to remove it. If you inherited a system prompt from an earlier model, this is where to start reading.
- "Think carefully" and "let's think step by step" are also worth dropping: Opus 5 thinks by default, and effort is the supported control for how much.
- Re-validate any vision workarounds you tuned for older models. Opus 5 is strong on charts, documents, diagrams, and UI replication, and Anthropic notes those workarounds may no longer be needed.
Correction narration
Only correct an earlier statement when the error would change
the user's code, conclusions, or decisions. State corrections
plainly and briefly, then continue the task. For slips that
change nothing for the user, make the fix and move on without
noting it.Opus 5 narrates corrections to its own earlier statements more than prior models. In an engineering session that is harmless. In a user-facing product it spends response budget on revisions that change nothing for the reader.
If you must run with thinking disabled
When you use a tool, you may say a brief sentence first. If no
tool can express what the user asked for, say so instead of
guessing. Do not include internal or system XML tags in your
response.Thinking is on by default and can only be disabled at effort high or below. Anthropic's primary recommendation is not to disable it: for most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost.
If your integration genuinely requires it, two artifacts can occasionally appear. The model may write a tool call into its visible text instead of emitting a structured tool_use block. The call never runs, and in an agentic loop that leaked text stays in history and affects later turns. The model may also emit internal XML tags into the visible response. One combined instruction mitigates both.
- Do not name the tags specifically. Instructions that call out thinking tags by name are less effective than the general form.
- If your system prompt contains a rule telling the model not to think or not to reason, remove it. That instruction increases tag leakage.
A prompt template that reflects the current guidance
Goal:
<What does "done" look like?>
Context:
<Repo, constraints of the environment, prior decisions>
Requirements:
- <checkable constraint>
- <checkable constraint>
Scope:
Only modify <X>. Do not touch <Y>, <Z>.
Output:
- <deliverable>
- <deliverable>
Keep the summary under <N> words.
Communication:
One sentence before your first tool call. Brief updates only
for important findings or changes of direction. Lead with the
outcome when you finish.Note what is absent: no step list, no verification block, no delegation encouragement. Opus 5 supplies those itself.
The trade-offs worth knowing
Outcome-oriented prompting trades control for capability. There are cases where that trade is wrong.
- An ambiguous goal statement is more expensive here. Opus 5 resolves the ambiguity itself and finishes the task, so you discover the misreading at the end rather than at step two.
- "Report everything, filter later" costs two calls. On a high-volume review pipeline, measure whether the second pass pays for itself.
- Effort is a behavioural signal, not a token budget. Low effort still thinks on genuinely hard problems. Use max_tokens if you need a hard ceiling.
- This is Opus 5 guidance as of July 2026 and does not transfer to other models. The Opus 4.7 and 4.8 advice to start at xhigh is not the Opus 5 recommendation.
- Deleting verification instructions on trust is uncomfortable. Delete them on one workload, measure, then roll out.
Our verdict
Four things are worth writing down: what done looks like, which files are in scope, how long the answer should be, and when to interrupt you. Verbosity is the one that needs saying explicitly, because effort will not handle it.
The harder work is deletion. If your system prompt has accumulated instructions for models you no longer run, the verification and re-check layer is the first thing to cut on Opus 5, and it is the change most likely to reduce cost without reducing quality.
A caveat on sourcing: this post contradicts other Opus 5 prompting guides on verification and subagent delegation. Everything above is taken from Anthropic's Opus 5 and effort pages, both linked below. Check them rather than taking this post at its word.
State the outcome, fence the scope, cap the length, and delete the instructions you wrote for an older model.
Frequently asked questions
Should I tell Claude Opus 5 to verify its own work?+
No. Anthropic's guidance is to remove explicit verification instructions: Opus 5 verifies its own work without being told, and instructions like "include a final verification step" cause over-verification. Removing them reduces wasted tokens with no loss in quality. The same applies to "double-check your answer" and to harness scaffolding that adds a separate verification step.
Does lowering the effort parameter make Claude Opus 5's responses shorter?+
Not reliably. Effort controls how much the model thinks, not how much it says. To shorten visible responses, put a conciseness instruction in the prompt. Add a separate length instruction for documents the model writes to disk, which are also longer than on prior models.
What effort level should I start with on Claude Opus 5?+
Start with the default, high, then sweep on your own evals. Step up to xhigh for demanding coding and agentic work, or max when a task justifies unconstrained spending. Use low and medium liberally wherever quality holds. Do not reuse effort settings tuned for Opus 4.7 or 4.8. That generation's guidance was to start at xhigh, which is not the Opus 5 recommendation.
Is "think step by step" still useful with Claude Opus 5?+
It is not the right lever. Opus 5 has thinking enabled by default and effort is the supported control for reasoning depth. If you want deeper reasoning, raise effort rather than adding a phrase to the prompt.
Can I turn thinking off on Claude Opus 5?+
Only at effort high or below. Setting thinking to disabled at xhigh or max returns a 400 error. Anthropic recommends keeping thinking on and controlling cost with lower effort instead: for most tasks, thinking enabled at low effort beats thinking disabled at similar cost.
Why does Claude Opus 5 do more than I asked?+
It applies its own judgement about what the task should be, which is useful on broad work and expensive on narrow work. Fence it explicitly by naming the module it may modify and the areas it must not touch, or paste Anthropic's scope snippet, which stops the model widening the task without letting it quietly narrow one either.
Should I encourage Claude Opus 5 to use subagents?+
No, the opposite. Opus 5 already delegates more readily than prior models. Give it a policy that restricts delegation to large, genuinely independent, parallelizable work, keep spawn counts low, and never use subagents to verify its own output.
