Rewriting Your Prompts and Skills for Fable 5

Last updated: October 22, 2026

Re-verified October 22, 2026: the prompting-guide quotes, effort guidance and scaffolding advice below still match Anthropic's Fable 5 prompting guide. One thing moved: the old migration-guide URL is now an index of per-model guides, including Fable 5.1 and Mythos 5.1, Opus 5.5 and Sonnet 5.5. The API-level list in the first section was written from the June page, so check the guide for the model you are actually moving to.

Swapping claude-opus-4-8 for claude-fable-5 takes thirty seconds. Anthropic's own migration guide calls the move "mostly drop-in" at the API level. The actual work is everything on top of the API: system prompts tuned to push Opus into action, skills written as step-by-step procedures, scaffolding that forced progress updates and suppressed subagents. Anthropic is unusually blunt in the Fable 5 prompting guide: "Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality."

That sentence is the thesis here. Your Opus 4.x workarounds compensated for specific model weaknesses. Fable 5 fixed many of them, so the compensations are now liabilities. Here is what maps to what, what to delete, and an honest case for when not to migrate.

The Real Migration Is in Your Prompts, Not Your Code#

The API-level changes from Opus 4.8 are short, per the migration guide:

• Thinking is always on. Adaptive thinking is the only mode. thinking: {type: "disabled"} returns a 400, and omitting the thinking field now means thinking runs, where on Opus 4.8 it meant off. Depth is controlled with output_config.effort.
• budget_tokens and assistant prefill stay removed. Both already 400 on Opus 4.7 and 4.8.
• Safety classifiers now fire the refusal stop reason. The classifiers target offensive cyber, biology, and reasoning-extraction requests. A declined request returns HTTP 200 with stop_reason: "refusal" and a stop_details.category. Retry on Opus 4.8 via the beta fallbacks parameter, SDK middleware, or manually with fallback credit.
• 30-day data retention is mandatory. Zero-data-retention orgs get a 400 on every request.
• Same tokenizer as Opus 4.7 and 4.8. Counts are roughly unchanged from those models. Coming from Opus 4.6 or earlier, you also absorb the 4.7 tokenizer change of up to roughly 35 percent higher counts (varying by content), so re-baseline with count_tokens.
• Lower caching minimum. The minimum cacheable prompt drops to 512 tokens, from 1,024 on Opus 4.8.

For the code-level walkthrough with SDK examples, see our Fable 5 migration guide. This post is about the layer the checklist cannot automate.

What Maps to What#

The translation table for prompt and skill patterns that were correct on Opus 4.x and need rework on Fable 5, grounded in Anthropic's prompting guide and migration notes.

The pattern across every row: state the goal and the boundary, not the steps.

The Effort Interplay: Your Opus 4.8 Settings Don't Transfer#

This is the most common silent regression, because the effort docs give different recommendations per model and most configs were tuned once and frozen.

On Opus 4.7 and 4.8, Anthropic's guidance was to start coding and agentic workloads at xhigh. On Fable 5 the guidance flips: start at high (the default), including workloads that ran at xhigh on Opus 4.8, and step down for routine work. The docs are explicit that "lower effort settings on Claude Fable 5 still perform well and often exceed xhigh performance on prior models."

Three interactions to watch:

• Effort is now your only thinking control. No disabled mode, no budget. A route that ran without thinking on Opus 4.8 (no thinking field) thinks adaptively on Fable 5, changing both latency and spend on routes you considered "cheap."
• max_tokens is a hard ceiling on thinking plus response text. At high and xhigh, set it generously or the model truncates mid-task. The migration guide says to revisit it specifically for workloads that previously ran without thinking.
• Turns get longer. Hard tasks can run many minutes at higher effort, and autonomous runs can extend for hours. Fix client timeouts, switch to streaming, and plan async check-ins before migrating, not after the first production timeout.

Run an effort sweep as part of migration, including low and medium. On a model this capable, paying xhigh prices for a routine route is the new overprovisioning. For whether the model itself is worth 2x Opus pricing, our Fable 5 vs Opus 4.8 decision guide and cost-per-task analysis cover that math.

Where Old Workarounds Become Harmful#

Some Opus-era patterns do not just become unnecessary on Fable 5. They actively hurt.

Reasoning-echo instructions can trigger refusals#

The sharpest example: prompts or skills telling the model to "show your thinking" or "explain your internal reasoning in the response." On Fable 5 these can fire the reasoning_extraction refusal classifier, causing elevated fallbacks to Opus 4.8 on traffic that has nothing to do with safety. Anthropic's scaffolding guidance says to audit existing skills and system prompts for reflection instructions when migrating. If your application needs reasoning visibility, set thinking: {type: "adaptive", display: "summarized"} and read the structured thinking blocks instead. The broader transparency questions around Fable's classifiers are their own topic, covered in the silent guardrails post.

Over-prescription degrades output#

Skills written as numbered procedures were a rational response to models that improvised badly. Fable 5 plans well, and the official guidance is to "review and consider removing older instructions if default performance is better." The practical method: pick your two highest-traffic skills, write a de-prescribed variant stating the goal, constraints, and definition of done, and A/B it against the original on real tasks. The deletable lines are usually mid-procedure steps ("then run X, then check Y"); the keepers are boundaries ("never push to main") and facts ("the staging DB resets nightly").

