I asked Opus how to prompt Opus

A prompt I'd been reusing for a few months started behaving oddly. Longer answers than I wanted. Extra work I hadn't asked for. Nothing broken enough to file a bug about, just… off.

So I did the obvious thing and asked Claude Opus 5 how Opus wants to be prompted now, and how that's changed from the versions before it. Then I pointed it at my own prompt library and had it audit that too, and write up what it found.

This post is that write-up. Opus did the research and drafted the prose; I set the questions, checked the sources it cited, and decided what actually shipped. I'm saying so up front for two reasons. One: a post about how a model wants to be prompted, written by that model, should disclose it. Two: it's the more honest version of the story anyway — the model isn't introspecting here. It's reading Anthropic's published documentation and applying it to my code. That distinction is the whole reason I'm willing to publish the result: every claim below traces to a doc, not to a model's opinion of itself.

What came back was more interesting than I expected, because the first thing it told me was that my prompts weren't the problem.

Our own system prompts are already in good shape: no assistant prefills (they 400 on 4.6+), no temperature, no "be thorough"/"double-check" scaffolding. The problems are in the teaching content, which is written for a pre-thinking-model world.

That's the finding in miniature. A prompt is a per-model artifact. It encodes assumptions about what the model does badly — and when the model stops doing that badly, the workaround doesn't go neutral. It becomes a live instruction that a more literal-minded model now follows.

Here's what changed, split into the parts that break loudly and the parts that break quietly. Sources are Anthropic's migration guide, adaptive thinking and effort pages. Where a number comes from Anthropic's own testing I've said so — neither of us has reproduced those independently.

Part one: the changes that throw errors

These are the easy ones, in the sense that you find out immediately. Three things that used to be normal now return 400.

1. The thinking budget is gone

Fixed thinking budgets — thinking: {"type": "enabled", "budget_tokens": N} — were deprecated on Opus 4.6 and removed from 4.7 onward. The replacement is adaptive thinking plus an effort level: you no longer say how many tokens to think for, you say how hard to work.

# Before (Opus 4.6 and earlier)
client.messages.create(
    model="claude-opus-4-6",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[...],
)

# After (4.7 onward — budget_tokens is a 400)
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},   # low | medium | high | xhigh | max
    messages=[...],
)

There's no arithmetic mapping between the two. A token budget capped how much the model thought; effort scales how much it thinks and acts. Anthropic's guidance is xhigh for coding and agentic work, a minimum of high for anything intelligence-sensitive, and low/medium for routine work — with the note that on Opus 5 the lower levels are unusually strong. Worth actually re-running the sweep rather than inheriting whatever you set two generations ago.

2. Sampling parameters are rejected

temperature, top_p and top_k return a 400 on Opus 4.7 and later. This one catches people out because it isn't a deprecation warning — it's a hard failure on a parameter that's been in every LLM tutorial for years.

It's also the one that caught me. The audit's first concrete hit was a card in my own knowledge base telling readers to run chain-of-thought at temperature 0.7 — advice that is now a 400 on the models it was aimed at:

The self-consistency card tells users to run CoT "at temperature=0.7". temperature is rejected with a 400 on Opus 5, Sonnet 5, Fable 5, and Opus 4.7+. Needs a caveat that on current Claude you get variance from prompting, not sampling params.

If you were at temperature 0 for repeatability: tighten the prompt and drop the effort level. If you were at 0.7 for variety, ask for the variety instead of sampling it:

# Before: variety from the decoder
client.messages.create(model="claude-opus-4-6", temperature=0.9, ...)

# After: variety from the prompt
"Propose 4 distinct approaches to this brief — one line of rationale each —
 then ask me to pick one before you build."

That second form is better than it sounds. You see the options and choose, instead of rolling dice and re-rolling.

3. Assistant prefill is gone

Prefilling the final assistant turn — the old trick for forcing JSON by opening the brace yourself — is a 400 from the 4.6 family onward. The replacement is structured outputs, which constrains decoding to a schema rather than nudging the model with an opening token:

# Before
messages=[
    {"role": "user", "content": "Extract the name."},
    {"role": "assistant", "content": '{"name": "'},   # 400 on 4.6+
]

