❓ The problem: only the "what," never the "why"
🧠 Imagine it this way: a language model can’t read minds—it predicts the most likely next token based on the text it has already seen. If your prompt only says WHAT (“write a function that validates email”), Fable 5 has to GUESS what it’s for, who will use it, and what “good” means here. It usually guesses well... until it doesn’t.
At its core, an LLM is a machine for next-token prediction. It doesn't have access to what's in your head—only to the prompt text. A request that describes only the task ("do X") leaves a gap: why X matters, who it's for, and what the quality criteria are. The model fills that gap with the statistically most common interpretation for that type of request, which may or may not be yours.
The cost of this “guess” grows with the model’s autonomy. Fable 5 was built to keep instructions in long-horizon runs, sometimes spanning multiple days. If the real intent wasn’t provided at the start, it doesn’t fail fast and ask—it executes for hours in the wrong but plausible direction, and you only discover the detour after it has already cost time and tokens.
💡 Main concept
Token forecast ≠ mind reading. The “why” isn’t polite window dressing in the prompt—it’s the missing data the model needs to choose among several equally valid ways to carry out the same “what.”
✗ Just what
"Write a function that validates email."
The model doesn’t know whether a false positive or a false negative is more costly here — so it will choose on its own.
✓ What + why
"Write a function that validates email because we’re filtering spam sign-ups before they reach the CRM — false negatives are worse than false positives here."
Now the criterion for "right" is explicit. The model decides in line with your direction, not the statistical average.
In one sentence: without the why, Fable 5 can’t read your mind — it predicts the next token and guesses the missing context.
🧩 The why formula in practice
🧠 Imagine it this way: instead of just asking for the task, you provide the full brief—what’s at stake, who it’s for, and what the answer needs to enable. It’s the difference between shouting an order and giving a real brief.
This is an established prompt engineering practice in general—not a direct quote from Fable 5’s official documentation (the source video already made the case, and the research did not confirm a specific verbatim statement for this technique). Treat it as a solid recommendation, not as an “official rule set in stone.” The formula has four parts: a larger task (the project this fits into), who (who depends on the result), what the output enables (the decision or action that comes next) and only then the request concrete.
Notice the order: the why comes before of the request, not as a footnote afterward. This matters because the model weighs context more heavily when it’s closer (in terms of attention) to the final request—a “why” tacked on at the end of the prompt carries less weight against the request itself.
Copyable model/formula — EN and PT-BR
I'm working on <bigger task, e.g. "security review of the payments API"> for <who, e.g. "the compliance team">. They need <what the output enables, e.g. "a prioritized list of vulnerabilities with severity, to decide what to fix before release">. With that: <concrete ask, e.g. "review auth.py and payments.py and list the risks found">.
Estou trabalhando em <tarefa maior, ex.: "revisão de segurança da API de pagamentos"> para <quem, ex.: "o time de compliance">. Eles precisam de <o que a saída habilita, ex.: "uma lista priorizada de vulnerabilidades com severidade, pra decidir o que corrigir antes do release">. Com isso: <pedido concreto, ex.: "revise auth.py e payments.py e liste os riscos encontrados">.
Step 1 — Larger task
What project or goal does this fit into? It’s not the command in isolation, but its broader context.
Step 2 — Who
Who will use, read, or depend on the result? A compliance team wants something different from a solo dev.
Step 3 — What the output enables
What decision or action comes after the response? That determines the right format and priorities.
Step 4 — The request
Only now comes the concrete request — after the model already knows why it matters.
🔬 Copy-run example: system prompt before and after
Goal: show, in a real system prompt for a PR review agent, how the why changes what the model prioritizes—without changing the requested “what.”
🇬🇧 EN
❌ BEFORE (what only): "You are an agent that reviews Pull Requests. Point out bugs and style suggestions." ✅ AFTER (what + why): "You are an agent that reviews Pull Requests for a team that ships to production 3 times a day and has no dedicated QA. The goal of this review is to catch what would break production — not style. They need a short, prioritized list (bugs > security > logic), because long, nitpick-heavy reviews get ignored. With that: review the attached diff and list only what would block the merge."
🇧🇷 Brazilian Portuguese
❌ ANTES (só o quê): "Você é um agente que revisa Pull Requests. Aponte bugs e sugestões de estilo." ✅ DEPOIS (quê + porquê): "Você é um agente que revisa Pull Requests para um time que faz deploy 3x ao dia e não tem QA dedicado. O objetivo desta revisão é pegar o que quebraria produção — não estilo. Eles precisam de uma lista curta e priorizada (bugs > segurança > lógica), porque revisões longas e cheias de nitpick são ignoradas. Com isso: revise o diff anexado e liste só o que bloquearia o merge."
How to check: run both versions against the same diff and compare the output. The “before” version tends to return a long, generic list (including style nitpicks); the “after” version prioritizes what would break production, in the right order. If the “after” output is still generic, the reason wasn’t explicit enough — reinforce it with concrete numbers/criteria.
In one sentence: a larger task + who + what the output enables + request—in that order; the why comes before the what.
📏 Why this matters even more with Fable 5
🧠 Imagine it this way: it’s the difference between making a wish to a literal genie and asking a friend who "gets the spirit" of your request. Fable 5 is the literal genie—extremely good at it, which cuts both ways.
Weaker models in instruction-following often “soften” ambiguous requests using common sense learned during training — sometimes accidentally getting your intent right even when you haven’t stated it explicitly. Fable 5 follows exactly what was requested. The official docs describe the benefit as: "Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name." (source: official doc "Prompting Claude Fable 5" — technique 6, "say less, not more," expanded in module 1.5; translation: "instruction-following has improved enough that you can guide most behaviors with a brief instruction instead of listing every behavior by name.")
That strength becomes a risk precisely when the why is missing: without it, Fable 5 won’t accidentally “guess well” the way a weaker model sometimes does—it follows the literal request to the letter, even if that misses the real goal behind it. The stronger the instruction follower, the more costly a poorly specified request becomes.
→ Weak instruction follower
- • Fills gaps with common sense from training
- • Sometimes “gets it right by accident” without the why
- • Deviates from the literal request more often
✓ Strong instruction-follower (Fable 5)
- • Does exactly what was asked
- • Without the why, it follows the literal request—even when that’s wrong
- • With the why, gets it right on the first try much more consistently
In one sentence: the more literal the instruction-follower, the more expensive it is to make a request without explaining why.
⚠️ The hidden trigger: asking it to “show its reasoning”
🧠 Imagine it this way: It seems harmless to ask “explain your reasoning”—it’s the kind of phrase any old “be transparent” skill might use. With Fable 5, it can trigger a safety refusal and silently switch models.
There's a direct irony with the rest of this module: asking the model to explain why you did something in the response text itself it’s the wrong way to get transparency. Prompts, skills, and harness instructions that ask the model to echo, transcribe, or narrate its internal reasoning as part of the response fall into a specific safety category—and that’s specific to Fable 5, not generic behavior from any Claude.
This usually comes from skills migrated from older models, where "show your reasoning step by step" was a valid prompting technique. In Fable 5, the right channel for this already exists—the thinking blocks — and asking for it to be duplicated in the text response is itself the risk trigger (see topics 5 and 6).
⚠️ Watch out: phrases that seem harmless
If a skill, system prompt, or harness tells the model to “explain,” “transcribe,” or “echo” its own reasoning in the response visible to the user, it may trigger the safety refusal discussed in the next topic—even if the intent is simply to “be transparent.”
✗ Triggers the filter
- • "Explain your reasoning in the response."
- • "Show how you thought, step by step."
- • "Think out loud and write everything before the final answer."
✓ Safe
- • "Answer directly with the result."
- • "If you need to record decisions, use an action changelog — not a narration of your reasoning."
- • Need real visibility? → topic 6: read the thinking blocks.
In one sentence: asking Fable 5 to reproduce its reasoning in the text response is a safety trigger, not a neutral request.
🚦 reasoning_extraction: the silent fallback to Opus 4.8
🧠 Imagine it this way: it's not an error that shows up with a red alert — it's a stop_reason: "refusal" inside a normal HTTP 200 response. If you don’t know to look for it, your app keeps running, just silently on a cheaper model.
The official refusals-and-fallback documentation defines four possible categories in stop_details.category: cyber, bio, frontier_llm and the one that matters here, reasoning_extraction. This is exactly the trigger from the previous topic.
📊 Official data — category definition
🇬🇧 EN (official, doc "refusals-and-fallback"): "The request asks the model to reproduce its internal reasoning in the response text. To get reasoning in a structured form instead, use adaptive thinking."
🇧🇷 PT-BR (translation): "The request asks the model to reproduce its internal reasoning in the response text. To get the reasoning in a structured form, use adaptive thinking."
When this triggers, the refusal happens before any output and is not billed. There are three ways to configure an automatic fallback to Claude Opus 4.8 when this happens: server-side fallback (Claude API / Claude Platform on AWS, via beta header), SDK middleware (BetaRefusalFallbackMiddleware) or a manual retry with "fallback credit". In all three cases, if you don't audit your skills/prompts, the fallback becomes a silent leak in quality and cost — the app "works," just with a different model than you think you're using.
🔬 Copy-run example: auditing existing skills
Goal: having an official Anthropic checklist for auditing old prompts/skills for instructions that ask the model to "show its reasoning" in the text—the exact trigger for topic 4. This is the official briefing text, used as an example of what DON’T / of what audit on existing skills (this isn’t a prompt to “run directly” on the task—it’s the policy you paste at the top of a CLAUDE.md, or give an agent as instructions for auditing the skills repository itself).
🇬🇧 EN (official — doc "Prompting Claude Fable 5")
Don't instruct Claude to reproduce its reasoning in the response. Prompts, skills, or harness instructions that tell the model to echo, transcribe, or explain its internal reasoning as response text can trigger the reasoning_extraction refusal category on Claude Fable 5, causing elevated fallbacks to Claude Opus 4.8. Audit existing skills and system prompts for reflection or show-your-thinking instructions when migrating. If your application needs reasoning visibility, read the structured thinking blocks from adaptive thinking instead.
🇧🇷 PT-BR (translation)
Não instrua o Claude a reproduzir o raciocínio dele na resposta. Prompts, skills ou instruções de harness que pedem pro modelo ecoar, transcrever ou explicar o raciocínio interno como texto de resposta podem disparar a categoria de recusa reasoning_extraction no Claude Fable 5, causando fallbacks mais frequentes pro Claude Opus 4.8. Ao migrar, audite skills e system prompts existentes em busca de instruções de reflexão ou "mostre seu raciocínio". Se sua aplicação precisa de visibilidade do raciocínio, leia os blocos estruturados de thinking do adaptive thinking em vez disso.
How to check: grep your skills/system prompts repository for phrases like "explain your reasoning", "show your thinking", "reproduce your reasoning" (and the Portuguese equivalents from topic 4). If you find any, it's a candidate for reasoning_extraction — replace it with the reading on thinking blocks (topic 6) and monitor the fallback rate to Opus 4.8 before and after the fix.
In one sentence: reasoning_extraction is a stop_reason: refusal as HTTP 200—audit your skills before it becomes a silent fallback to Opus 4.8.
🔍 The alternative: read the thinking blocks, don’t ask it to “tell you”
🧠 Imagine it this way: instead of asking the actor to narrate the behind-the-scenes details in the middle of the scene, you read the behind-the-scenes script separately. The adaptive thinking already separates the two channels—the job is to read the right channel, not force both into one.
If your application needs real visibility into reasoning — for debugging, auditing, or logging — the right answer isn't to ask the model to rewrite its reasoning in the text the user sees. It's to read the structured thinking blocks that adaptive thinking already produces, in a channel separate from the final response. This preserves both things at once: the model thinks as much as it needs to, and you have visibility — without triggering topic 5.
In practice, this is a change of where the instruction says: instead of "explain your reasoning in the response", the instruction (or your harness code) becomes "read the reasoning in the thinking block". See the official adaptive thinking documentation for the exact API configuration.
Illustrative response structure (not a verbatim quote from the docs—just shows where each channel goes)
{
"content": [
{ "type": "thinking", "thinking": "...raciocínio interno estruturado..." },
{ "type": "text", "text": "...resposta final que o usuário vê..." }
]
}
How to check: if your application needs to audit decisions, read the blocks with type === "thinking" in your code, instead of instructing it to "explain your reasoning" in the prompt. Confirm that the type === "text" the final output stays clean, direct, and free of behind-the-scenes narration—and the fallback rate to Opus 4.8 (topic 5) doesn’t increase.
✗ Ask it to reproduce in the text
"Explain your reasoning before answering." → risk of reasoning_extraction + silent fallback.
✓ Read the thinking blocks
Enable adaptive thinking and read type: "thinking" in your code. No trigger, with real visibility.
In one sentence: reasoning visibility lives in the thinking blocks, not in the response text.
📚 Sources for this module
- • Prompting Claude Fable 5 (official docs — techniques and code boxes)
- • Refusals and fallback (official docs — reasoning_extraction category)
- • Adaptive thinking (official docs — thinking blocks)
🧾 Module Summary
Next module:
1.3 — Negative prompting + boundaries: what NOT to do and when to stop and ask.