Suppression guardrails waste the model's strengths#

Anti-delegation rules, forced progress cadence, and "do not explore, just answer" instructions all cap behaviors Fable 5 is now good at. Replace suppression with direction. The doc-recommended shape for delegation is one line: delegate independent subtasks and keep working while they run, intervening only if a subagent goes off track.

As a community observation rather than vendor guidance: Simon Willison's release-day testing (June 9, 2026) found the model "slow" and "expensive" but with remarkably strong instruction following on multi-step tasks, and noted the guardrails "trigger often enough" that the new fallback mechanisms exist for a reason. Steer with brief instructions, and treat refusal handling as a real code path.

Rewriting Skills, Specifically#

For Claude Code users, the mechanics matter too. Per the Claude Code skills docs, a skill's body loads only when used, and custom commands have merged into skills. Three Fable-specific passes:

1. Description pass. The description is what the model sees by default, so make the trigger condition explicit ("use when the user asks to deploy") rather than describing contents.
2. Body pass. Cut step enumeration down to goal, constraints, and verification criteria. Keep file paths, commands, and gotchas; those are facts, not prescriptions.
3. Reasoning audit. Grep your skills directory for "explain your reasoning," "show your work," and "think out loud" and remove them for the refusal reason above.

One more doc-backed behavior worth exploiting: Fable 5 "does a good job of updating skills on the fly based on what it learns from the task at hand." Give it permission to edit its own skills and review the diffs. That loop is the practical version of what we argued in why skills beat prompts for coding agents.

A One-Day Migration Plan#

• Hour 1: inventory. Grep for model IDs, thinking config, prefills, effort values, and reasoning-echo phrases. Confirm your org is not on zero data retention.
• Hours 2-3: blocking changes. Swap the model ID, remove thinking: {type: "disabled"}, add stop_reason: "refusal" handling with stop_details.category logging, and configure fallback to Opus 4.8.
• Hours 4-5: de-prescription A/B. Run your top prompts and skills with the scaffolding stripped, against the originals, on representative tasks. Keep whichever wins per route.
• Hour 6: effort sweep. Test low, medium, and high on routine routes; reserve xhigh for routes where evals show headroom. Raise max_tokens wherever thinking is new.
• Hour 7: refusal audit. Replay a representative traffic sample and measure refusal rate by category before production.
• Hour 8: rollout with logging. Ship behind a flag, log effort, latency, refusals, and cache hits, and compare against your Opus baseline for a week.

When to Stay on Opus 4.x#

Honest cases for not migrating, or not yet:

• You are under zero data retention. Fable 5 returns a 400 on every request from ZDR orgs; Opus 4.8 remains available under ZDR.
• Your workload is latency-sensitive interactive chat. Longer turns are structural at higher effort, and the per-token price is double ($10/$50 vs $5/$25 per million tokens).
• Your work borders the classifier domains. Benign security tooling and life-sciences tasks can trigger false positives. If fallback would serve a large share of traffic anyway, route to Opus 4.8 directly.
• Your Opus 4.8 prompts already hit quality targets. A tuned setup that meets your evals does not need a 2x price migration plus a prompt rewrite to stand still. Migrate when a task class is failing, not because the version number went up.

FAQ#

Do I need to rewrite every prompt before switching to Fable 5?#

No. The API swap works with existing prompts. But Anthropic's guidance says prompts and skills written for prior models are often too prescriptive and can degrade Fable 5 output quality, so A/B your highest-traffic prompts with the scaffolding removed before calling the migration done.

What replaces budget_tokens and thinking: disabled on Fable 5?#

Nothing directly. Thinking is always on and adaptive; output_config.effort (low, medium, high, xhigh, max) is the depth and spend control. thinking: {type: "disabled"} and budget_tokens both return 400 errors.

Should I keep effort at xhigh like I did on Opus 4.8?#

Probably not as a default. Anthropic recommends starting at high on Fable 5, including for workloads that ran at xhigh on Opus 4.8, because lower effort levels often exceed xhigh performance on prior models. Sweep low and medium on routine routes too.

Why would a normal prompt suddenly get refused on Fable 5?#

The most common self-inflicted cause is an instruction asking the model to reproduce its internal reasoning in the response, which can trigger the reasoning_extraction refusal category. Audit prompts and skills for show-your-thinking language, and read summarized thinking blocks via thinking.display: "summarized" instead.

Sources#

• Anthropic migration guide (Opus 4.8 to Claude Fable 5): https://platform.claude.com/docs/en/about-claude/models/migration-guide - accessed June 11, 2026; as of October 22, 2026 this URL is an index of per-model migration guides
• Introducing Claude Fable 5 and Claude Mythos 5: https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5.md - accessed June 11, 2026
• Prompting Claude Fable 5: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5 - accessed June 11, 2026, re-read October 22, 2026
• Effort parameter documentation: https://platform.claude.com/docs/en/build-with-claude/effort.md - accessed June 11, 2026
• Claude Code skills documentation: https://code.claude.com/docs/en/skills - accessed June 11, 2026
• Simon Willison, initial Claude Fable 5 impressions (community observation, June 9, 2026): https://simonwillison.net/2026/Jun/9/claude-fable-5/ - accessed June 11, 2026

Continue Reading#

• Claude Fable 5 - pricing, limits, and alternatives on one page
• Claude - the full model family on one page