Claude Fable 5 · Field Guide
Your best prompting habits are now your worst.
Claude Fable 5 was built for long, ambiguous, end to end work, and the prompting habits that made you good with Opus 4.x will actively hold it back. Here is the new playbook, distilled from official Anthropic guidance into one word: GOALS.
What changed
More instructions no longer means better output
For years, the reliable way to improve model output was to add detail: more steps, more rules, more procedure. Fable 5 breaks that relationship. Its instruction following and judgment are strong enough that a clear statement of intent and outcome outperforms an exhaustive checklist, and past a point, extra procedure actively degrades results. The migration guidance from Anthropic is blunt: skills and instructions written for prior models are often too prescriptive for Fable 5.
Prior models (Opus 4.x era)
Claude Fable 5
Every section below follows the same pattern: the principle, the old habit versus the new habit as real prompts, and what it looks like in practice. By the end you will have a template that encodes the whole framework, plus full rewrites of prompts you probably use today.
Give the why
The highest leverage change: context about your actual goal outperforms any checklist of requirements.
Fable 5 makes hundreds of small decisions in any nontrivial task: depth, format, what to include, what to skip. Intent is what lets it make those calls correctly. The template from Anthropic is worth stealing verbatim:
"I am working on [the larger task] for [who it is for]. They need [what the output enables]. With that in mind: [your specific request]."
Adapted from Anthropic, Prompting Claude Fable 5
Old habit
Write a competitive analysis of voice agent pricing. Include a table. Cover at least 5 vendors. Keep it under 2 pages. Use professional tone.
All format and no purpose. The model cannot tell which details matter.
The GOALS way
I am preparing a board update for a seed stage AI company deciding whether to build or buy voice infrastructure. They need to know if the unit economics work at 10,000 calls per month. With that in mind: analyze voice agent pricing.
Same task. The intent tells it what "good" means here.
Outcomes, not steps
The biggest philosophical break: state the destination, let the model choose the route.
Older models did best with exhaustive step by step instructions. Fable 5 does worse with them. Every procedural step you dictate substitutes your judgment for the judgment of the model, and on complex work its sense of the how is now frequently better than a procedure planned in advance. One clear sentence steers behavior better than enumerating every rule by name.
- State the outcome you want. Let the model determine the path.
- Audit your existing prompts, skills, and CLAUDE.md files. Instructions accumulated for older models are often too rigid now. Test without them and cut what the model handles better by default.
- Keep the context, cut the procedure. Rich intent (the G) plus a concise instruction (the O) is the winning combination. Information helps; micromanagement hurts.
Old habit
1. First read all files in /src 2. Then list every component 3. Then check each for unused props 4. Then create a report.md 5. Then fix issues one at a time 6. After each fix, run the linter 7. Then summarize changes...
A route planned before seeing the terrain. Caps quality at your plan.
The GOALS way
Clean up dead code and unused props across /src without changing behavior. Done means the test suite still passes and the linter is clean.
Outcome plus constraint plus finish line. The model plans the route.
Agree on "done"
Fable 5 runs until it believes the job is finished, so define the finish line before it starts.
1. Define done, measurably
Replace "make it good" with a bar the model can check itself against: "all 84 test assertions pass," "a first time visitor completes checkout without guidance," "the deck survives a skeptical CFO." If no measurement exists, have the model build one first, whether a test suite, a rubric, or an eval script, and then work to it.
2. Constrain excess delivery
This one surprises people. At higher effort, the failure mode of Fable 5 is not laziness. It is excess: refactoring code you did not ask about, surveying five alternative approaches, gathering more context than the task needs. The fix is the opposite of old school prompting. Instead of pushing it to try harder, tell it to hold back. The recommended language from Anthropic: "Do the simplest thing that works well." And if you are describing a problem or just thinking out loud, say so. Fable 5 is proactive enough to occasionally start fixing things when what you wanted was an assessment.
Old habit
Improve the onboarding flow. Make it really good. Be thorough and comprehensive. Do not miss anything.
"Good" is undefined, and "thorough" invites excess scope.
The GOALS way
Improve the onboarding flow. Done means a new user reaches their first saved project in under 3 steps, and all existing tests pass. Do the simplest thing that works well. No refactors outside the onboarding path.
A measurable bar plus an explicit ceiling on scope.
Let it run
Recalibrate your expectations about time. Long runtimes are the model working correctly.
At high effort, a single response can take minutes; autonomous runs can extend for hours. Anthropic flags this as the most common source of confusion for teams migrating from Opus 4.8. The old rhythm of quick output, spot the problem, prompt again, repeat, is replaced by one long run that plans, executes, and checks itself.
Your prompts
Model working
Pick the effort level: the dial belongs to you, not the model
Effort is the primary Fable 5 control for intelligence versus latency versus cost, and it is a setting you choose. High is the default for most demanding work. Xhigh is for capability sensitive tasks where first shot correctness beats speed. Medium and low handle routine subtasks, and notably, Fable 5 at lower effort often matches or exceeds prior models at max effort, which changes the cost math considerably.
Front load decisions for autonomous runs
For pipelines where no one is watching, say so: tell the model the user cannot answer questions during the run, so pausing to ask permission will block the work. Grant the authority and access it needs before the run starts, not during.
Show the evidence
Autonomy without verification is just hope. Make "done" a claim that must be proven.
On long multi step tasks, any model can drift into reporting a step as complete when it has not been verified. The single most important instruction in the official guide targets exactly this:
"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."
Anthropic, Prompting Claude Fable 5 (put this in your system prompt, not just the task)In testing by Anthropic, this instruction nearly eliminated fabricated status reports, even on tasks designed to elicit them. The word audit matters; it outperformed softer phrasings.
On long builds, add a cadence so hours of autonomous work never go unverified until the end: "Establish a method for checking your own work at an interval of [X] as you build."
Put it to work
The GOALS prompt template
One structure that encodes the whole framework. Fill the brackets, delete what does not apply, and keep the evidence audit line in your system prompt or skills so you never retype it.
goals-template.txt
I am working on [the larger goal] for [who it is for]. They need [what the output enables]. # G: Give the why With that in mind: [the outcome you want]. # O: Outcomes, not steps Done means [measurable bar: tests pass, user completes X, metric hits Y]. Do the simplest thing that works well; stay within [scope boundary]. # A: Agree on "done" Work autonomously. I cannot answer questions during the run. Establish a method for checking your own work at an interval of [X] as you build. # L: Let it run 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. # S: Show the evidence
From Opus to Fable
Three prompts, rewritten
The fastest way to internalize the shift is to see prompts you probably use today, rewritten. Each pair below is the same task twice: once the way it was written for Opus, and once the GOALS way for Fable 5.
Example 1 · Shipping a product feature
How you prompted Opus
Add CSV export to the dashboard. 1. Add an Export button top right 2. On click, call /api/export 3. Build the endpoint with pandas 4. Stream the file as a download 5. Add a loading spinner 6. Write unit tests for the endpoint 7. Update the README
You designed the solution before the model ever saw the codebase.
The Fable 5 way
Our enterprise users need to pull dashboard data into Excel for board reporting. Add CSV export to the dashboard. Done means a user can download the current filtered view in one click and all tests pass. Do the simplest thing that works well. Audit each claim against a tool result before reporting progress.
Intent, outcome, finish line, evidence. The model designs the solution.
Example 2 · Analyzing data for a decision
How you prompted Opus
Analyze sales_q2.csv. First clean the null values. Then group revenue by region. Then create 5 charts: bar, line, pie, scatter, heatmap. Then write a summary with 3 bullet points per chart.
A fixed procedure caps the analysis at what you already suspected.
The Fable 5 way
I am deciding whether to keep our two lowest performing sales regions or consolidate them. sales_q2.csv has the data. Recommend a decision and show the evidence behind it. Done means every claim traces to a specific number in the file.
A decision to inform, not a chart list to complete. The model may surface what you never thought to ask.
Example 3 · Writing content that gets cited
How you prompted Opus
Write a 1500 word blog post on AI lease abstraction. Use H2 headings every 200 words. Include the keyword "AI lease abstraction" 8 times. End with a conclusion and a call to action.
Keyword arithmetic reads as filler to modern search and AI engines alike.
The Fable 5 way
We want AI engines like ChatGPT and Perplexity to cite us when property managers ask about lease abstraction. Readers are operations leads evaluating tools. Write the article that earns that citation. Done means it answers the questions a buyer actually asks, and every claim is specific enough to quote.
Optimize for being the best answer, and the format follows.
Notice what every rewrite has in common: the Opus version tells the model what to do, and the Fable 5 version tells it what must be true when it finishes. That is the entire shift in one sentence.
The bottom line
Brief it like a senior hire
The prompting evolution from Opus 4.x to Fable 5 mirrors the shift from managing a junior employee to briefing a senior one. Juniors need procedures. Seniors need intent, a definition of done, room to work, and accountability for evidence.
GGive the whyGoal, audience, what the output enables.
OOutcomes, not stepsState the destination; it plans the route.
AAgree on "done"A measurable bar, plus a ceiling on scope.
LLet it runLong runs are correct; you pick the effort.
SShow the evidenceAudit claims against tool output; verify fresh.
Point it at your hardest unsolved problem: the workflow you abandoned because no model could do it reliably. Prompt it in GOALS. That is where Fable 5 stops looking like an upgrade and starts looking like a different product entirely.
Sources: Anthropic, "Prompting Claude Fable 5" (platform.claude.com) · Anthropic, "Introducing Claude Fable 5 and Claude Mythos 5."
Charts are conceptual illustrations of documented guidance, not benchmark measurements.
The AI customer experience newsletter
Practical playbooks on AI support, agents, and automation — plus product updates. Join 6,000+ operators. No spam, unsubscribe anytime.