# After
output_config={"format": {"type": "json_schema", "schema": SCHEMA}}

Worth knowing: the prefill trick usually came with a support structure — stop sequences, a regex extractor, a retry-on-parse-failure loop. Delete the prefill and most of that scaffolding goes with it. Check support on your specific model before relying on it; it isn't uniform across the line.

Part two: the one that fails silently

This is the finding I'd have taken longest to reach on my own, and it's the reason the audit paid for itself. Nothing errors. On Opus 4.7 and 4.8, omitting the thinking parameter meant no thinking. On Opus 5, omitting it means the model thinks anyway — adaptive is the default. And thinking tokens come out of the same max_tokens budget as the visible answer.

I have a grading call that has to return parseable JSON, sized at 1,500 max_tokens against a non-thinking model. Opus flagged it while adding the new models to the picker, before I ever ran it:

On the 5-series, thinking is on by default and thinking tokens share max_tokens with the answer… picking Opus 5 would have burned the budget on thinking and returned truncated text, i.e. unparseable JSON from the grader.

No API error in that failure mode. Just a parse error in my own code, three layers away from the cause. The fix is headroom plus a bounded effort level; the diagnosis is what would have cost me the afternoon.

There's a related trap if you try to solve it by switching thinking off. On Opus 5, thinking: {"type": "disabled"} is only accepted at effort high or below — pair it with xhigh or max and you get a 400. And Anthropic documents two failure modes with thinking disabled on this model: tool calls occasionally get written into the visible text instead of emitted as a tool-use block, in which case the turn completes fine and the call silently never runs; and internal <thinking> tags can leak into the response. Their counterintuitive note is that telling the model not to reason makes the tag leakage worse, and that naming the tags in your instruction is less effective than a generic "no internal XML tags in your response". Leaving thinking on at a lower effort is usually cheaper in every sense.

Part three: the advice that reversed direction

This is the part that shows up in no error log, and it's where I suspect most stale prompt libraries are quietly losing quality.

Delegation flip-flopped — four times

If you want one example of why prompt guidance doesn't transfer between generations, it's subagents. Per Anthropic's own release notes: Opus 4.6 was overeager to delegate and needed reining in. 4.7 spawned fewer than 4.6. 4.8 under-used them and needed encouragement. Opus 5 delegates readily again and needs a cap. Opus's own summary of that, in the knowledge-base entry it wrote:

Model generations disagree about subagents, so guidance doesn't transfer.

Which means a "please delegate more" instruction written for 4.8 — correct for 4.8 — is now actively expensive:

# Written for Opus 4.8 (correct then, wrong now)
"When a task fans out across independent items, delegate to subagents
 rather than iterating serially."

# For Opus 5
"Don't spawn a subagent for work you could finish in a handful of tool
 calls, or to verify your own output. Delegate only genuinely independent,
 sizeable tracks — prefer one subagent over several."

Delete your verification instructions

This one inverts a standard best practice, so it's worth stating plainly: on Opus 5, telling the model to check its work causes over-verification. Anthropic's guidance is that these models verify unprompted, and that removing the instructions reduces the behaviour with no capability regression. It's a delete, not a rewrite:

- "Double-check your answer before responding."      <- delete
- "Include a final verification step for any task."   <- delete
- "Use a subagent to verify the result."             <- delete

Same goes for harness-level scaffolding: a separate verification stage you bolted on for an older model is likely redundant now, and you're paying for it every run.

Length and scope need explicit bounds

Opus 5 writes longer — both conversational responses and the files it produces. The non-obvious part: lowering the effort level does not reliably shorten the visible output. Length is a prompt instruction now, not a knob. Anthropic reports a short conciseness instruction cut user-facing response length by around 20% in their testing.

Scope needs a bound too — these models will apply their own judgement about what the task should be, adding steps you didn't ask for. Anthropic reports their scope-discipline instruction reduced scope changes to nearly zero without producing excessive clarifying questions. Both fit in a few lines:

- Keep responses focused and concise; lead with the outcome.
- Match deliverable length to the task — no filler sections.
- Deliver what I asked, at the scope I asked. If you think the ask is
  wrong, say so in a sentence and proceed as asked.

