Start by cutting every line that tells it to check its own work

This is the first thing to do in the whole document. The lines you're hunting for come in two flavors, and both will look familiar.

The first is task-level verification: "include a final verification step for any non-trivial task," "use a subagent to verify." The second is response-level self-checking: "double-check your answer," "confirm before you respond." Same treatment for both — delete.

The cleanup goes beyond your prompt text. The doc calls this out specifically: if the harness you built for older models contains a separate verification stage, tear that out too. The prompt is what you say to the model; the harness is the code wrapped around it that decides when to call the model, how many times, and with what. Both layers need clearing.

Ask a review prompt for "only the serious ones" and you'll get fewer

This is the least intuitive item in the guide, and the easiest one to trip over inside your own automation.

Start with what's working: Opus 5 reviews code with high precision and high recall. A large share of what it flags in any given pass is a real bug, and most of the extra findings are genuine too, not noise padding the list. More usefully, that precision holds up at lower effort settings — so you can do a cheap fast sweep first, then a deeper pass.

The trouble starts with where you put the filter. If your prompt says "report only high-severity issues" or "be conservative," Opus 5 may follow that literally and report less. The doc's fix is to move filtering out of the prompt entirely: let it report everything, then run a separate pass to filter.

Reduced to its core, the difference between the two is who decides what counts as serious. Put it in the prompt and that judgment happens inside the model, out of your view. Run it as a separate pass and the judgment stays with you.

It got wordier in three separate places, and each needs its own fix

Opus 5's user-facing responses run longer than the previous Opus. The instinct is to dial down effort and save some words, but that path doesn't work — first you need to understand what the effort parameter actually controls.

effort governs how many tokens the model is willing to spend thinking, not how much it ends up saying. Turn it down and thinking shrinks, but visible response length doesn't necessarily follow. If you want shorter answers, you have to ask for them explicitly.

One: the user-facing response

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.

If your system prompt is long, there's a companion move: append a short reminder at the end of it, paired with the block above.

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

Two: files written to disk

This is a separate problem from chat verbosity and needs its own fix. Reports, Markdown docs, and summary files that Opus 5 writes also run longer than before. If your product has it generate documents for users, give it an 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.

Three: narration while it works

In agentic settings — where you turn it loose to run on its own — Opus 5 likes to talk: it announces what it's about to do before acting, and each message runs longer than before. To bring that down, don't order it to be quiet. Describe the rhythm and shape you want.

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.

Want it to narrate more, or in a different style? Same lever, opposite direction. There's a general craft lesson hiding here too: showing a positive example of the communication style you want beats listing a pile of don'ts.

It spawns subagents more eagerly, including for small jobs

A subagent is a chunk of work the main model hands off to a freshly spawned instance, which finishes it independently and hands the result back. Each instance reads its own copy of the context and generates its own output, burning its own tokens.

Opus 5 delegates more readily than its predecessor. On genuinely independent, substantial tasks — a wide investigation spanning many files, say — that pays off. On small tasks, cost and time multiply.

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.

One line in that block links back to section 2: do not use subagents to verify your own work. The same habit gets blocked twice — once at the verification behavior itself, once at the delegation habit that carries it.

There's a harder version too: if your harness supports it, hard-code the maximum number of subagents. The prompt persuades; a cap in the harness enforces. For cost-sensitive setups, do both.

It will expand the job on its own

Beyond over-verifying, Opus 5 also broadens task scope by itself: adding steps nobody asked for, or applying its own judgment to redefine what the task should be. For narrow, well-defined tasks, you need to nail the boundary down.

The block the doc supplies here is the longest and most carefully constructed of the eight. It defends against four different kinds of drift at once — worth unpacking sentence by sentence:

The phrasing here sits very close to several passages in Claude Code's default system prompt — that's our observation, not something the doc addresses. If you've written similar boundary constraints into your own project, you can diff them against this and fill in what's missing.

Thinking is on by default, and turning it off invites two failure modes

There's one real mechanical change between Opus 5 and the previous generation. On Opus 4.8, omitting the thinking field meant no thinking. On Opus 5, that same request runs with thinking on. To get the old behavior, you have to add thinking: {"type": "disabled"} yourself.

