The Claude Model Playbook

How to use every Claude model at its ceiling, and get Fable-5-class output from Opus and Sonnet

Last updated: July 2026. Prices per 1M tokens (input/output).

---

Part 1: The lineup, honestly

The 99.9% mistake: most people pick one model and use it at default settings for everything. The people getting outsized results do two things differently: they route tasks to the right tier, and they change the settings and workflow, not just the model. A well-driven Sonnet 5 beats a lazily-prompted Opus every time.

Routing cheat sheet (for your actual workflows)

---

Part 2: The settings 99% of people never touch

These matter more than which model you pick.

1. Effort (the biggest lever)

output_config: {effort: ...} controls how hard the model thinks and works. Levels: low, medium, high (default), xhigh, max.

• Coding and agentic work: xhigh. This is what Claude Code uses by default. It is the single cheapest upgrade to output quality that exists.

• Most knowledge work: high (the default, so you get this for free).

• When correctness matters more than cost: max. Test it; sometimes it overthinks.

• Volume/routine work: medium or low. Sonnet 5 at medium roughly equals Sonnet 4.6 at high.

In Claude Code: effort is already xhigh. Via API:

client.messages.create(

model="claude-opus-4-8",

max_tokens=64000,

thinking={"type": "adaptive"},

output_config={"effort": "xhigh"},

messages=[...],

)

2. Adaptive thinking

Always set thinking: {"type": "adaptive"} on Opus 4.8 (it's NOT on by default there; omitting it runs without thinking). On Sonnet 5 it's on by default. On Fable 5 it's always on and can't be configured. Never use budget_tokens; it's dead on all current models.

If you show reasoning to users, add "display": "summarized" (the default hides it).

3. max_tokens headroom

At xhigh/max, set max_tokens to 64K+ and stream. A tight budget means the model spends everything on thinking and truncates the answer.

4. Fast mode (when latency hurts)

Opus 4.8 supports fast mode: same model, up to 2.5x faster output, premium price. In Claude Code toggle with /fast. Via API: beta endpoint + speed="fast" + beta flag fast-mode-2026-02-01. Use for live/interactive work, not batch.

5. Prompt caching (for repeated context)

If you send the same big context repeatedly (brand guidelines, audience doc, style guide), put it first in the system prompt with cache_control: {"type": "ephemeral"}. Reads cost ~10% of normal. Keep the stable stuff first, the changing stuff last. Never interpolate timestamps or IDs into the system prompt; one changed byte kills the whole cache.

---

Part 3: Getting Fable-5-class output from Opus and Sonnet

Fable 5's edge is not magic vocabulary. It comes from a handful of behaviors: it plans against a complete spec, verifies its own work, iterates against a definition of done, keeps notes, and delegates in parallel. Every one of those behaviors can be manufactured on Opus and Sonnet with workflow and prompting. Here's the full stack, in order of impact.

Technique 1: The full-spec first turn (free, biggest single win)

All current frontier models do dramatically better when the entire task is specified up front in one turn, instead of dribbled out across a conversation. Ambiguous prompts revealed progressively waste tokens and lower quality.

Template (fill every bracket before sending):

CONTEXT: I'm working on [larger goal] for [who it's for]. They need [what the output enables].

TASK: [the specific deliverable, one sentence]

CONSTRAINTS:

- [format, length, tone, tech stack, things to avoid]

- [things already decided that are not up for debate]

DONE MEANS:

- [checkable criterion 1]

- [checkable criterion 2]

- [checkable criterion 3]

REFERENCE: [paste examples of what good looks like, or link files]

Work autonomously to completion. For minor choices, pick a reasonable option

and note it rather than asking. Ask only if a decision would change the scope.

The "DONE MEANS" section is the part almost nobody writes and it's the part that changes everything, because it enables Technique 3.

Technique 2: The Fable behavior pack (paste into your system prompt / CLAUDE.md)

These are the exact behavioral instructions Anthropic recommends, adapted as a general quality pack. Together they recreate most of what makes Fable 5 output feel better: grounded claims, no over-planning, no scope creep, readable summaries.