Stop shouting

This one started earlier in the line, around 4.5/4.6, and it's the most common thing the audit turned up in old prompts. Emphasis written to overcome an older model's reluctance now over-triggers, because these models follow the system prompt closely:

CRITICAL: You MUST use this tool when...   ->   Use this tool when...
Default to using [tool]                    ->   Use [tool] when it improves X
If in doubt, use [tool]                    ->   (delete)
Be thorough. Do not be lazy.               ->   (delete)

When every instruction is marked critical, the marker stops carrying information. And the register of the prompt becomes the register of the output — an anxious prompt gets you a hedging model.

One for the code-review harnesses

A specific trap, documented from 4.7 onward: if your review prompt says "only report high-severity issues" or "be conservative", the model now follows that literally. It finds the bugs, then declines to report the ones it judges below your stated bar. Precision goes up, measured recall goes down, and it reads like a capability regression when it's actually obedience. Ask for coverage at the finding stage — every issue, with confidence and severity attached — and filter in a separate pass.

What we actually changed

The audit came with a diff, which I reviewed and shipped. Across my prompts, my knowledge base and the harnesses around them:

• Deleted every verification instruction and the harness stage that mirrored it.
• Deleted "think step by step" and every progress-narration rule ("summarise every N tool calls") — current models narrate on their own.
• Deleted the delegate-more guidance written for 4.8 and replaced it with a cap.
• Added two lines of bounds: concision, and don't-widen-the-scope.
• Fixed the token budgets on anything that had to return parseable output.
• Softened every CRITICAL: and MUST that wasn't a real constraint.

Note the ratio: five of six are deletions. Opus's own one-line summary when it wrote this up for my knowledge base was "delete more than you add", and that's the shape of the whole migration. The models got better at the things the workarounds were compensating for, which makes the workarounds the problem. (The knowledge base in question is Prompt Composer's, since it's a prompt-engineering tool and had the same stale advice inside it. That's the last I'll mention it.)

On having the model audit its own prompting

Worth being precise about what this exercise was and wasn't, because "I asked the AI about itself" is a genre with a bad reputation and mostly deserves it.

It wasn't introspection. Opus doesn't have privileged access to its own behaviour, and if it had answered from memory I'd have thrown the output away. What it did was read Anthropic's published documentation for each generation, hold four of them side by side, and cross-reference that against my actual code — which is tedious, mechanical work I would have done badly. Every load-bearing claim in this post has a doc behind it, linked. My job was setting the questions, spot-checking the citations, and rejecting the parts I didn't buy.

The one thing it did that I'd call genuinely useful beyond search: it caught the max_tokens problem in code I hadn't asked it to look at, because it was already holding "thinking shares the budget" and "this grader is capped at 1,500" in the same context. That's not self-knowledge. That's just two facts meeting.

Takeaways

• Re-audit prompts at every model release, not every model migration. The API errors force your hand; the behavioural changes don't, and those are the expensive ones.
• Suspect emphasis and prohibitions first. Any line that shouts, or forbids something the model wasn't going to do, is a workaround for a model that may no longer exist. Trace it: which failure, on which model, did this prevent? If nobody can say, test removing it.
• Check every max_tokens value on a thinking-by-default model. This is the one that fails silently and looks like a parsing bug.
• Re-run your effort sweep instead of inheriting a level. The lower levels moved a lot; the setting you picked two generations ago is probably not the one you'd pick now.
• Delete more than you add. If your migration diff is mostly additions, you're probably layering new instructions on top of dead ones.
• Check the docs for your specific model, not the family. Support genuinely differs between 4.7, 4.8 and 5 on thinking defaults, effort levels and structured outputs — the family name won't tell you.
• Use the model for the tedious half. Reading four sets of release notes and diffing them against your own code is exactly the work it's good at — provided you make it cite, and you check.

One caveat on this post: there are deliberately no release dates on any of these generations. I couldn't source them from anywhere I trust, and I'd rather leave a hole than guess. The ordering — 4.6, 4.7, 4.8, 5 — is what the argument needs, and it's what I can support. Everything else is cited above; if a detail looks wrong for your setup, check it against the migration guide before taking either of our words for it. These pages move.