How to Prompt Claude Opus 5: Anthropic's Official Guide

Anthropic's "Prompting Claude Opus 5" documentation is not a rewrite of prompt engineering fundamentals - it is a short list of behavioural deltas from Opus 4.8, each paired with a concrete snippet. The throughline across nearly all of them is that Opus 5 does more on its own initiative than prior models: it narrates its plan before acting, verifies its own output, catches and fixes its own mistakes, and delegates to subagents when a task looks parallelisable. That autonomy is generally a capability win, but left completely unguided it also means longer responses, more narration than some products want, and occasionally more delegation or scope-expansion than a task called for.

Anthropic's fix in every case is the same shape: describe the behaviour you want explicitly, rather than assuming the model needs to be told to do more. Where older prompting habits added instructions ("verify your answer", "double-check before responding"), the Opus 5 guidance is often to remove them, because the model already does that work internally and the instruction just compounds it.

• Best for: teams migrating agentic harnesses, coding assistants or user-facing products from Opus 4.8 to Opus 5, or anyone tuning a first Opus 5 integration.
• Core shift: Opus 5 needs explicit shape and scope guidance more than it needs explicit permission to think or verify - it already does both by default.
• Defining trait: nearly every official pattern is about calibrating an autonomous behaviour Opus 5 already exhibits, not switching a capability on.
• Main caveat: thinking can only be disabled at effort high or below, and Anthropic's own recommendation is not to disable it at all.

Anthropic's guide opens by naming the capability changes that actually matter for how you write prompts, rather than every benchmark improvement. On agentic coding, Opus 5 is built for multi-file features and larger refactors, and it completes full tasks rather than leaving stubs - which means it performs best when given the complete task specification up front and left to run, rather than the drip-fed, check-in-heavy style that suited less autonomous models. On code review, Anthropic notes Opus 5 finds real bugs at a high rate with few false positives, and that accuracy holds even at lower effort settings - but a literal instruction like "only report high-severity issues" gets followed literally, so the guide recommends asking for everything and filtering afterward in a separate pass if you want to be selective.

Three more deltas round out the list: efficiency at lower effort, where low and medium now hold strong quality at a fraction of the tokens and latency of higher settings, making them the primary lever for cost and speed rather than an afterthought; vision, where prompt-side workarounds tuned for weaker models' chart and diagram reading may no longer be necessary and are worth re-testing; and multi-agent coordination, where Opus 5 runs writer-verifier subagent patterns with few cases of agents overwriting each other's work - useful, but worth capping deliberately for cost-sensitive workloads (see the subagent section below). The context window is also now 1M tokens as both default and maximum, with instruction-following and tool-calling that Anthropic says stay consistent across that full window.

Opus 5's default user-facing responses run longer than prior Opus models'. The important nuance in Anthropic's guidance: the effort parameter controls how much the model thinks, not how much it says - lowering effort reduces internal thinking volume but does not reliably shorten the visible response. If you want shorter answers, the guide says to prompt for it explicitly rather than relying on effort level as a proxy.

For a user-facing multi-turn product, Anthropic's example instruction is:

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.

For longer system prompts, Anthropic recommends pairing that instruction with a short reminder placed near the end of the prompt - attention to instructions can fade across a long system prompt, so a closing nudge like a <tone_preference> tag reinforcing "keep outputs reasonably concise" reinforces the earlier guidance where the model is about to act on it.

Opus 5 narrates readily during agentic work - it tends to announce what it's about to do, and per-message output during agentic sessions often runs longer than on prior models. Anthropic's guidance is that this benefits from explicit cadence instructions rather than being left to the model's default. To tune narration down:

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.

To tune narration up, or to change its style, the same lever works in reverse - Anthropic notes that positive examples of the communication style you want are more effective than instructions about what to avoid, so show the model the shape of update you want rather than listing what not to do.

Separate from conversational verbosity, files Opus 5 writes to disk - reports, Markdown documents, summaries - also tend to run longer than on prior models. For products where Claude authors documents directly, Anthropic's recommended addition is explicit length calibration:

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.

This is a small, easy instruction to miss because it targets a different surface (files on disk) than the conversational-verbosity guidance above (chat responses) - a coding agent or documentation generator can need both instructions simultaneously, tuned independently.

This is the section most worth re-reading if you're migrating an existing harness. Opus 5 verifies its own work without being told to. If your prompt contains explicit verification instructions carried over from prompting older, less self-checking models - "include a final verification step for any non-trivial task," "use a subagent to verify" - Anthropic's guidance is to remove them: instructions like these cause over-verification on Opus 5, and removing them reduces wasted tokens with no loss in quality. The same applies to legacy harness scaffolding that bolts on a separate verification step.

Opus 5 can also expand a task's scope on its own judgement, adding steps that weren't requested. For narrow tasks, Anthropic's recommended scope-constraint instruction is:

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.

Opus 5 delegates to subagents more readily than prior models. Anthropic is clear that delegation pays off on genuinely independent, sizeable tracks of work, but multiplies cost and time when applied to small tasks that didn't need splitting. If your harness supports subagents, the guide recommends either explicit criteria for when delegation is warranted, or a deterministic cap on how many agents can spawn:

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.

