Anthropic has published a dedicated page on prompting Claude Opus 5, and the striking thing about it is how much of the advice is subtractive. Opus 5 performs well out of the box on prompts written for Opus 4.8 — the tuning that actually pays off is mostly deleting instructions that used to help and now cause the model to do more work than you wanted.
This guide walks through what to change, with the exact wording Anthropic recommends. Every quoted block below is from Anthropic's own documentation.
First, the settings that will break
Two of these return an HTTP 400 rather than degrading quietly, so fix them before touching prompt text.
| What changed | What happens if you ignore it |
|---|---|
Thinking is on by default — omitting the thinking field now runs adaptive thinking | No error, but max_tokens caps thinking plus answer, so tightly-sized limits truncate mid-response |
Disabling thinking is capped at high effort | 400 — thinking: disabled with xhigh or max is rejected |
temperature, top_p, top_k removed | 400 — steer with prompting instead |
budget_tokens removed | 400 — use output_config.effort |
The thinking-effort rule is validated per request, so a later call that raises effort while thinking is still disabled fails even though earlier calls in the same conversation succeeded. Audit every route, not just the first one.
Nothing else about the request surface changed. The model ID is claude-opus-5, the context window is 1M tokens as both the default and the maximum, and max output is 128K.
Rule 1: delete your verification instructions
This is the one that surprises people, because it inverts standard prompting advice. Opus 5 verifies its own work without being told to. Instructions like "include a final verification step" or "use a subagent to verify" now stack on top of behaviour the model already has, and produce over-verification — more tokens, more time, no quality gain.
Anthropic is explicit that the fix is removal, not rewording: taking these instructions out "reduces wasted tokens with no loss in quality." The same goes for per-prompt phrasing like "double-check your answer" or "re-verify before responding", and for harness scaffolding that bolts on a separate verification pass.
If you maintain a shared prompt library where "ask the model to self-check" is a standing rule, this needs a carve-out for Opus 5 rather than a global edit.
Rule 2: ask for brevity in words, not in effort
Opus 5's default responses run longer than earlier Opus models'. The instinct is to lower effort — and that does not reliably work, because effort governs how much the model thinks, not how much it says. Lowering it can cut thinking volume while leaving the visible answer just as long.
Prompt for length explicitly instead. Anthropic's recommended wording for a user-facing product:
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.In a long system prompt, they suggest repeating a short reminder near the end, where it is closer to the model's output:
<tone_preference>
Keep outputs reasonably concise.
</tone_preference>Rule 3: set deliverable length separately
Conversational verbosity and document length are two different knobs. Files Opus 5 writes to disk — reports, Markdown docs, summaries — also tend to run long, and a conciseness instruction aimed at chat responses will not necessarily rein them in.
Match the length of written documents to what the task needs: cover the
substance, but do not pad with filler sections, redundant summaries,
or boilerplate.Rule 4: say what is in scope
Opus 5 can widen a task — adding steps you did not ask for, or quietly applying its own judgement about what the job should have been. For narrow tasks, constrain it:
Deliver 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.Note the second half. It is not purely a brake — "finish the whole task" also guards against the opposite failure, where the model reports done on a partial result.
Rule 5: cap subagents — this one reversed direction
If you tuned prompts for Opus 4.8, you may have added guidance pushing the model to delegate more, because 4.8 under-used subagents. Opus 5 goes the other way. It delegates readily, and delegation multiplies cost and latency: each subagent re-establishes context, re-explores, reports back, and then the coordinator reads the report.
Remove any delegate-more guidance and replace it with a ceiling:
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.The "do not use subagents to verify" clause is Rule 1 showing up again from a different angle — verification belongs in the main loop.
Rule 6: limit correction narration
Opus 5 catches its own mistakes well, and then tends to explain them at length. In a user-facing product that reads as thrash. Scope the narration to corrections that actually change something:
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.Effort: start at the default, then sweep down
Effort is the primary cost and latency control, and Anthropic's advice here is not "turn it up".
| Level | Use for |
|---|---|
low / medium | Use liberally — strong quality at a fraction of the tokens and latency. Your main cost lever wherever quality holds |
high | The default. Start here, then adjust against your own evals |
xhigh | Demanding coding and agentic work |
max | When correctness matters more than cost; can overthink simpler tasks |
The important instruction is the one people skip: if you carried effort defaults over from a previous model, re-run a sweep. Opus 5's quality at low and medium is high enough that settings tuned on an older model are usually wrong here — and on agentic work, higher effort sometimes reduces total cost by cutting the number of turns.
At xhigh or max, give max_tokens real headroom — 64K is a reasonable starting point — so the model can think and act without truncating.
If you have to run with thinking off
You can disable thinking at high effort or below, but Anthropic's guidance is to avoid it: for most tasks, thinking on at low effort beats thinking off at similar cost. Two artefacts can appear when it is disabled:
- Tool calls written as plain text. The model occasionally describes a tool call in its visible response instead of emitting a structured
tool_useblock. The turn completes normally, the call never runs, and no error is raised — in an agentic loop that leaked text stays in history and skews later turns. Most common on tool-heavy work like search. - Internal XML tags leaking into output, such as
<thinking>.
Two counterintuitive fixes. If your system prompt contains a rule telling the model not to think or not to reason, remove it — that instruction makes tag leakage worse. And do not name the tags you want suppressed; the general form works better than calling out <thinking> specifically. Anthropic's combined mitigation:
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.Give it the whole job at once
Opus 5's biggest gains are on hard, long-horizon work — multi-file features, larger refactors, end-to-end tasks — and it finishes them rather than leaving stubs. It performs best when handed the complete specification up front and left to run, rather than fed instructions turn by turn.
Practically: spend the effort on the first message. State the goal, the constraints, and what "done" looks like, then let it work. Drip-feeding requirements across turns is the usage pattern that costs the most and gets the least out of it.
One more, for code review
Opus 5 finds real bugs at a high rate with few false positives. But if your review prompt says "only report high-severity issues" or "be conservative", it follows that literally and reports less — so measured recall can fall even though bug-finding improved. Ask it to report everything with a confidence and severity attached, and filter in a separate pass.
A starter block
Combining the above into something you can paste into a system prompt and cut down:
Keep responses focused, brief, and concise. Spend most of the response
on the main answer.
Deliver what was asked, at the scope intended. Make routine judgment
calls yourself and check in only when different readings would lead to
materially different work. Finish the whole task.
Only correct an earlier statement when the error would change the user's
conclusions or decisions.
Delegate to a subagent only for large, genuinely independent work. Do not
use subagents to verify your own work.Then go through your existing prompt and delete: verification instructions, "double-check your answer", any push to delegate more, and any rule telling the model not to reason.
What this does not change
The fundamentals still apply — be specific, give examples, state the output format you want, and put stable content early in the prompt so it caches. If you are starting from scratch rather than migrating, our guide on working with AI effectively covers that groundwork, and it is unaffected by any of the above.
One genuinely new lever worth knowing: the minimum cacheable prompt on Opus 5 is 512 tokens, down from 1024 on Opus 4.8. Prompts you previously wrote off as too short to cache may now create cache entries with no change on your side.
For the model's capabilities and benchmark position, see our launch coverage, the benchmark comparison against Fable 5, Sonnet 5 and Opus 4.8, our hands-on review, and where it sits on the model leaderboard. And for a reminder that scaffolding choices can matter as much as the model itself, see the dispute over how much a benchmark harness changes a score.
Want AI news before everyone else?
The morning's most important AI stories, straight to your inbox. No fluff.