\<work_style>

When you have enough information to act, act. Do not re-derive facts already

established, re-litigate decisions already made, or narrate options you will

not pursue. If weighing a choice, give a recommendation, not a survey.

Don't add features, refactor, or introduce abstractions beyond what the task

requires. Do the simplest thing that works well. Only validate at system

boundaries. No error handling for scenarios that cannot happen.

Before reporting progress, audit each claim against actual evidence from this

session. Only report work you can point to. If something is not yet verified,

say so explicitly. If tests fail, say so with the output. Never hedge a done

task and never claim an unverified one.

For minor choices (naming, formatting, defaults, equivalent approaches), pick

a reasonable option and note it rather than asking. For scope changes or

destructive actions, ask first.

\</work_style>

\<communication>

Lead with the outcome. Your first sentence should answer "what happened" or

"what did you find", the thing I'd ask for if I said "just give me the TLDR".

Supporting detail comes after. Readable beats short: be selective about what

you include, but write what you do include in complete sentences with terms

spelled out. No arrow chains, no invented shorthand, no labels I have to

decode. Never use em dashes.

\</communication>

Technique 3: The critique loop (generate, grade, revise)

This is the single most reliable way to beat a bigger model with a smaller one. Fable 5 does an internal version of this; you do it explicitly:

1. Draft with Sonnet 5 (or Opus).

2. Critique in a FRESH conversation (no shared context, so the critic can't be anchored by the draft's reasoning). Use Opus 4.8 as the critic even if Sonnet drafted.

3. Revise with the critique pasted back into the original conversation.

4. Repeat until the critique comes back clean, usually 1 to 2 rounds.

Critic prompt (fresh chat, Opus 4.8):

You are a ruthless editor. Grade this [deliverable type] against the rubric

below. For each criterion: PASS or FAIL, with the specific line or section

that fails and exactly what would fix it. Do not soften findings, do not

filter for importance; report everything, including issues you're uncertain

about, with a confidence level. Coverage matters more than politeness.

RUBRIC:

[paste your DONE MEANS criteria, expanded]

DELIVERABLE:

[paste draft]

Why fresh context matters: a model critiquing its own draft in the same chat defends its earlier choices. A fresh-context critic with only the rubric and the artifact finds real problems. This mirrors Anthropic's own finding that separate fresh-context verifier passes outperform self-critique.

Technique 4: Best-of-N with a judge (for high-stakes creative work)

Sampling parameters are gone on current models, so you get variety through prompting instead. For hooks, headlines, concepts, or design directions:

Generate 5 genuinely distinct [hooks/angles/directions] for [task]. Each must

take a different strategic approach (e.g. contrarian, curiosity gap, data-led,

story-led, direct promise). For each: the artifact plus one line on the

strategy. Do not produce 5 variations of the same idea.

Then judge in a fresh chat:

You are choosing which of these 5 [hooks] to ship to [audience] with the goal

of [metric]. Rank them. For the top pick, explain the mechanism that makes it

work and suggest one sharpening edit. Be decisive.

Cost: 5 Sonnet drafts + 1 Opus judgment is still far cheaper than one Fable call, and for creative selection tasks it frequently wins.

Technique 5: Make the model use its capabilities (they under-trigger by default)

Opus 4.8 and Sonnet 5 are conservative about reaching for search, subagents, memory, and tools. They wait until they're sure. Fix it with explicit trigger conditions:

\<capability_triggers>

Search first: for anything where current information would change the answer

(recent events, prices, versions, trends), search before answering rather than

answering from memory. For open-ended research, start searching immediately.

Delegate: when a task fans out across independent items (many files, many

candidates, many posts to analyze), use parallel subagents rather than

iterating serially. Don't spawn a subagent for work you can do directly.

Memory: before any multi-session task, check the notes file for prior context;

write new findings to it as you go.

\</capability_triggers>

The same trick works at the tool level: tool descriptions that say when to call the tool ("Call this when the user asks about current prices") measurably outperform descriptions that only say what it does.

Technique 6: Give it a memory file

