Tuning your prompts for Opus 4.8 — dial back what you built to push older models

[jmmarkiewicz]

If you're moving a PAI-style setup to Claude Opus 4.8, here's a pattern worth knowing before you do: a lot of the scaffolding we all built to push older models now works against you.

TL;DR — Opus 4.8 calibrates effort, response length, and thinking depth on its own, follows instructions more literally, and is more proactive by default. The aggressive prompt language we wrote to fight laziness and under-triggering (CRITICAL, MUST, ZERO EXCEPTIONS, "always be thorough," forced tool/subagent use) now causes the opposite problem: over-triggering, over-thinking, and inflated tokens. Everything below is drawn from Anthropic's official Opus 4.8 prompting best-practices guide.

The migration checklist

What you probably have	Why it backfires on Opus 4.8	Fix
CRITICAL: You MUST use this tool…	The model is more responsive to the system prompt and over-triggers on aggressive language	Plain instruction: "Use this tool when…" (Anthropic's own example)
"Always be thorough / go above and beyond" as a default	Opus over-explores and over-engineers at higher effort already	Make it targeted: "Use X when it would improve your understanding," not a blanket default
Custom effort tiers enforced in the prompt (forced step counts, thinking floors)	Duplicates what the model now does natively	Lean on the real effort parameter (low→xhigh/max) + adaptive thinking — the guide calls effort "likely more important for this model than any prior Opus"
Walls of "Never do X. Never do Y."	Negative framing is weaker steering	"Tell it what to do, not what not to do" — positive framing + positive examples steer better
Instructions that assume the model will generalize	Opus 4.8 follows literally and won't silently generalize	State scope explicitly: "Apply this to every section, not just the first"
Forced subagent / parallel-agent use	Opus 4.8 spawns fewer subagents by default and orchestrates well on its own	Remove the forcing; only steer up if you actually see under-delegation
Big, dense system prompt + "think hard" everywhere	Large/complex prompts can make it think more often than you want, adding latency	Trim; steer thinking down explicitly where you don't need it

Before / after

- CRITICAL — MANDATORY — ZERO EXCEPTIONS: every response MUST follow the format.
+ Follow the format below. (It's parsed downstream, so format consistency matters more than length.)

- Never claim something works without checking. "Should work" is forbidden.
+ Assert only what you've verified with tools; replace "should work" with the evidence that shows it does.

Note the second one keeps the rigor — it just states it positively, which steers more reliably.

The one place to keep the strong language

Don't strip everything. Reserve firm, unambiguous language for irreversible / outward-facing actions — deleting data, force-pushing, sending messages, anything that touches shared systems or money. Anthropic's guide has a ready snippet for exactly this (the "balancing autonomy and safety" section). The principle: let the strength of your language correlate with how hard the action is to undo. Everywhere else, calm down — the model is listening more carefully than it used to.

Why this matters for PAI specifically

PAI leans hard on prompt scaffolding by design. That scaffolding was calibrated against models that needed pushing. Opus 4.8 inverts those defaults, so a tuning pass pays off quickly — and the lightest-touch version (just de-escalating imperative language) is low-risk and high-payoff on its own.

Curious whether others migrating to Opus 4.8 are seeing the same over-triggering / over-thinking, and how you're handling effort-tier mapping.

[stephtara]

So, has somebody made modifications to some of the standard PAI instruction files that they would be willing to share?

[jmmarkiewicz]

Hi @stephtara — yes, I went through exactly this on my own setup. Happy to share what I changed.

Short version: I treated it as a tone pass, not a rewrite. The standard PAI files were written for an earlier model generation that needed pushing — lots of ALL-CAPS imperatives, "BE THOROUGH", "ZERO EXCEPTIONS", "NEVER/ALWAYS". Opus 4.8 inverts those defaults: it calibrates effort, length and thinking itself, so that same forcing language now over-triggers — too many tool calls, over-long output, over-thinking on simple turns. The content of the files was mostly fine; the friction was almost entirely in the forcing mechanisms.

What I changed (a deliberate "do no harm" first pass):

• De-escalated the imperative language in the system prompt's Output-Format and Verification sections — turned "YOU MUST ALWAYS… / BANNED / ZERO EXCEPTIONS" into plain instructions with the reason attached. 4.8 follows intent much better when you give it the why instead of shouting the what. E.g. a flat tool ban → "prefer X, because it catches rendering issues Y misses"; a "zero exceptions" runtime rule → "always use bun — npm/npx cause lockfile drift that breaks the next session".
• Same treatment for the tool-trigger language in CLAUDE.md.
• One positive reframe of the verification block — state the behaviour you want, not a wall of prohibitions.

What I deliberately kept aggressive: the irreversible stuff — security, privacy/containment, billing/auth. There, over-caution is free and a miss is expensive, so the strong language stays.

Still on my list (not done yet): mapping the effort tiers onto the real effort API setting instead of duplicating it in prompt-space, softening hard numeric floors into task-scaled guidance, and auditing every rule for "is the rationale stated, or just the command?"

I can't paste my files verbatim (too much personal context in them), but every change above maps straight onto the standard PAI templates, so it should port directly. Happy to go deeper on any specific file.

[stephtara]

Thanks -- so you are doing this all by hand, yourself, correct?

[jmmarkiewicz]

oh no no - I used the Anthropic prompting guideline published alongside Opus 4.8 and asked my "PAI" to thoroughly read through and then self-analyze and propose changes - and then gave it green light to "self-correct" - that's the beauty (and horror) of these set-ups - as they load up the md files at the start (into the system prompt) - they can then redact these files without any effect - until the next session is started and next system prompt gets sent to the LLM Cloud brain.... I

[stephtara]

When I do this kind of thing I somehow regularly end up with more problems than what I set off to résolve in the first place and bloated instructions all over the place... I have to say it's starting to be discouraging!

[chrisglick]

@stephtara - I can feel that pain too. IT's difficult to work in this space because we're actively engaging in a completely new practice; AI's of this capability are, seemingly, incredibly intelligent and incredibly stupid at the same time. And the PAI system is a meta-layer on top of this.

It seems very similar to psychoanalysis, where there is a known gap in self-understanding. If you ask someone to figure out why a certain challenge happens in their life, they can only respond to you from their perspective and with their biases, unconscious judgements, and all the rest of the mess. This is why an impartial 3rd party, the therapist, is needed for an outside perspective. If this is a difficult proposition for us humans, it's doubled for an AI, which has no inherent sense of self and a limited self reflective capacity. So asking any model to improve PAI through it's own distorted views will likely only create larger distortions. This might be one reason that you end up with more problems than when you started.

In my own practice with AI, I try and get laser focused on specific projects and tasks, and only ask for updated instructions/skills around those specific tasks, instead of asking the meta-layer to improve the meta-layer. This forces the AI to focus solely on what worked and what didn't work in the context of our proven work output. I believe this is how Daniel produced the PAI system in the first place.

I'm not sure if this is what you're already doing, I may have misread your process. I largely haven't touched the PAI algorithm or even updated to the latest. I've only asked Claude to improve PAI when, during a reflection session, it specifically told me of competing instructions in it's own CLAUDE.me file and the PAI algorithm which it said were producing inner conflict.

It's a fascinating problem for sure and I'm interested in how people are approaching this issue too.

[jaylarr176]

Curious as to if anyone has any experience with this and model mixing. For example, if Opus 4.8 needs softer language, but Sonnet 4.6 uses the older - is it just not possible to optimally use both at the moment?