Prompting Claude Opus 5: Stop Telling It to Double-Check

Most migration guides focus on code changes. This one focuses on prompt changes.

Try Apidog today

Claude Opus 5 launched on July 24, 2026, and Anthropic published a dedicated prompting guide alongside it. The important change: several instructions that improved Opus 4.8 make Opus 5 worse—more expensive, more verbose, or, in one case, actively unreliable.

Opus 5 already performs several behaviors that older prompts had to request explicitly. If your existing prompt repeats those instructions, the behavior compounds. You get extra verification passes rather than extra accuracy.

This guide shows the documented behavior changes and provides copy-paste prompt replacements for your system prompt. It also covers two failure modes caused by disabling thinking, which can silently corrupt an agent loop.

For code-level changes, see the Opus 4.8 to Opus 5 migration guide. To compare request and response payloads across prompt versions and settings, use Apidog.

The one-line summary

Opus 5 verifies more, writes more, delegates more, and explains itself more than Opus 4.8.

Your Opus 4.8 prompt was likely designed to push the model toward those behaviors. On Opus 5, the same prompt can push it past them.

The migration work is mostly subtractive:

• Remove global verification instructions.
• Add explicit output limits.
• Bound subagent delegation.
• Define task boundaries.
• Suppress correction narration when output feeds another system.

1. Delete global verification instructions

Anthropic states that Opus 5 verifies its work without being prompted. It may re-read its output, check arithmetic, re-run tests, or inspect edge cases automatically.

Those were useful behaviors to request from Opus 4.8. On Opus 5, repeating them can cause over-verification and increase token usage.

Search your system prompts for instructions like these 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 a specific high-risk operation needs an explicit validation pass, scope it to that operation:

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.

Use scoped verification as a control. Avoid global “verify everything” rules, which become a cost multiplier on Opus 5.

If you are measuring API spend during the migration, combine this with the cache and batch strategies in the Opus 5 pricing breakdown and the guide to cutting a Claude API bill.

2. Set explicit response-length limits

Opus 5 defaults to longer responses than Opus 4.8. This also affects generated deliverables such as reports, summaries, design docs, and READMEs.

Do not use effort as a verbosity control.

The effort parameter controls how much the model thinks, not how much it writes. Moving from xhigh to medium can reduce thinking tokens while leaving the visible response roughly the same length.

Use prompt-level constraints instead:

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 a document, constrain the artifact and define exclusions:

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 changes, limit commentary rather than 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.

For details on what each level changes, see the Opus 5 effort parameter guide.

3. Cap subagent delegation

Opus 5 delegates to subagents more readily than Opus 4.8. In a harness that supports spawning, multi-part tasks may cause it to fan out automatically.

That can be useful, but every subagent has its own context and token cost. Put an explicit limit on delegation for cost-sensitive or latency-sensitive tasks.

Disable delegation completely:

Do not spawn subagents for this task. Handle it in this conversation.

Or allow bounded fan-out:

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.

Avoid delegation for trivial work, such as reading one file or making a decision that the main thread can already make from available context.

If you are building a deliberate multi-agent workflow, see creating Claude Code subagents.

4. Define strict task boundaries

Opus 5 can expand the scope of a narrow request. For example, a request to fix one failing test may also trigger helper refactors, signature changes, or additional test cases.

That behavior can be helpful for broad maintenance work. For surgical changes, it increases review cost and blast radius.

State both the allowed change and the prohibited changes:

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.

The final sentence is important. It gives the model an approved way to report a dependency or issue without making an unrequested change.

5. Suppress correction narration for machine-consumed output

Opus 5 narrates corrections more often than Opus 4.8. When it changes approach mid-response, it may explain the earlier mistake and describe the new approach.

That is useful in an interactive session. It is noise when the response feeds a parser, UI, structured store, or another model.

Use this instruction:

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.

When storing output in structured systems, pair this with structured outputs so the response shape is enforced rather than merely requested.

Thinking-disabled failure modes

The changes above are tuning improvements. Disabling thinking introduces correctness risks.

Anthropic documents two artifacts that can appear occasionally when thinking is disabled with:

{
  "thinking": {
    "type": "disabled"
  }
}

Tool calls emitted as plain text

The model can produce text that looks like a tool call instead of returning a structured tool_use block.

The call does not execute.

In a single chat response, this is easy to spot. In an agent loop, it can silently fail:

