Rob Shocks' Fable 5.2 walkthrough answers two questions that launch-day benchmarks do not: which Claude model should handle a real job, and what should change in your prompt when the model can work longer and follow instructions more literally? His five-part summary draws on Anthropic's model-selection playbook and Fable-specific prompting guide. The practical lesson is to give the model an outcome, verification path, scope and approval boundary, then measure what it actually finishes.
Start most coding work with Opus 5.5 at medium effort. Test Sonnet for clear, scoped fixes and Haiku for cheap, checkable side jobs. Reach for Fable 5.2 when Opus at high falls short, or when the job is large, ambiguous and long-running. Before escalating, give the agent a way to verify its work and raise effort once. This is a starting policy, not a guarantee that one model wins every task.
Watch Rob's 13-Minute Guide
Rob's ChatLLM segment is sponsored. The model map below is a text-based adaptation of the screenshot supplied with this article, cross-checked against Anthropic's current playbook. Rob's preference to avoid max effort is his judgment; Anthropic reserves it for rare, open-ended work where time and tokens matter less.
Which Model Should Do the Job?
- Everyday work, or not sureOpus 5.5Start at medium
- Clear, scoped fixSonnet 5.5Worth testing against Opus
- Side jobs: search, logs, extractionHaiku 5.5Use for checkable subagent work
- Big, ambiguous, multi-hour jobFable 5.2Medium to plan; high for a long run
Not a blanket “never max” rule: use higher effort only when your own tests justify the time and cost.
One important exception to a neat diagram: a clear specification does not mean an easy task. A risky migration can be well specified and still need Opus or Fable. Anthropic also lists Opus for vision-heavy computer use and Sonnet for repeated, well-defined agent tasks. Pick by the failure mode and cost per accepted result, not by the model name alone.
Change the Effort Before You Change the Model
Anthropic's playbook gives a useful escalation order: make the outcome checkable with a test, build or script; raise effort one level; then try the next model up at lower effort. Extra thinking cannot supply a missing capability, but it can help a model use tools and verify a difficult result. On Anthropic's FrontierCode 2.0 run, Fable 5.2 at high scored about level with Opus 5.5 at max for roughly half the cost per task. That benchmark is a reason to test, not a promise about your repository.
| Where you run Fable 5.2 | Starting effort | Adjustment |
|---|---|---|
| Claude Code | medium | Good for interactive planning; try high for hard or unattended execution. |
| Claude API | high | Lower to medium when your evaluations show quality holds. |
| Exceptional research or ceiling tests | xhigh or max only after measurement | Higher levels can consume far more time and tokens for uneven gains. |
The API prompting guide starts at high, while the Claude Code playbook starts at medium. Rob resolves that apparent contradiction by using medium while collaborating and high for the long run. Anthropic notes that effort changes may affect prompt caching depending on how they are made, so check your actual usage rather than assuming every switch is free.
Five Prompt Changes Worth Testing
1. Describe the Outcome, Not a Script of Steps
At 06:11, Rob suggests handing Fable a complete outcome for a messy investigation instead of pre-splitting it into tiny tasks. A good brief still names the deliverable, limits, sources and checks. For example: “Find the cause of the intermittent checkout failure, fix what the evidence supports, run the relevant tests and list unresolved risks.” That leaves room for investigation without allowing an undefined production change. This is Rob's working interpretation of Anthropic's long-horizon guidance, not a claim that every Fable task needs an open-ended prompt.
2. Tell It What “Finished” Means
Anthropic says Fable 5.2 can end a turn while doable work remains, especially at lower effort. At 07:22, Rob recommends a persistence instruction for ordinary errors and timeouts, plus a completion test. Keep hard stops explicit: intentionally withheld access, safety boundaries and actions requiring approval are not obstacles to work around. Anthropic reports that its tested completion instruction reduced incomplete sessions, with more output tokens; use it where finishing matters enough to justify the extra cost.
3. State the Code Scope and Desired Ownership Behavior
At 08:30, Rob covers a surprising finding: when Anthropic's test prompt portrayed the codebase as the agent's own, Fable more often consolidated duplication and fixed adjacent issues. It also used more tokens and sometimes changed more than requested. That “ownership” wording is a behavioral cue, not legal ownership or blanket permission. For a customer repo or narrow patch, omit it and name the allowed files. If you do want structural improvement, say so and review the entire diff, not just the agent's summary.
4. Put a Price and Purpose on Subagents
Fable can be a good orchestrator, but Anthropic warns that subagents can become a large share of session cost. At 09:24, Rob suggests checking the model used by each subagent, assigning simpler file search or log reading to a cheaper model, and removing stale “always delegate” instructions. Delegation depends on the harness; do not assume every built-in agent uses Haiku or that a custom agent is automatically cheaper. Give each agent a bounded question and an output the main agent can verify.
5. Make Rules and Approvals Exact
At 10:50, Rob's final change is to replace vague “never” and “go ahead” language with action-specific rules. A useful boundary is: “Ask before deploying, deleting data or sending external messages; you may run local tests and retry read-only calls without asking.” When approving a step, name it: “Yes, run the migration on the staging database.” Anthropic's guide says old caution notes and approval rules can accumulate across agent files and memory, so review those when moving a workflow to Fable. Keep a real confirmation gate for risky actions.
A Copyable Fable 5.2 Task Brief
This JQ AI SYSTEMS example combines the five ideas for a bounded coding task. It is not a verbatim Anthropic system prompt or a transcript quote. Replace the scope and approval lines for your project before running it.
Outcome, scope, checks and approval
Price and Plan Limits: Check Before a Long Run
Anthropic lists Fable 5.2 at $8 per million input tokens and $40 per million output tokens on the API, compared with Opus 5.5 at $4 and $20 in its model playbook. Token price is not task price: cached context, retries, tool calls and subagents affect the total. Rob's sponsor pricing is a separate offer, not the cost of Claude itself.
As of 11 November 2026, the official launch offer includes Fable in Pro and standard Team weekly limits through 16 November 2026, 11:59 pm PT, up to 50% of the weekly allowance. After that, those seats return to usage credits for Fable. Max and Ultra include Fable within their plan limits but also cap Fable's share at 50% of weekly usage; eligible subscribers have separate temporary reset offers. The default model does not change automatically, and Fable consumes plan limits faster than other Claude models. Check Settings > Usage before starting a multi-hour run.
Video Chapters
| Time | Topic |
|---|---|
| 00:00 | Introduction |
| 00:43 | Fable 5.2 highlights |
| 01:43 | Which model for which job |
| 03:02 | Change effort before the model |
| 05:18 | ChatLLM sponsor segment |
| 06:11 | 1. Outcomes, not steps |
| 07:22 | 2. Make it finish |
| 08:30 | 3. Say who owns the code |
| 09:24 | 4. Keep subagents in check |
| 10:50 | 5. Be exact about rules |
| 11:41 | When Rob would use each |
| 13:18 | Wrap-up |
Sources and Scope
Checked 11 November 2026. Rob's video, the supplied transcript and the reader-supplied model chart establish his explanation and preferences. Anthropic's model playbook, prompting guide, launch post and plan-offer note support the model, effort, price and access details. The diagram is a new HTML text rendering of the supplied image; the copyable task brief is our example. We have not run a head-to-head evaluation of these models on the same task.