Prompting Claude Fable 5

Claude Platform Docs · article · 2026-07-07 Reader 🖥️

practical · expository — A how-to reference page: it prescribes prompting and scaffolding patterns and supplies copy-paste system-prompt blocks. It asserts rather than argues; rationale (`because the model was trained to...`) is thin and mostly implicit.

Structure

Key terms

• effort
  The primary API control for the intelligence/latency/cost trade-off on Fable 5, with discrete settings (low, medium, high, xhigh); default `high`, `xhigh` for the most capability-sensitive work, `medium`/`low` for routine tasks. Lower effort on Fable 5 is said to often exceed prior models' `xhigh`.
• adaptive thinking
  Fable 5 uses adaptive thinking only — there are no configurable extended-thinking token budgets; the model decides how much to reason internally.
• summarized (summarized-only) thinking output
  The model exposes only a summary of its internal reasoning; extracting the full/raw thinking is one of the actions its safety classifiers target.
• refusal stop reason (`stop_reason: "refusal"`)
  A distinct API stop reason returned when a request trips Fable 5's safety classifiers; the doc pairs it with configuring server- or client-side fallback to Opus 4.8.
• safety classifiers
  Runtime classifiers that decline requests in offensive-cybersecurity, biology/life-sciences, and summarized-thinking-extraction domains — and that may also trip on benign cybersecurity or beneficial life-sciences work.
• long-horizon autonomy
  Fable 5's capacity to sustain productive, goal-directed output over extended, multi-day runs with strong instruction retention across long, complex tasks.
• elicitation language / system reminder
  A short instruction placed in the system prompt that is required to actually trigger a behavior or tool use (e.g., autonomous operation, or calling `send_to_user`); the doc stresses that defining a capability or tool is insufficient on its own without this instruction.

Propositions

