How to prompt Claude Opus 5

To prompt Claude Opus 5 well, give it the whole task up front in XML-tagged sections (context, task, constraints, output format), state how long and how broad the answer should be, and leave out “double-check your work” instructions. Opus 5 already verifies its own work and tends to widen scope and write at length unless you bound it.

What makes Opus 5 different

Anthropic positions Opus 5 as its model for long-horizon agentic coding and enterprise work. A few traits shape how you should write for it:

• It finishes whole tasks. Multi-file features and large refactors come back complete rather than stubbed, especially when the full specification is in the first message.
• Long context stays reliable. The context window is 1M tokens, and instruction following holds up across it.
• Thinking is on by default. The model decides how much to think, calibrated by the effort setting.
• Responses run long. Chat answers and files it writes to disk are both wordier than earlier Opus models unless you ask otherwise.
• It takes review instructions literally. Tell it to “only flag serious issues” and it will report less. Ask for everything, then filter in a second pass.

The prompt structure: XML tags

Claude parses XML tags cleanly, which matters most when a prompt mixes instructions, background and pasted material. Use descriptive tag names and keep them consistent across your prompts.

<instructions>
You are a senior backend engineer on a Django codebase.
</instructions>

<context>
The /orders endpoint times out for accounts with more than 5,000 orders.
Orders are paginated in the template, but the view loads every row.
</context>

<task>
Fix the view so it queries only the requested page.
</task>

<constraints>
Keep the response JSON shape identical. Add no new dependencies.
</constraints>

<output_format>
A unified diff, then at most three sentences explaining the change.
</output_format>

<success_criteria>
- The endpoint issues one bounded query per request.
- Existing order-list tests still pass.
</success_criteria>

Not every prompt needs every tag. A one-line fix needs <task> and maybe <context>. Save <success_criteria> for work where “done” is genuinely ambiguous.

For long documents (roughly 20k tokens and up), put the material first, each document in its own <document> tag with a source, and the question last. Anthropic reports noticeably better answers with that ordering.

Be explicit, and explain why

Treat Opus 5 like a very capable new colleague who doesn’t know your conventions. If you want ambitious output, say so. It won’t infer “go above and beyond” from a two-word request.

Reasons beat bare rules. “Never use ellipses” works less well than “this text is read aloud by a speech engine, so avoid ellipses it can’t pronounce”. The model generalises from the reason to cases the rule didn’t name.

Use direct verbs. If you want code changed, write “fix”, “implement” or “refactor”, not “could you suggest”.

Control length and scope

These are the two behaviours most worth tuning on Opus 5.

Length. The effort setting changes how much the model thinks, not how much it writes. To get shorter answers, say so in the prompt: ask for focused, brief responses with short caveats. In a long system prompt, repeat a one-line reminder near the end. For documents it writes to files, ask it to match length to what the task needs and skip filler sections.

Scope. Opus 5 sometimes adds steps nobody asked for. For narrow tasks, tell it to deliver what was requested at the intended scope. If it thinks the request is mistaken, it should say so in a sentence and still do the task as asked.

On formatting, tell it what to do rather than what to avoid (“write in flowing paragraphs” beats “no markdown”). The style of your prompt also leaks into the answer: a prompt full of bullet points invites bullet points back.

Don’t ask it to double-check

Earlier models benefited from “verify your answer before responding”. Opus 5 already checks and corrects its own work, so those lines stack on top of its built-in behaviour and burn tokens without improving results. Remove them.

Success criteria are different, and still useful. Writing down what “done” looks like (tests pass, interface unchanged) defines the target. Telling the model to run extra verification passes doesn’t.

If the model narrates small self-corrections in a user-facing product, ask it to mention a correction only when the error would change the user’s decisions.

Effort levels

Opus 5 offers five effort levels: low, medium, high (default), xhigh and max.

• Start at high and measure against your own evaluations.
• Use low and medium freely as your main cost and latency lever. Quality often holds.
• Reach for xhigh or max on demanding agentic coding. Give those runs a large max_tokens budget.
• Prefer keeping thinking on at low effort over switching thinking off. Anthropic notes that thinking can only be disabled at high or below.

Subagents

Opus 5 delegates to subagents more readily than its predecessors. That pays off for large, genuinely independent work, such as a wide investigation across many files. It wastes time and money on small tasks. Tell it when delegation is appropriate, and don’t let it spawn subagents just to verify its own output.

Moving prompts from Opus 4.8

Existing Opus 4.8 prompts work well as they are. Most worthwhile edits remove things:

1. Delete explicit verification and “re-check” instructions.
2. Replace blanket tool rules (“always use search”) with guidance on when a tool helps.
3. Add a conciseness instruction if length matters.
4. Add a scope boundary for narrow tasks.
5. Cap subagent delegation if your harness supports it.
6. Re-run an effort sweep instead of reusing old defaults.