And that switch is conditional: disabling thinking is only allowed when effort is high or below. Pair it with xhigh or max and you get a 400 back, validated per request. (The error code and the per-request validation come from Anthropic's migration guide; the effort ceiling itself is stated in the prompting page.)

Once thinking is actually off, two problems surface occasionally. The first is the expensive one, because it's silent.

This shows up most often in tool-heavy work — search tasks, for example. The second failure mode is easier to spot: the model leaks internal tags like <thinking> into the response users can see.

That second one comes with a counterintuitive trap. If your system prompt contains a rule telling the model "do not think" or "do not reason," delete it — that kind of instruction makes the tag leakage worse. By the same logic, naming the thinking tag specifically works less well than a generic phrasing, which is why the mitigation block below doesn't mention a single tag name.

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.

Each sentence targets one cause. The first grants permission to speak before calling a tool, so the model doesn't have to cram its prose into the call. The second offers an escape route when no tool fits, so it doesn't force one. The third is a general tag ban that names no specific tag.

Picking among five effort levels, and the combination that returns a 400

The prompting guide itself covers effort in a single paragraph; the full table lives in Anthropic's Effort documentation. The material in this section comes mainly from that page and the migration guide, not from the prompting guide.

The recommendation for Opus 5: start at the default high, then move in either direction based on your own evals. Push hard coding and agentic work up to xhigh, and reserve max for tasks worth spending anything on. Use low and medium freely — as long as your evals show quality holding, treat them as your first lever for controlling token cost and latency.

That starting point differs from the previous generation, which is worth calling out. Anthropic's official advice for Opus 4.8 was to start coding and agentic work at xhigh; for Opus 5 it's "start at high." The same capability rundown adds another line: low and medium now deliver strong quality at a fraction of the tokens and latency of the higher levels.

Prompt caching stores the unchanging opening of your prompt so that sending it again costs neither compute nor wait time. Dropping the threshold from 1024 to 512 means prompts that were previously too short to cache now qualify.

Three follow-up moves, all of which come up in any automated pipeline. First, when migrating from an older model, don't copy your old effort settings across — assemble a set of the real tasks you run most and compare old settings against new. Second, tasks that ran without thinking on Opus 4.8 will now run with it, and since max_tokens caps thinking plus response together, that value needs another look. Third, changing effort invalidates the prompt cache: in a long cache-dependent session, pick a level at the start and stay there — switch between tasks, not mid-task.

The one-pager: what to cut from your old prompts, and what to add

Everything above, compressed into a list you can act on. The three deletions come first because they cost nothing and pay off immediately.

One more block, not covered above

Opus 5 catches and fixes its own earlier mistakes, which is good — but it's also more inclined than its predecessor to announce "I was wrong a moment ago" in front of the user. For user-facing products, this block trims correction narration down to the cases that actually matter.

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.

What the doc doesn't give you

"Longer responses," "more narration," "more eager to delegate" — all qualitative, not a single percentage. How much longer, how much more? Readers have no way to know; you have to run your own comparison. Same with "deleting verification instructions saves tokens without hurting quality" — a conclusion, offered without supporting data. And "thinking on at low effort beats thinking off" is likewise a judgment, not a measured number.

What is solid is the eight prompt blocks themselves. They're copy-paste material, and whether they help is one before-and-after run on your own regular workload away.

Two flavors, both familiar: task-level ("add a verification step at the end," "use a subagent to review") and response-level ("double-check your answer").

The cleanup goes beyond the prompt. If the harness you built for older models — the code wrapped around the model that decides when and how often to call it — has a standalone verification stage hanging off it, tear that out too.

Opus 5 reviews code with high precision and recall, and holds that precision at lower effort — good for a fast sweep followed by a deeper pass. What breaks is where you put the filter.

Opus 5 talks more than its predecessor and delegates more eagerly. The first instinct is to lower effort — the dial that controls how many tokens it spends thinking. That path doesn't work.

• User-facing response — ask for brevity; for long system prompts, append a short reminder at the end
• Documents on disk — report and file length is its own layer, calibrated separately
• Progress narration — describe the rhythm you want; positive examples beat a pile of prohibitions
• Subagents (a chunk of work handed to a fresh instance that burns its own tokens) — delegate only genuinely parallelizable work; three agents on a small job multiply both the bill and the wait
• Task scope — let it object in a sentence, then require it to finish as specified: no quiet narrowing, widening, or transforming

Counting "less announcing of its own corrections" and the disabled-thinking mitigation, the doc supplies eight English prompt blocks you can paste straight into a system prompt; the full article walks through each one.

On Opus 4.8, omitting the thinking field meant no thinking. On Opus 5, the same request runs with thinking on. Disabling it takes an explicit line, and only works when effort is high or below.

Those three figures come from Anthropic's Effort documentation and migration guide, not from the prompting page. As for "longer responses" and "more eager to delegate," Anthropic gives no percentages — you'll have to run your own comparison.