Fable 5 Prompting: Five Moves, and the First Is a Deletion

The highest-value edit you can make to a Fable 5 prompt today is a deletion. Anthropic's migration notes are blunt about it: instructions telling the model to echo, transcribe, or explain its internal reasoning as response text can trigger the reasoning_extraction refusal category, which returns stop_reason: "refusal" and, in their words, causes "elevated fallbacks to Claude Opus 4.8". That line — "walk me through your reasoning step by step" — has been free in every prompt library since 2022. On Fable 5 it can quietly cost you the model you're paying $10/$50 per million tokens for, and you won't notice unless you log stop reasons.

That inversion is the theme of the whole document. Anthropic states plainly that skills written for earlier models are "often too prescriptive" for Fable 5 and can degrade output quality. So the job moved: less clever phrasing, more auditing what you already send. Five moves below — what to write, why it works per the docs, and where each one bites back.

1. Delete the show-your-work instructions

Search your system prompts and skill files for "explain your thinking", "show your reasoning", "reflect on", "narrate your analysis". Delete them. Past the refusal risk, they can't do what you want anyway: on Fable 5 the raw chain of thought is never returned. The thinking.display setting decides what arrives instead — "summarized" gives you a readable summary of the reasoning, and "omitted", which is the default, gives you thinking blocks with an empty thinking field.

Backfires when: you genuinely need reasoning visibility for an audit trail. Don't ask for it in prose — set thinking.display to "summarized" and read the structured blocks.

2. Set effort instead of writing "think harder"

effort is the primary intelligence/latency/cost control on Fable 5, and it lives in the request, not the prompt:

{
  "model": "claude-fable-5",
  "max_tokens": 64000,
  "output_config": { "effort": "xhigh" }
}

Five levels: low, medium, high, xhigh, max. The API default is high, and passing "high" is documented as producing exactly the same behaviour as omitting the parameter — so a lot of teams "tuning effort" are shipping the default with extra steps. Begin at high, move to xhigh for the most capability-sensitive work, step down to medium or low for routine jobs. The reassuring part: lower effort on Fable 5 still performs well and, per Anthropic, often beats what xhigh delivered on previous models.

Backfires when: you vary it inside one conversation. Effort shapes the rendered prompt, so changing it between requests discards your cached prefixes — choose a level at the start of a long session and hold it. Two more traps. At high and xhigh you need a generous max_tokens, because that ceiling covers thinking plus response text (Anthropic suggests starting around 64k, against a 128k per-request output maximum). And thinking: {"type": "disabled"} is not supported at all here — adaptive thinking is always on, so effort is the only depth dial you get.

3. Cap the scope in writing when you run high effort

Higher effort is where Fable 5 tidies up things nobody asked about. The doc ships a counterweight:

Don't add features, refactor, or introduce abstractions beyond what the task
requires. A bug fix doesn't need surrounding cleanup and a one-shot operation
usually doesn't need a helper. Do the simplest thing that works well. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Only
validate at system boundaries (user input, external APIs).

Backfires when: you treat it as a reason to drop to medium instead. High effort is also where you get the most rigorous self-verification. Keep the effort and add the guardrail — Anthropic's suggested pairing is an interval check ("Establish a method for checking your own work at an interval of [X] as you build"), verified by fresh-context subagents, which they report outperform self-critique.

4. Make every progress claim point at a tool result

This is the first thing I'd install on anything running unattended:

Before reporting progress, audit each claim against a tool result from this
session. Only report work you can point to evidence for; if something is not
yet verified, say so explicitly. If tests fail, say so with the output; if a
step was skipped, say that; when something is done and verified, state it
plainly without hedging.

Anthropic's claim here is unusually specific: in their testing this "nearly eliminated fabricated status reports", including on tasks designed to provoke them. Six lines against confidently wrong status updates is the best trade in the whole doc.

5. Fix the harness, not the prompt — hide the token countdown

The most surprising item isn't a prompting problem at all. Deep into very long sessions, Fable 5 can start proposing a fresh session, offering to summarize and hand off, or quietly trimming its own work. The docs name the trigger: harnesses that display a remaining-token countdown to the model. So stop surfacing the number. If your UI has to, add the reassurance:

You have ample context remaining. Do not stop, summarize, or suggest a new
session on account of context limits. Continue the work.

Backfires when: the budget is actually tight. Fable 5 ships a 1M-token context window by default, so you usually do have room — but if you genuinely don't, the honest fix is compaction, not telling the model to press on.

The one tool worth adding

For long asynchronous runs, define a send_to_user tool: one message string that your UI renders directly, returning a bare acknowledgement as the tool result. It exists because tool inputs are never summarized, so a deliverable reaches the reader byte-exact without ending the turn. The non-obvious half, straight from the doc: defining the tool is not enough. Without an explicit elicitation line in the system prompt, Fable 5 rarely calls it.

The EM angle

If your team runs Claude in CI or inside an agent harness, stop_reason belongs in your logs and on a dashboard. A slow climb in refusals is not a Claude outage — it's usually one stale instruction in a skill file nobody has reread since the previous model. Five-minute fix, but only if you're measuring it. This is also the cheapest credibility move for a Brazilian dev on an international team: being the person who found the silent downgrade beats being the person with the biggest prompt file.

Today: open the longest system prompt or skill file you own, search it for "reasoning", "step by step" and "explain your", and delete every instruction that asks the model to narrate its own thinking. Then set output_config.effort explicitly in one place in your code, so the level becomes a decision instead of an accident.

Sources

• Claude Docs — Prompting Claude Fable 5
• Claude Docs — Effort
• Claude Docs — Introducing Claude Fable 5 and Claude Mythos 5