Most migration guides tell you what breaks in your code. This one is about what breaks in your prompts.
Claude Opus 5 launched on July 24, 2026, and Anthropic shipped a dedicated prompting guide alongside it. That guide documents something worth paying attention to: several instructions that made Opus 4.8 better make Opus 5 worse. Not subtly worse. Measurably more expensive, measurably more verbose, and in one case actively broken.
The reason is simple. Opus 5 already does, on its own, several things you used to have to ask for. When your old prompt asks anyway, the instruction compounds with behavior the model already has. You get double the verification passes, not double the accuracy.
This guide walks through each documented behavior shift with a copy-paste prompt snippet you can drop into your system prompt today. It also covers the two failure modes that show up when you disable thinking, which is the one place where an Opus 5 prompt can produce output that looks fine and silently corrupts an agent loop. If you are still working through the code-level changes, the Opus 4.8 to Opus 5 migration guide covers those separately. And if you want to watch these behaviors change in real request and response payloads, Apidog is a straightforward way to send the same prompt at different settings and diff the results.
The one-line summary
Opus 5 verifies more, writes more, delegates more, and explains itself more than Opus 4.8 did. Your Opus 4.8 prompt was tuned to push a model toward those behaviors. Now it pushes past them.
So the work is subtractive. You are mostly deleting instructions, not adding them. The additions you do make are constraints: be shorter, stay in scope, do not spawn helpers.
1. Delete your verification instructions
This is the big one, and it is the reason for the title.
Anthropic states that Opus 5 verifies its own work unprompted. It re-reads what it wrote, checks its arithmetic, re-runs a test, and looks for the edge case you did not mention. That was the exact behavior everyone hand-prompted into Opus 4.8 with lines like “double-check your work before responding” or “verify each step.”
Carry those lines forward and you get over-verification. The model runs verification passes it would have run anyway, plus the ones you asked for, and you pay for every token of it. On long agentic runs this is a real bill, not a rounding error.
The fix is a deletion. Search your system prompts for these patterns and remove them:
Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.
If you have a genuinely high-stakes step where you want an explicit verification pass, scope it to that step rather than making it a global rule:
Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.
That shape matters. A global “verify everything” instruction on Opus 5 is a cost multiplier. A single scoped exception is a control.
If you are tracking API spend across this migration, the cache and batch levers in the Opus 5 pricing breakdown stack with this one, and our guide to cutting a Claude API bill covers the general levers.
2. Prompt for conciseness explicitly, because effort will not do it
Opus 5’s default responses run longer than Opus 4.8’s. So do its written deliverables: the reports, summaries, design docs, and READMEs it produces when you ask for a document.
Here is the part that trips people up. Lowering the effort parameter does not fix this. Effort controls how much the model thinks. It does not control how much the model writes. Drop from xhigh to medium and you cut thinking tokens while the visible response stays about as long as it was. If you assumed effort was a verbosity dial, your bill will not move the way you expected. The Opus 5 effort parameter guide covers what each level actually changes.
Length is a prompting problem, so solve it in the prompt. Be specific about the ceiling rather than saying “be brief,” which models interpret generously:
Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.
For written deliverables, put the limit on the artifact and name what to drop:
Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.
For code-heavy work, the equivalent constraint is about commentary, not code:
Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.
3. Cap subagent delegation
Opus 5 delegates to subagents more readily than Opus 4.8 did. Given a multi-part task and a harness that supports spawning, it will fan out.
That is often the right call. It is also a cost decision the model is making on your behalf, and each subagent carries its own context and its own token bill. For cost-sensitive or latency-sensitive workloads, put a number on it rather than leaving it to the model’s judgment:
Do not spawn subagents for this task. Handle it in this conversation.
Or, when fan-out is genuinely useful but should be bounded:
You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.
The pattern to avoid is delegation for its own sake: a subagent spawned to read one file, or to make a decision the main thread already had the context to make. If you build with subagents deliberately, our guide to creating Claude Code subagents covers the harness side of scoping them.
4. Constrain scope explicitly on narrow tasks
Opus 5 expands task scope. Ask it to fix a failing test and it may also refactor the helper the test calls, update the type signature, and add two more test cases. Ask it to rename a variable and it may tidy the surrounding function.
Sometimes this is a feature. On a narrow, surgical task it is not: an unrequested refactor means a bigger diff for a reviewer to read and a bigger blast radius for a change that was supposed to be one line.
State the boundary as a boundary, and name what is off limits:
Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.
That last clause is the useful half. Without it the model has no sanctioned way to raise a real problem, so it either makes the change anyway or drops the observation. With it, you get a flagged concern and an unchanged diff.
5. Expect more correction narration, and turn it off if you do not want it
Opus 5 narrates its corrections more than Opus 4.8. When it changes its mind mid-response, it tells you: it flags that an earlier approach was wrong, explains why, and describes the switch.
For interactive work this is useful. For a pipeline where the response feeds a parser, a UI, or another model, that narration is noise sitting in a field that is supposed to hold an answer.
The instruction is short:
Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.
If you route responses into structured storage, pair that with structured outputs so the shape is enforced rather than requested.
The thinking-disabled failure modes
Everything above is a tuning problem. This part is a correctness problem.
Anthropic documents two artifacts that show up occasionally on Opus 5 when thinking is disabled via thinking: {type: "disabled"}. Both are worth knowing before you ship an agent.
Tool calls written as plain text. The model emits something that looks like a tool call, but as text in the response body rather than as a structured tool_use block. Nothing executes. In a single-turn chat you would notice. In an agentic loop you often do not: the loop sees no tool call, so it takes no action, and the leaked text stays in the conversation history. Later turns then read that text as if a call had happened. The failure compounds across turns, and by the time output looks wrong the cause is several turns back.
Internal XML tags in visible output. Tags like <thinking> appear in the response the user sees. Cosmetically bad on its own, and worse if you render responses as HTML or parse them for structure.
The counterintuitive part: naming the tags in your prompt makes leakage worse, not better. An instruction like “never output <thinking> tags” puts the token sequence in context and raises the odds it appears. Do not write that instruction.
Anthropic’s own recommended mitigation is not a prompt at all. It is to keep thinking enabled and control cost with a lower effort level instead:
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
That gets you the cheap end of the range without the disabled-thinking artifacts. It also sidesteps a related trap: on Opus 5, combining thinking: {type: "disabled"} with effort xhigh or max returns a 400, because disabling thinking is capped at high effort. Note too that thinking is now on by default, so a request that simply omits the thinking field runs with adaptive thinking rather than without it, as it would have on Opus 4.8.
If you have a hard requirement to disable thinking, add a defensive check in your loop rather than a prompt instruction: reject any assistant turn whose text body contains an unexecuted call-shaped string before appending it to history. Fail loudly instead of letting a phantom call into the transcript.
Test the changes instead of guessing
Prompt changes are hard to evaluate by reading them. The behaviors here (response length, verification passes, subagent count) show up as token counts and payload structure, which means the honest way to check your work is to send the requests and compare.
That is straightforward to set up in Apidog, which is an all-in-one API development and testing platform:
- Build one request against the Anthropic Messages endpoint with
"model": "claude-opus-5", and store your API key as an environment variable rather than pasting it into the body. - Save your old Opus 4.8 system prompt and your trimmed Opus 5 version as two saved requests against the same input.
- Compare the
usageblock on each response. Output tokens tell you whether the conciseness constraint landed; input tokens and cache fields tell you whether your prompt edits broke a cache prefix. - Duplicate the request across effort levels to see for yourself that thinking tokens fall while visible length holds.
- Inspect the streaming response to confirm tool calls arrive as structured
tool_useblocks and not as text.
Step five is the one that catches the plain-text tool-call failure before it reaches production. Download Apidog if you want to run these side by side, and see the Opus 5 API walkthrough for the full request shape.
The honest ceiling
Worth saying plainly, since prompting guides tend to read like the model is the last one you will ever need: Opus 5 is not the top of the Claude stack. Fable 5 keeps the “most capable widely released” designation, and Opus 5 still trails Mythos 5 on cybersecurity exploitation and autonomous biology research. Anthropic says both of these in its own launch post. The accurate framing is frontier-class capability at half the frontier price, with a named ceiling above it.
The launch benchmark claims (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) are all Anthropic’s own numbers and have not been independently reproduced as of July 25, 2026. Treat them as vendor-reported, and run your own evals on the prompts you actually ship.
Putting it together
A trimmed Opus 5 system prompt for a cost-sensitive agentic task looks roughly like this:
Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.
Six lines, five of which are constraints and none of which ask the model to try harder. That is the shift. On Opus 4.8 you prompted to raise a floor. On Opus 5 you prompt to set a ceiling.
Start there, then run an effort sweep on your own evals rather than carrying your 4.8 settings over, since the levels were recalibrated. For the parameter mechanics see the effort parameter guide, for the editor-side workflow see using Opus 5 in Claude Code, and for the full model picture start at what Claude Opus 5 is. Anthropic’s models overview has the current spec table.
FAQ
Should I really delete “double-check your work” from my prompts? Yes. Anthropic’s prompting guide says Opus 5 verifies unprompted, and carried-over verification instructions cause over-verification. Delete the global rule. If one specific step genuinely needs an explicit check, scope the instruction to that step only.
Why is Opus 5 so verbose even at low effort? Because effort controls thinking, not visible output length. Lowering effort cuts reasoning tokens while responses stay roughly as long. Set a word or format limit in the prompt itself.
How do I stop Opus 5 from spawning subagents? Say so directly: “Do not spawn subagents; handle this in this conversation.” If some fan-out is useful, give a numeric cap and restrict it to independent parallel work.
Why am I seeing <thinking> tags in my output? That artifact appears occasionally when thinking is disabled. Do not add a prompt instruction naming the tags, since that makes leakage more likely. Anthropic’s recommended fix is to keep thinking enabled and use a lower effort level to control cost.
What happens if a tool call comes back as plain text? Nothing executes, and the leaked text stays in the conversation history where later turns treat it as a completed action. Validate assistant turns before appending them to history, and prefer keeping thinking on rather than disabling it.