Models perform notably better when they can write learnings somewhere, even a plain markdown file. In Claude Code you already have auto-memory. For API workflows, add:

Maintain LEARNINGS.md. One lesson per entry with a one-line summary. Record

corrections and confirmed approaches, including why they mattered. Consult it

at the start of every session. Update stale entries rather than duplicating;

delete ones that turn out wrong.

Technique 7: The advisor tool (API only): Sonnet body, Opus brain

The advisor tool pairs a cheap executor with a smart advisor consulted mid-generation for planning. Sonnet does the token generation, Opus provides the strategy:

response \= client.beta.messages.create(

model="claude-sonnet-5",          # executor: cheap, fast

max_tokens=16000,

betas=["advisor-tool-2026-03-01"],

tools=[{

"type": "advisor_20260301",

"name": "advisor",

"model": "claude-opus-4-8",   # advisor: consulted for planning

}],

messages=[...],

)

You get Opus-guided output at closer to Sonnet prices. The advisor must be at least as capable as the executor.

Technique 8: De-prescribe your prompts

Prompts written for older models are often too prescriptive for current ones and actively reduce quality. Audit your saved prompts for:

• "CRITICAL: You MUST..." aggressive language: soften to plain instructions, current models follow the system prompt closely and will over-trigger.

• Step-by-step scaffolding ("First do X, then Y, then Z"): replace with the goal and constraints; let the model plan.

• "After every 3 tool calls, summarize": delete, models do this natively now.

• Forced verification steps ("double-check the layout before returning"): delete and re-test; often no longer needed.

State the goal and the definition of done. Enumerate steps only when the order genuinely matters.

---

Part 4: When to actually pay for Fable 5

Don't fight the routing. Some things Opus + workflow can't replicate:

• True long-horizon autonomy. Multi-hour unattended runs where one derailment ruins everything. Fable's coherence over hundreds of tool calls is structurally better.

• First-shot builds of complex, well-specified systems. If you've written a great spec (Technique 1) and the build is genuinely hard, Fable's one-shot rate saves more than the price difference in iteration time.

• The top of your difficulty range. The teams with the best Fable results gave it their hardest unsolved problems first. If Opus has failed at something twice, escalate instead of iterating a third time.

Fable-specific notes: thinking is always on (don't send a thinking param), assistant prefill is gone, single turns can run many minutes (stream, and plan UX for it), and API code should include the Opus 4.8 fallback (fallbacks parameter, beta server-side-fallback-2026-06-01) so a safety-classifier false positive doesn't kill the request.

---

Part 5: The daily operating system (summary)

1. Route by task, not habit: Haiku for grunt work, Sonnet 5 for volume, Opus 4.8 for anything intelligence-sensitive, Fable for the summit.

2. Set effort xhigh for coding/agentic, keep adaptive thinking on, give max_tokens headroom.

3. Write the full spec in turn one, with an explicit DONE MEANS rubric.

4. Install the behavior pack in your system prompt / CLAUDE.md.

5. Never ship a first draft: run the fresh-context critique loop at least once for anything that matters.

6. Best-of-5 + judge for hooks, headlines, and creative directions.

7. Add trigger conditions for search, subagents, and memory.

8. Batch API at 50% off for anything that can wait an hour.

9. Cache your stable context (brand docs, style guides) and keep it byte-identical.

10. Escalate to Fable after two Opus failures, never before one.

Related on MrRaoAI

• Claude Token Optimization, keep sessions cheap after you pick the right model
• 15 free Claude Skills, raise floor quality for design and writing
• Founder One-Pager Prompt, a high-effort prompt that benefits from Opus / Fable

FAQ

Should I always use the most expensive model?

No. Route grunt work to Haiku, volume drafts to Sonnet, intelligence-sensitive work to Opus, and overnight hard builds to Fable. Wrong routing wastes more money than wrong prompts.

What is the biggest setting people ignore?

Effort. Raising effort on the right model often beats upgrading the model on a lazy default setting.

Prices change: is this still useful?

Yes. Treat the routing and workflow sections as the durable part. Re-check vendor pricing when you budget.