• explicitcorroboratedPoint Fable 5 at your hardest, most complex, long-running, or ambiguous problems (not just simple workloads) and you reveal its real capability range; testing it only on simpler tasks tends to undersell it.conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p1 — Near-verbatim restatement of 'point Fable 5 at your hardest problems; simple-workload testing undersells it.' Secondary-source echo of the same official guide — adds no independent evidential weight.
• explicitestablishedWhen migrating from Opus 4.8, treat the capability jump as a prompt to re-evaluate and prune existing instructions, tools, and guardrails — some prior scaffolding is no longer needed.conf: high
  supportsHarness design for long-running application development · p7 — Both prescribe stripping harness scaffolding as model capability rises. The Fable 5 docs make it official Anthropic guidance ('capability improvements are a good prompt to re-evaluate which instructions, tools, and guardrails are still needed'), matching the harness-design methodology of removing components one at a time and keeping only the load-bearing pieces.
  supports ←The Anatomy of an Agent Harness · p11 — Fable-5 p2: treat a capability jump as a prompt to re-evaluate and PRUNE existing instructions, tools, and guardrails. Anatomy supplies the principled basis: scaffolding is temporary, removed when the building is complete, and Anthropic deletes planning steps from Claude Code's harness as new model versions internalize that capability.
  refines ←Don't train the model, evolve the harness · p9 — NOT a contradiction — the apparent opposition ('evolve/grow' vs 'prune') is lexical. Fable-5 p2 prescribes PRUNING on the MODEL-CAPABILITY axis: a stronger model absorbs compensatory hand-holding, so remove it. Akshay's thesis operates on the LOCUS-OF-LEVERAGE axis: for a FIXED, rented model, the harness is where the marginal gain lives. These are different axes, so no conflict. Akshay refines Fable-5's undifferentiated 'prune scaffolding' by specifying WHAT survives pruning: his finding that 'code fixes transfer across models, prompt playbooks do not' (p5) says keep the portable code-layer mechanisms and cut the model-specific prompt hand-holding. And Akshay's own quoted deep-dive endorses the prune stance outright (Manus rebuilt 5x removing complexity; the future-proofing test rewards NOT adding complexity), confirming 'evolve' = fitness-selection that adds AND removes.
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p13 — Operationalizes the guide's 'a capability jump is a prompt to re-evaluate instructions, tools, and guardrails' into an ordered six-area migration checklist. Same content, repackaged as procedure; the packaging is the thread's additive value, not new evidence.
• explicitSteer most behaviors with a single brief, high-level instruction rather than enumerating each case — because instruction-following is strong, a short brevity instruction is as effective as listing every individual pattern.conf: high
• explicitGive the reason and intent behind a request (the larger task, who it is for, what the output enables), not just the request itself, and you get better output — context lets the model connect the task to relevant information instead of inferring intent on its own.conf: high
  supportsThe Best Prompting Advice Came From a Writing Teacher · p4 — The Fable 5 'give the reason' template ('I'm working on [larger task] for [who]... they need [what the output enables]') operationalizes exactly Zinsser's pre-prompt questions of purpose and audience — as concrete, model-specific guidance for an agent rather than a writing heuristic.
• explicitestablishedUse the `effort` setting as the primary intelligence/latency/cost control — default `high`, `xhigh` for the hardest tasks, `medium`/`low` for routine work — and reduce effort to curb over-deliberation; lower effort on Fable 5 often exceeds prior models' `xhigh`.conf: high
  supports ←Claude Code: Best practices for agentic coding · p8 — The think-keyword ladder (think < think hard < ultrathink) is the 2025 coarse precursor to Fable 5's `effort` setting — both hold that reasoning allocation should scale with task difficulty as the primary intelligence/cost lever.
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p3 — Restates effort as a cost/latency trade-off with the same tiers, but FLATTENS the docs: it drops effort's intelligence axis and omits the over-deliberation warning. Secondary-source echo; the flattening is a selective distortion, not a contradiction.
  refines ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p14 — Adds a cost-routing caveat the docs de-emphasize: Fable 5 is a specialist and Opus 4.8 is faster/cheaper/sufficient for routine work — more cost-cautious than the guide's 'lower effort on Fable 5 still performs well and often exceeds prior models' xhigh' framing.
• explicitAdd an explicit anti-over-engineering instruction (no unrequested refactors, abstractions, feature flags, or defensive validation for impossible cases) to prevent the unrequested tidying and refactoring that higher effort tends to produce.conf: high
• explicitAdd an anti-overplanning instruction ('when you have enough information to act, act') to stop Fable 5 from over-surveying options, re-deriving established facts, or re-litigating settled decisions on ambiguous tasks.conf: high
• explicitcorroboratedInstruct the agent to audit each progress claim against an actual tool result from the session before reporting, and fabricated status reports are nearly eliminated — Anthropic reports this held even on tasks designed to elicit fabrication.conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p6 — Reproduces the progress-audit block near-verbatim. Secondary-source echo — adds no independent evidential weight; the thread's extra 'audit beat softer phrasings' test is uncited and not in the primary.
• explicitcorroboratedDefine explicit constraints distinguishing an assessment request from a change request, and gate state-changing commands on whether evidence supports that specific action, to prevent unrequested actions (drafting emails, defensive git-branch backups, applying fixes before asked).conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p7 — Same proactivity constraint block and the same two examples (unrequested email, defensive git-branch backup). Secondary-source echo — adds no independent evidential weight.
• explicitcorroboratedRestructure harnesses for asynchronous, long-running execution — adjust client timeouts, streaming, and progress indicators, and check runs asynchronously (e.g., scheduled jobs) rather than blocking — because individual hard-task requests can run for many minutes at higher effort and autonomous runs for hours.conf: high
  supportsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p3 — Primary-source vendor confirmation that a frontier model's run lengths (minutes-to-hours) force modeling agents as asynchronous long-running processes rather than blocking request handlers — the central thesis of the long-running-agents piece.
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p2 — Restates the async/timeout migration point (runs last minutes to hours; extend timeouts). Secondary-source echo — adds emphasis ('most common source of confusion') but no independent evidential weight.
• explicitcorroboratedUse parallel subagents frequently with explicit guidance on when delegation is appropriate and asynchronous orchestrator-subagent communication, and keep long-lived subagents that retain context — this saves time and cost through cache reads and avoids bottlenecking on the slowest subagent.conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p10 — Restates bounded subagent delegation with async continuation and failure-reporting. Secondary-source echo — adds no independent evidential weight.
• explicitcorroboratedProvide a persistent memory store (as simple as a Markdown file, one lesson per file with a one-line summary) and instruct the model to record and reference lessons — and bootstrap it by having the model review past sessions — because Fable 5 performs particularly well reusing lessons across runs.conf: high
  supportsExternalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p4 — The recommended Markdown notes file is a concrete instance of memory-as-externalization: transforming a cognitive burden (retaining lessons across runs) into external infrastructure the model reads, exactly the externalization thesis.
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p8 — Reproduces the Markdown memory-note format and the session-close reflection bootstrap. Secondary-source echo — adds no independent evidential weight.
  extends ←Paweł Huryn's Post · p3 — Fable 5 guidance says 'a Markdown file, one lesson per file' is enough for a persistent memory store; Huryn extends this into a fuller structural taxonomy differentiating semantic memory (markdown/rules) from episodic memory (CSV/history) rather than treating all persisted lessons as one undifferentiated store.
• explicitFor autonomous pipelines, add a system reminder that the user is not watching, that reversible actions following from the request should proceed without asking, and that any end-of-turn plan/question/promise must be converted into tool calls — this prevents early stopping (text-only 'I'll now run X' without the call, or pausing for permission mid-run).conf: high
• explicitAvoid surfacing explicit context-budget or remaining-token counts to the model; if the harness must show them, add reassurance ('you have ample context remaining') — this prevents Fable 5 from prematurely suggesting a new session, summarizing, or trimming its own work (context anxiety).conf: high
  supportsHarness design for long-running application development · p1 — Same 'context anxiety' failure mode (the model prematurely wraps up as it senses limits). The Fable 5 docs confirm it as a named behavior and add a concrete mitigation the harness-design piece did not: don't surface remaining-token countdowns to the model, or add a reassurance.
• explicitAdd a checkpoint instruction that pauses only for genuinely blocking cases (destructive/irreversible actions, real scope changes, or input only the user can provide), and Fable 5 stops only where needed without enumerating every case.conf: high
• explicitcorroboratedAdd a communication-style/readability addendum for the final user-facing summary (outcome first, complete sentences, no arrow chains, hyphen-stacked compounds, or invented jargon; re-ground the reader rather than continue the working thread) to prevent hard-to-follow output in extended agentic conversations.conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p9 — Restates the final-response readability addendum (outcome first; no arrow chains/internal labels). Secondary-source echo — adds no independent evidential weight.
• explicitTo surface verbatim mid-task messages, define a `send_to_user` tool AND pair it with system-prompt elicitation language — tool inputs are never summarized so content arrives intact, but Fable 5 rarely calls the tool without the explicit instruction.conf: high
• explicitcorroboratedConfigure server-side or client-side fallback to Opus 4.8 for refusals, because Fable 5's safety classifiers (offensive cybersecurity, biology/life sciences, summarized-thinking extraction) can decline even benign work and return `stop_reason: "refusal"`.conf: high
  supports ←How to Actually Prompt Fable 5, Straight From the Team That Built It · p11 — Restates the refusal stop_reason + Opus 4.8 fallback. Secondary-source echo of the same mechanism — the added sub-5% figure and cyber-routing detail are uncited and not in the primary, so they add no evidential weight.

Arguments

Narratives

• The 'When you have enough information to act, act. Do not re-derive facts already established... give a recommendation, not an exhaustive survey' block.
  → Demonstrates a single brief instruction curbing overplanning/option-surveying on ambiguous tasks.
• The 'Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for...' block.
  → Demonstrates the anti-fabrication technique — grounding status claims in tool evidence.
• The 'You are operating autonomously. The user is not watching in real time... Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question... do that work now with tool calls' block.
  → Demonstrates the autonomous-pipeline system reminder that prevents early stopping and turns end-of-turn promises into tool calls.
• The intent template 'I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].'
  → Demonstrates giving the reason/intent — a fill-in-the-blank pattern operationalizing purpose and audience for an agent.
• The `send_to_user` tool JSON schema plus the elicitation line 'Between tool calls, when you have content the user must read verbatim... call the send_to_user tool with that content.'
  → Demonstrates that a defined tool needs paired system-prompt elicitation to actually be used, and that tool inputs pass through un-summarized.
• The 'You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.' block.
  → Demonstrates countering context anxiety triggered by a visible remaining-token countdown.
• The memory-note format block 'Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike...' plus 'Reflect on the previous sessions we've had together...'
  → Demonstrates a minimal file-based memory system and how to bootstrap it from past sessions.

Questions addressed

• ✅ How should I migrate a harness from Opus 4.8 to Claude Fable 5?
  Adjust client timeouts, streaming, and progress indicators and move to async run-checking (runs can last minutes to hours); prune now-unnecessary instructions, tools, and guardrails; and configure fallback to Opus 4.8 for refusals.
• ✅ How do I stop an agent from fabricating or overstating progress?
  Instruct it to audit each progress claim against a tool result from the session and report only work it can point to evidence for.
• ✅ How do I trade off intelligence against latency and cost?
  Use the `effort` setting (default `high`, `xhigh` for the hardest work, `medium`/`low` for routine), and reduce effort when a task is slower than needed.
• ✅ Why does the agent stop early, ask permission mid-run, or suggest a new session, and how do I prevent it?
  Add an autonomous-operation system reminder plus a checkpoint definition, and avoid surfacing remaining-token countdowns (or add a 'you have ample context remaining' reassurance).

Gaps

• incompleteNo eval methodology to verify that any recommended prompt actually works for the reader's own task. The single near-quantified claim ('nearly eliminated fabricated status reports') is unquantified, drawn from Anthropic's own testing, with no reproducible benchmark, dataset, baseline, or numbers — so a rigorous adopter cannot confirm which system-prompt blocks earn their place.
  Read next: Pair with an evals discipline (e.g. extract-anthropic-harness-design-long-running-application-development, which uses graded evaluators); build an A/B eval harness that measures each system-prompt block's marginal effect before adopting it wholesale.
• incompleteThe document is undated. It is thoroughly version-specific (Fable 5 vs Opus 4.8, effort tiers, adaptive/summarized-only thinking, the `refusal` stop reason, safety-classifier domains) yet carries no published or last-updated date, so its claims will drift silently as the model and platform update.
  Read next: Cross-check every version-specific claim against the platform changelog and the 'Introducing Claude Fable 5 and Mythos 5' page at time of use; re-verify before betting a migration on any stated default or limit.
• incompleteThe behavioral-improvement claims (bug-finding recall 'noticeably higher', vision accuracy 'substantially higher', single-pass implementations of multi-day systems, more dependable subagent dispatch) are all qualitative, with no benchmark numbers, task definitions, or independent verification.
  Read next: Seek third-party or benchmark evidence for the specific claimed gains before relying on them; treat the improvement list as vendor signal, not measurement.
• incompleteNo guidance on interaction effects among the many recommended system-prompt blocks (brevity, anti-over-engineering, anti-overplanning, checkpoint, autonomy, readability, progress-audit, memory). The doc never says whether they conflict, how much instruction budget they consume together, or which takes precedence — awkward given its own advice to prefer brief high-level instructions over enumeration.
  Read next: Consult context-engineering / progressive-disclosure material on instruction budgets; assemble and test the composed system prompt as a whole rather than validating each block in isolation.
• incompleteEnglish- and software-only. Every example prompt is English and targets agentic/coding/enterprise-document work; there is no guidance for non-English prompting or for non-software domains, even though the guide claims broad capability gains.
  Read next: Look to practitioner reports on multilingual and domain-specific steering; do not assume the English software-agent prompts transfer unchanged.
• uninformedNo stated boundary for when 'steer with a brief instruction' stops working and explicit enumeration becomes necessary. The doc asserts brevity suffices, yet its own recommended blocks are long, multi-clause instructions — leaving the reader without a rule for where high-level steering degrades.
  Read next: Use eval-driven tuning to find the point where high-level steering fails and enumeration is required for a given behavior and effort level.

Closes gaps elsewhere

• The Best Prompting Advice Came From a Writing Teacher · g2 — Zinsser's four rhetorical pre-prompt questions omit the LLM-specific technical concerns (context selection, multi-step decomposition, tool use, output-format constraints, verification). This guide supplies exactly those: effort/context control, subagent decomposition, tool-use elicitation, readability/output-format instructions, and self-verification against tool results — matching the gap's reading_direction toward prompt-engineering guides that address agentic, not just generation, tasks.
• The real skill behind good AI prompts is older than computers · g4 — Svenson treats the model as a neutral mirror and underweights that model capability, tool scaffolding, and prompt structure shift outcomes independent of user attention. This official Anthropic guide is primary-source evidence for precisely that: model-specific structure (effort settings, brief-vs-enumerated instructions, subagent and memory scaffolding, elicitation language) measurably changes behavior — matching the gap's own reading_direction, which asked for exactly these Anthropic prompt-/context-engineering guides.

Related documents

• The Best Prompting Advice Came From a Writing Teacher
• How to Actually Prompt Fable 5, Straight From the Team That Built It
  Agent Harness Agent Memory Context Engineering Long-Running & Managed Agents
• Harness design for long-running application development
  Agent Harness Capability Provisioning (right-sizing to the task) Long-Running & Managed Agents Multi-Agent Orchestration
• The Anatomy of an Agent Harness
  Agent Harness Agent Memory Context Engineering Multi-Agent Orchestration
• Anthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development
  Agent Harness Long-Running & Managed Agents Multi-Agent Orchestration Riding Model Improvements
• Claude Code: Best practices for agentic coding
  Agent Harness Capability Provisioning (right-sizing to the task) Context Engineering Multi-Agent Orchestration
• Don't train the model, evolve the harness
  Agent Harness Context Engineering Multi-Agent Orchestration Riding Model Improvements
• Stop Overengineering Your Agent Harness
  Agent Harness Context Engineering Multi-Agent Orchestration Riding Model Improvements
• Agent Harness Engineering
  Agent Harness Capability Provisioning (right-sizing to the task) Multi-Agent Orchestration
• Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security
  Agent Harness Agent Memory Long-Running & Managed Agents