1. The loop finds no structured tool call.
2. No tool is executed.
3. The plain-text pseudo-call is appended to conversation history.
4. Later turns interpret that text as if the action already happened.

The error can compound across multiple turns.

Internal XML tags in visible output

Tags such as <thinking> can appear in user-visible output. This is cosmetically undesirable and can also break HTML rendering or downstream parsers.

Do not add a prompt instruction that explicitly names these tags. Including the tag sequence in context can make leakage more likely.

Anthropic’s recommended mitigation is to keep thinking enabled and reduce cost with a lower effort level:

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "low" },
  "messages": [
    { "role": "user", "content": "..." }
  ]
}

This avoids the disabled-thinking artifacts while using the lower-cost end of the effort range.

Also note:

• Combining thinking: {type: "disabled"} with xhigh or max effort returns a 400.
• Disabled thinking is capped at high effort.
• Thinking is now enabled by default.
• Omitting thinking runs adaptive thinking on Opus 5, unlike Opus 4.8 behavior.

If you must disable thinking, validate assistant messages before adding them to your agent history. Reject turns containing an unexecuted call-shaped string in the text body. Fail loudly instead of allowing a phantom tool call into the transcript.

Test prompt changes instead of guessing

You cannot reliably evaluate these changes by reading a prompt. Response length, verification behavior, subagent usage, and tool-call structure appear in token counts and payloads.

You can test this setup in Apidog, an all-in-one API development and testing platform:

1. Create a request for the Anthropic Messages endpoint with "model": "claude-opus-5". Store the API key in an environment variable instead of putting it in the request body.
2. Save your previous Opus 4.8 system prompt and your trimmed Opus 5 prompt as separate requests using the same user input.
3. Compare the usage object in each response. Check output tokens for conciseness and inspect input-token and cache fields to ensure prompt edits did not break a cache prefix.
4. Duplicate the request at multiple effort levels. Confirm that thinking tokens change while visible output length remains similar.
5. Inspect streaming responses and verify that tool calls arrive as structured tool_use blocks, not response text.

Step five catches the plain-text tool-call failure before production. Download Apidog to run side-by-side comparisons, and see the Opus 5 API walkthrough for the full request shape.

The honest ceiling

Opus 5 is not the top of the Claude stack. Fable 5 retains the “most capable widely released” designation, while Opus 5 trails Mythos 5 in cybersecurity exploitation and autonomous biology research.

Anthropic states both points in its launch post. The accurate framing is frontier-class capability at half the frontier price, with a named capability ceiling above it.

The launch benchmark claims for Frontier-Bench, ARC-AGI 3, OSWorld 2.0, and CursorBench are Anthropic-reported numbers and had not been independently reproduced as of July 25, 2026. Treat them as vendor claims and run evaluations against the prompts and workloads you actually ship.

A practical Opus 5 system-prompt baseline

For a cost-sensitive agentic task, start with a system prompt 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.

These are mostly constraints. They do not ask the model to try harder.

That is the main migration shift:

• With Opus 4.8, prompts often raised a behavioral floor.
• With Opus 5, prompts should usually set a behavioral ceiling.

Start with this baseline, then run an effort sweep against your own evaluations because the effort levels were recalibrated.

For implementation details, see:

• The effort parameter guide
• Using Opus 5 in Claude Code
• What Claude Opus 5 is
• Anthropic’s models overview

FAQ

Should I delete “double-check your work” from my prompts?

Yes. Anthropic’s prompting guide says Opus 5 verifies work without prompting, and inherited verification instructions can cause over-verification. Remove the global instruction. Keep explicit checks only for specific high-risk steps.

Why is Opus 5 verbose even at low effort?

Because effort controls thinking rather than visible response length. Lower effort can reduce reasoning tokens without meaningfully shortening output. Set a word limit or output format constraint in the prompt.

How do I stop Opus 5 from spawning subagents?

State it directly:

Do not spawn subagents; handle this in this conversation.

If some delegation is useful, set a numeric maximum and limit it to independent work that can run in parallel.

Why do I see <thinking> tags in output?

This can occur when thinking is disabled. Do not add a prompt instruction that names the tags, because that can increase leakage. Keep thinking enabled and lower the effort level to control cost.

What happens when a tool call comes back as plain text?

Nothing executes. The leaked text can remain in conversation history, where later turns may treat it as a completed action. Validate assistant turns before appending them to history, and prefer enabled thinking over disabled thinking.