Give it judgment, not a rulebook
Everything else on this page is a consequence of this.
Today's frontier models are being hobbled by products built for yesterday's weaker ones. The biggest opportunity is giving them harder tasks with fewer instructions.
Long rulebooks, step-by-step drip-feeding, "double-check" scaffolding, ALL-CAPS bans, worked examples for everything.
Hand it the complete task up front, state the goal and the guardrails, and let it own the work end to end.
Four behaviors that changed what a good prompt looks like
Opus 5 does these on its own now. Old prompts that also ask for them cause it to over-do them, which burns tokens with no gain.
It self-verifies, unprompted
Opus 5 checks and re-checks its own work without being told to. Explicit "verify" steps stack on top and cause over-verification.
→Remove "double-check", "re-verify", "add a verification step", and verify-subagent scaffolding.
It delegates to subagents readily
A subagent is a second copy of the model that the first one launches to work alongside it. Useful when two halves of a job are independent. Wasteful when it spins one up for something it could finish in a few tool calls itself.
→Give explicit delegation criteria or a hard spawn cap.
It talks more
Longer default answers and more agentic narration. Lowering effort trims thinking, not the visible reply. Conciseness will not happen on its own.
→Ask for brevity explicitly. Effort is not a length dial. Files it writes to disk run long too, and need their own separate length line.
It expands scope on its own
It applies judgment about what the task "should" be, and sometimes adds work you did not ask for. A request to fix one function can come back with the surrounding file tidied as well.
→For narrow jobs, state the scope boundary explicitly.
What to delete from prompts written for 4.8
Edit your prompts like a diff. Anthropic's own guidance: roughly half the advice is about what to remove. Treat your system prompt and your CLAUDE.md, the project instructions file Claude Code reads on every run, as things to prune.
- "Double-check your answer before responding."It already does. Compounds into wasted tokens.
- "Include a final verification step / use a subagent to verify."Causes over-verification with no quality gain.
- "Only report high-severity issues" / "be conservative"It obeys literally and finds less. Ask for everything, filter later.
- NEVER / ALWAYS / DO NOT … (ALL-CAPS bans)Grep them out. Keep only hard product/legal constraints.
- Paragraphs of worked few-shot examplesOn Claude 5 examples shrink the exploration space.
- xhigh as your starting point, inherited from Opus 4.8The API default was already high on both models. What changed is the recommended start: 4.8 said start at xhigh for coding, Opus 5 says start at high and sweep down.
- thinking: {"type":"disabled"} at xhigh or maxHard 400 error on Opus 5. Drop to high or below, or remove the field.
- Rules that call thinking tags out by nameNaming them increases leakage. Use the general form instead.
- One explicit conciseness lineThe only reliable lever on response length.
- A scope boundary: "deliver what was asked, at the scope intended"Stops silent scope creep on narrow tasks.
- A subagent cap / delegation criteriaKeeps cost and latency predictable.
- The complete task spec, up frontThen let it run instead of drip-feeding steps.
- A schema + enum instead of examplesLet the tool definition carry the intent. A status field limited to pending, in_progress and done says more than a sample call, and does not box the model into copying it.
- Narration cadence, if user-facingDescribe the shape of updates you want.
- A length line for Claude-authored filesSeparate lever from conversational conciseness. Reports and Markdown run long.
- A threshold for correcting itself out loudIt narrates its own corrections more than 4.8 did. Limit it to corrections that change your decisions.
- A short reminder near the end of a long system promptAnthropic pairs the conciseness line with a tone_preference tag at the tail.
The effort dial, your primary control
Opus 5 supports all five levels. You start at high (the API default) and reach for low/medium as your primary control for cost and latency. Instead of inheriting 4.8's xhigh starting point, run an effort sweep: the same real task at each level, scored against your own evals, to find the cheapest one that still passes.
Strong quality at a fraction of the tokens. Use liberally where quality holds, and for a fast first review pass.
Your everyday setting for most real work. Sweep down to here before assuming you need more.
The starting point. Good for complex coding and agentic tasks out of the box.
Reserve for demanding coding and agentic work. Raising the dial on a small job costs more without buying quality.
Unconstrained token spending, when the task justifies it. Set a large max_tokens (64k is a reasonable start) at this level and at xhigh.
More effort ≠ more quality. Opus 5 expands scope on its own judgment, and Anthropic documents the same higher-effort tidying and unrequested refactoring on Fable 5. The Circuit, an independent newsletter, describes the failure mode of max on a small job as the model quietly redecorating your codebase. That phrasing is theirs, not Anthropic's. Anthropic's own line is narrower: start at high, sweep down, re-run the sweep on your evals.
Two things the dial does not do. It does not shorten visible responses, only thinking volume, so prompt for length separately. And it is not free to change mid-session: effort shapes the rendered prompt, so switching levels between requests invalidates your cached prefixes. Pick a level at the start of a cached conversation and hold it.
What breaks when you migrate from Opus 4.8
Prompting is only half the migration. Swapping the model ID to claude-opus-5 changes two API behaviours, and only one of them throws.
Thinking is on by default
On Opus 4.8, a request that omitted the thinking field did no thinking. On Opus 5 the same request thinks. Adaptive thinking is now the default, and thinking: {"type":"adaptive"} is equivalent to omitting it.
→Audit every route that relied on thinking-off. Cost and token counts move even though the price per token did not.
Disabling thinking above high is a 400
Setting thinking: {"type":"disabled"} at xhigh or max effort returns an error on every request. Opus 4.8 accepted that combination.
→Either drop effort to high or below, or remove the thinking field. Anthropic would rather you keep thinking on and control cost with lower effort. Thinking on at low effort beats thinking off at similar cost.
max_tokens now covers thinking too
max_tokens is a hard limit on total output, thinking plus response text together. A budget that fit a thinking-off reply can now truncate one.
→Nothing throws when it happens: the call returns 200, stop_reason comes back as max_tokens, and the reply stops mid-sentence. If you log only errors, you will not see it. Raise max_tokens on routes that never set a thinking field, starting around 64k at xhigh and max.
Everything else is drop-in
Same Messages API, same tool-use patterns, same 1M context and 128K max output as 4.8, and the same $5 / $25 per million tokens. Mid-conversation tool changes are available behind a beta header.
→Re-baseline cost on your own workloads anyway. Token counts move even when unit price does not.
The six context-engineering shifts
From "The new rules of context engineering for Claude 5 generation models" by Thariq Shihipar of Anthropic, the framework behind the 80% deletion.
Give the goal, not a rulebook. When it over-does something, remove instructions rather than adding more.
Few-shot examples now narrow exploration. Encode intent in tool schemas and enums instead.
Stop front-loading everything. Let the model pull what it needs on demand, through skills: small instruction files it opens only when the task calls for one.
Consolidate repeated guidance into the tool's own definition, so there is one source of truth.
Stop hand-maintaining notes the tool now keeps for you. Auto-memory writes and recalls that state itself, so the CLAUDE.md entries you kept updating by hand can go.
Replace prose specs with code, test suites, and rubrics the model can execute against.
Copy-paste blocks
Reproduced from Anthropic's official "Prompting Claude Opus 5" guide (linked in Sources) and checked against it on 29 Jul 2026. Drop these into a system prompt as needed.
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.
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.
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.
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.
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.
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.
<tone_preference> Keep outputs reasonably concise. </tone_preference>
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.
Read the last block with its caveat. Use it only if your integration cannot run with thinking on. With thinking off, Opus 5 occasionally writes a tool call as plain text (it never runs, and it stays in history to poison later turns) or leaks internal XML tags. Anthropic's primary fix for both is to keep thinking enabled and lower effort instead. Everything else on this page assumes thinking stays on.
In Claude Code, day to day
How the Claude Code team works with it now.
What was said, and by whom
Two launch-day posts from the Claude Code team, one earlier podcast takeaway, and one independent read. Each card is labelled with what it is.
Opus 5 is our least prompt injectable model yet. Across PI evals and red teaming, it is very hard to prompt inject successfully.
We removed ~80% of the Claude Code system prompt for our newest models. The new rule of thumb: give Claude judgement, not a rulebook.
Push past high and Opus 5 starts making changes the task didn't ask for. The failure mode of max on a small job isn't slowness, it's a model quietly redecorating your codebase.
Every model release, we revisit our products and remove the crutches, the features the model needed before but now handles natively.
Where this is still contested
Almost everything above is Anthropic describing its own model. Worth holding loosely until your evals say otherwise.
The HN thread on the context-engineering post ran to roughly 200 points and 130 comments, and not all of it agreed. One top comment read the advice as moving harness tuning out of a portable CLAUDE.md and into Anthropic-specific tooling. Others reported first-day trouble with auto-memory pulling in unrelated context, and with Opus 5 making more unrequested edits than earlier Opus versions. Several third-party write-ups also report coding scores that stop improving, or fall, past high effort. None publish the setup they tested with, so treat that as a reason to run your own sweep rather than as a result.
Treat the deletion advice as a hypothesis to test, not a migration script. Keep a 4.8 baseline you can diff against. Delete scaffolding in batches and re-run your own evals between batches, rather than stripping the whole prompt in one pass. The advice is written for frontier models: if you also run smaller or older models against the same prompts, the guardrails you delete here may still be load-bearing there.
Sources
Primary Anthropic material first, then the threads, then independent write-ups. Anything tagged unverified is one person's read, not Anthropic's position.
Anthropic, official
X / Twitter threads
Developer write-ups independent · not Anthropic
Compiled by
Anish Gandhi
Production AI Engineer
4,000+ hours delivered 100% job success on Upwork Top Rated Plus
Anish builds AI applications for clients, and most arrive as rescues, where a build demos well then fails in front of real users. One closed 73 bugs before launch. System prompts and agent harnesses get audited the same way, which is what this page is: every claim checked against Anthropic's docs on 29 Jul 2026, anything unverified labelled.