Note the explicit callback to the verification section: the same instinct that causes over-verification (checking work that's already been checked) shows up again here as using a subagent purely to re-verify, which the guide flags as a specific pattern to prevent.

Opus 5 catches and fixes its own mistakes well without prompting. As with verification, Anthropic's advice is to avoid instructing re-checks it already performs ("double-check your answer," "re-verify before responding") - like explicit verification instructions, these compound with the model's own behaviour and add cost without improving results.

The model also narrates corrections to its own earlier statements more than prior models, which can read as undesirable self-doubt in a user-facing product. To limit correction narration to corrections that actually matter to the user:

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 runs with thinking on by default, spanning five effort rungs: low, medium, high, xhigh and max. Anthropic's recommendation is to start at the default (high) and adjust from your own evals - using low and medium liberally as the primary lever for token cost and response time wherever quality holds, and stepping up to xhigh for demanding coding and agentic work. Teams carrying effort defaults over from an older model are specifically advised to re-run an effort sweep, since Opus 5's lower rungs are meaningfully stronger than equivalent settings on prior models.

Thinking can be disabled, but only at effort high or below - it is not possible to disable at xhigh or max. With thinking disabled, two artefacts can occasionally leak into visible output: a tool call written as plain text instead of a structured call (most common on tool-heavy workloads like search, and the turn completes without the call ever running, with the leaked text persisting in conversation history for later turns), and internal <thinking> or other XML tags appearing directly in the response. Anthropic's primary mitigation for both is simply not to disable thinking - keep it enabled and use a lower effort level to control cost, since thinking enabled at low effort typically outperforms thinking disabled at similar cost. For integrations that must run with thinking off regardless, the guide offers a 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.

One specific pitfall worth flagging: instructions that name thinking tags directly ("don't output thinking tags") are less effective than the general instruction above, and Anthropic notes that a system prompt rule telling the model not to think or not to reason actually increases tag leakage rather than preventing it - the general framing consistently outperforms the specific one here.

Combining the response-length, scope, subagent and self-correction patterns above into one starting point for an agentic coding assistant gives you something close to this - adjust the specifics to your product, but the shape reflects Anthropic's own guidance rather than a generic template:

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.

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.

Do not add a separate verification or double-check step - verify as
part of doing the work, not as an extra pass. Delegate to a subagent
only for large, genuinely independent tracks of work; do not delegate
work you can finish yourself in a handful of tool calls, and never
delegate purely to re-check your own output.

Match the length of written documents to what the task needs. When you
finish, lead with the outcome, then supporting detail.

Treat this as a starting point to validate against your own evals, not a drop-in fix - Anthropic's own framing throughout the guide is that these are levers to pull based on measured behaviour on your specific workload, not universal defaults.

Anthropic's API-level migration note for teams moving from Opus 4.8 to Opus 5 flags two mechanical changes worth knowing before the prompting patterns above: thinking is now on by default (it was opt-in on 4.8 in some configurations), and disabling it is capped at effort high or below rather than available unconditionally. Beyond the API surface, the practical migration checklist from this guide is short: audit your prompts for explicit verification or double-check instructions and remove them, add response-length and narration-cadence instructions if your product needs tighter defaults than Opus 5 ships with, re-run an effort sweep rather than reusing 4.8-era effort settings, and add a subagent-delegation cap if your harness supports subagents and cost matters.

Because Opus 5 performs well on existing Opus 4.8 prompts without changes, none of this is urgent in the sense of breaking anything - it's optimisation, not repair. Teams report the biggest single win from the task-scope and verification-removal patterns specifically, since those directly reduce token spend on large agentic workloads.

• Not a full prompt-engineering course: this covers Opus-5-specific deltas only; Anthropic's separate "Prompting best practices" guide covers techniques that apply across all current Claude models.
• Guidance, not guarantees: Anthropic frames every pattern as a starting point to validate against your own evals, not a universal fix - your task mix may behave differently.
• Thinking-disabled mitigations are imperfect: Anthropic's own advice is to avoid disabling thinking rather than rely on the leak-mitigation prompt as a complete fix.
• Living document: as with any vendor documentation, specifics can be revised after publication - check Anthropic's platform docs directly before shipping prompt changes to production.

Read this closely if you're migrating an agentic coding harness, a subagent-based automation pipeline, or a user-facing chat product from Opus 4.8 to Opus 5 - the verification-removal and subagent-capping patterns specifically can meaningfully cut token spend on large workloads. It's also worth a read if you're building your first Opus 5 integration from scratch, since starting with these patterns beats discovering the need for them through a surprising token bill.

You can mostly skip the tuning (for now) if you're running light, single-turn use of Opus 5 without an agentic harness or subagents - Anthropic's own point is that the model performs well on existing prompts out of the box, and most of this guide's value shows up specifically in agentic, multi-step, cost-sensitive deployments.

Anthropic's official Opus 5 prompting guide is short precisely because Opus 5 needs less prompting, not more - the recurring theme across response length, verification, self-correction and subagent delegation is a model that increasingly does the right thing by default, and the highest-leverage prompt changes are often subtractive: removing the scaffolding that made sense for less autonomous predecessors.

For anyone running Opus 5 at scale, the practical order of operations is: audit for redundant verification instructions first, add scope and narration guidance second, and treat effort level as an ongoing tuning knob rather than a one-time setting. None of it is required to get good results - Anthropic built Opus 5 to work well on prompts that predate it - but each pattern here is a real, measured lever the model's own creator says is worth pulling.