Fable is back. Here's how to actually code with it.

Fable is back.

After the June export-control mess, Anthropic has restored Claude Fable 5 access. As of July 1, 2026, Fable is again available globally across Claude.ai, Claude Platform, Claude Code, and Claude Cowork, with Anthropic also re-enabling access on AWS, Google Cloud, and Microsoft Foundry as quickly as possible.

But the return comes with a very important caveat.

Fable is now protected by stricter safety classifiers. When those classifiers decide a request is too close to high-risk cybersecurity, biology, or reasoning-extraction territory, the request can be blocked and routed to Claude Opus 4.8 instead. Anthropic also says the new classifier is more likely to flag benign coding and debugging tasks while they tune down false positives.

That is why some developers are seeing what feels like this behavior:

"I selected Fable, asked it to code, and it switched to Opus 4.8."

The understandable reaction is: "So Fable can't code anymore?"

I think that is the wrong conclusion.

The better conclusion is:

Fable can still be extremely useful for coding, but you need to stop using it like a generic autocomplete model. Use it like a staff engineer, architect, migration planner, debugging lead, and final reviewer.

That shift matters.

Anthropic's own Fable prompting guide says Fable is strongest on complex, ambiguous, long-running work: the kind of work that might take a human hours, days, or weeks. It specifically calls out stronger long-horizon autonomy, code review, debugging outside restricted cybersecurity categories, repository-history search, ambiguity handling, and subagent delegation.

So the question is not: "Can Fable code?"

The real question is: "Where should Fable sit in my coding workflow so I get maximum value without constantly hitting fallback?"

Here is the practical playbook.

1. Use Fable for judgment, not keystrokes

The fastest way to waste Fable is to ask it to do every small edit.

Do not use it for:

• Tiny syntax fixes
• Simple CRUD changes
• Renaming variables
• Formatting
• Boilerplate generation
• Routine file search
• Basic test updates
• Mechanical implementation steps

Those tasks are usually better handled by a cheaper or faster model.

Use Fable where mistakes are expensive:

• Architecture decisions
• Large refactors
• Migration planning
• Complex debugging
• Design reviews
• Ambiguous product-to-code translation
• Multi-file dependency analysis
• Final production review
• Test strategy
• Codebase archaeology
• Long-running agent tasks
• Pull request review after another model implemented the change

A good mental model:

Sonnet or Opus can be the implementer.
Fable should often be the architect and reviewer.

That also matches what some early practitioner guides are recommending: use cheaper models for triage, repetitive execution, and simple tool calls, then bring in Fable for deeper judgment, migration planning, architecture review, and final decisions.

2. Split coding work into three phases

The most reliable Fable workflow I have found from the docs and community patterns is this:

Phase 1: Explore
Phase 2: Plan
Phase 3: Execute and verify

Fable does not need to own every phase.

A practical setup:

Use a cheaper model or Opus 4.8 to explore the repo, collect files, summarize architecture, identify test commands, and prepare a clean brief.

Use Fable to reason about the hard part: what should change, what could break, what order to do it in, and how to verify it.

Use Opus or Sonnet to implement repetitive edits.

Use Fable again as the final reviewer.

That "Fable sandwich" is often more reliable than asking Fable to blindly do the entire job from the first prompt.

Example workflow:

Opus: map the repo, identify affected files, summarize current behavior.
Fable: design the safest migration plan and identify hidden risks.
Opus or Sonnet: implement the plan.
Fable: review the diff, tests, edge cases, and rollout risk.
Human: approve the final ship decision.

This is not about bypassing safeguards. It is just good model routing.

"Sonnet or Opus can be the implementer. Fable should often be the architect and reviewer. The teams that win are the ones that learn how to hand work between models, not force one model through every prompt."

3. Start with planning mode for big changes

For large coding tasks, Fable should often begin in read-only mode.

Claude Code's docs recommend /plan before large changes, and note that /model and /effort let you adjust how much reasoning you spend during the task. Before shipping, Claude Code provides /diff, /code-review, /review, and /security-review workflows.

A strong Fable prompt looks like this:

/model claude-fable-5
/effort high
/plan

Goal:
Design the safest implementation plan for [feature/refactor/migration].

Constraints:
- Do not edit files yet.
- First map the affected files and dependencies.
- Identify assumptions and unknowns.
- Propose the smallest safe change.
- Separate implementation steps from verification steps.
- Tell me which parts should be delegated to a cheaper model.

This does three things.

First, it gives Fable the kind of high-level reasoning task where it makes sense.

Second, it reduces accidental over-editing.

Third, it creates a clean plan that another model can execute if Fable later falls back.

4. Use high effort by default, not always max

Fable has an effort dial, and using it well matters.

Anthropic recommends high as the default for most Fable tasks, xhigh only for the most capability-sensitive workloads, and medium or low for more routine work. The docs also warn that high-effort Fable can gather more context and deliberate more than necessary on routine tasks.

My practical rule:

Use medium for interactive coding help.
Use high for most serious engineering tasks.
Use xhigh for architecture, migrations, deep debugging, and final reviews.
Avoid xhigh for tiny edits.

A good instruction to pair with higher effort:

Do the simplest thing that solves the stated problem. Do not add features, abstractions, compatibility layers, or surrounding cleanup unless they are necessary for this task.

That instruction is close to Anthropic's own guidance for preventing Fable from over-refactoring at higher effort.

5. Make your repo Fable-readable

Fable is powerful, but it is not psychic.

If your project context is messy, Fable will waste tokens discovering things a human team could have written down once.

Claude Code recommends using /init to create a starter CLAUDE.md, then refining it with build commands, test commands, code style, workflow rules, and non-obvious project gotchas. It also warns that bloated CLAUDE.md files can cause Claude to ignore the important instructions.

A good CLAUDE.md should include:

• How to install dependencies
• How to run one test
• How to run the full test suite
• How to typecheck
• How to lint
• Which package manager to use
• Non-obvious architecture rules
• Important directories
• Branch and PR conventions
• Known traps in the repo

A bad CLAUDE.md includes:

• Long tutorials
• Obvious language conventions
• File-by-file explanations
• Outdated information
• Rules that conflict with each other
• Generic instructions like "write clean code"

A practical CLAUDE.md snippet:

# Project commands
- Install: pnpm install
- Dev server: pnpm dev
- Typecheck: pnpm typecheck
- Unit test one file: pnpm test path/to/file.test.ts
- Full test suite: pnpm test
- Lint: pnpm lint

# Workflow
- Prefer small, reviewable diffs.
- For bug fixes, add or update a regression test first when practical.
- Run typecheck after a series of code changes.
- Do not run the full test suite unless the targeted tests pass first.

# Architecture
- API routes live in src/server/routes.
- Shared domain logic lives in src/domain.
- UI components should not call database code directly.

This makes Fable more reliable because it can spend its reasoning budget on the hard problem instead of rediscovering your workflow.

6. Put repeatable workflows into skills

Do not stuff every workflow into CLAUDE.md.

Claude Code supports skills through SKILL.md files. The docs recommend using skills for domain knowledge and reusable workflows that should load on demand rather than bloating every conversation.

For example, you could create:

.claude/skills/fable-migration-review/SKILL.md

---
name: fable-migration-review
description: Review a proposed code migration for hidden risks and verification gaps
---

Review the proposed migration.

1. Identify affected modules.
2. Find hidden dependencies.
3. Identify backwards compatibility risks.
4. Check whether the plan can be split into smaller PRs.
5. Define targeted tests.
6. Define rollback strategy.
7. Produce a ship/no-ship recommendation.

Then you can invoke it whenever Fable is doing a migration review.

This is a good use of Fable because the value is not in typing code. The value is in catching what another model or engineer might miss.

7. Use hooks for rules that must always happen

Instructions are advisory. Hooks are deterministic.

Claude Code's docs are very clear here: use hooks for actions that must happen every time with zero exceptions. For example, a hook can run eslint after edits or block writes to sensitive folders.

This matters for Fable because you should not rely on any model to remember every operational rule in a long session.

Good hook ideas:

• Run formatting after file edits
• Run lint after edits
• Block changes to generated files
• Block changes to migrations unless explicitly allowed
• Filter huge test logs down to failures
• Prevent accidental writes to production config
• Warn when secrets appear in a diff

The docs also note that hooks can reduce token usage by preprocessing noisy output. For example, instead of making Claude read a 10,000-line log, a hook can return only matching error lines.

That is exactly the kind of environment setup that makes Fable more effective: give it the right signal, not all the noise.

8. For security work, be explicit and defensive

This is where many fallbacks happen.

Anthropic says Fable's safeguards target offensive cybersecurity techniques such as building exploits, malware, or attack tooling. The same docs also say benign cybersecurity work can trigger safeguards.

So do not phrase legitimate work in a way that sounds like exploit development.

Bad prompt:

Find vulnerabilities in this auth system and show me how to exploit them.

Better prompt:

I am reviewing my own authorized codebase. Please perform a defensive code review focused on correctness, authentication boundaries, authorization checks, input validation, secrets handling, and test coverage.

Do not provide exploit chains, offensive tooling, payloads, or attack instructions. For each issue, provide:
1. The affected file and line
2. Why it is risky
3. A safe remediation
4. A safe regression test

Even this may still route to Opus 4.8. That is expected sometimes. Anthropic intentionally uses a safety-margin approach that blocks ambiguous cyber requests, even when many are probably benign.

The goal is not to trick the classifier. The goal is to state legitimate defensive scope clearly and avoid asking for dangerous output.

For deeper security review inside Claude Code, use the built-in /security-review command where appropriate. Claude Code documents it as a deeper read-only pass before shipping.

9. Avoid asking for hidden reasoning

Another avoidable fallback trigger: asking Fable to reveal internal reasoning.

Anthropic's Fable docs say the model has safeguards around extraction of summarized thinking, and the migration guide documents a reasoning_extraction refusal category.

So do not ask:

Show your full hidden chain of thought step by step.

Ask:

Give me the conclusion, key evidence, tradeoffs, risks, and recommended next action.

For coding, this is usually better anyway. You do not need a transcript of the model's private reasoning. You need an engineering decision you can inspect.

10. Use Fable for code review after another model writes the code

One of the best patterns is:

Let a cheaper model write the diff.
Let Fable review it.

Anthropic's Fable page includes customer feedback that Fable reviewed a PR drafted by Opus and made significant improvements in one shot. The same page includes feedback that Fable is strong on UI design, game coding, intent understanding, and catching complex design holes.

A practical prompt:

/model claude-fable-5
/effort xhigh

Review the current diff as a senior engineer.

Focus on:
- Correctness bugs
- Hidden coupling
- Backwards compatibility
- Missing tests
- Edge cases
- Simpler implementation paths
- Risky assumptions
- Files that should not have changed

Do not rewrite the whole PR. Return only:
1. Must-fix issues
2. Should-fix issues
3. Tests to add or run
4. Ship/no-ship recommendation

This is a perfect Fable task because the model is not just generating code. It is judging whether the work is safe.

11. Use subagents, but do not make all of them Fable

Fable is good at delegation. Anthropic says it is more dependable at dispatching and sustaining parallel subagents, and its prompting guide recommends using subagents frequently for independent subtasks.

But that does not mean every subagent should use Fable.

Claude Code's cost docs recommend using cheaper models for teammates, keeping teams small, keeping spawn prompts focused, and shutting down teammates when they are done.

A better pattern:

Fable = orchestrator
Sonnet or Opus = implementation agents
Haiku or cheaper models = simple scan/extraction agents
Fable = final synthesis and decision

Example subagent setup:

• Research agent: maps files and dependencies
• Test agent: finds and runs relevant tests
• Implementation agent: makes mechanical edits
• Review agent: checks diff quality
• Fable orchestrator: decides the plan and final recommendation

Claude Code lets you create custom subagents with /agents, choose their tools, choose their model, and restrict them to read-only tools when appropriate.

This is how you get more Fable-quality output without burning Fable tokens on every repetitive step.

12. Use worktrees for parallel experiments

If you want to test multiple approaches, isolate them.

Claude Code supports git worktrees with claude --worktree, creating separate working directories and branches so edits in one session do not touch files in another.

This works well with Fable:

Ask Fable to propose two or three viable implementation strategies.
Run each strategy in a separate worktree with cheaper implementation agents.
Bring the diffs back to Fable for comparison.
Ask Fable which one is safest to ship.

Prompt:

Compare these three worktree diffs.

Evaluate:
- Smallest safe change
- Test coverage
- Maintainability
- Regression risk
- Compatibility with current architecture
- Rollback simplicity

Pick one. Explain why. Do not merge anything.

Again, Fable is doing what it is best at: synthesis, judgment, and risk analysis.

13. Ask Fable to verify against tool results, not vibes

Fable is powerful, but you should still make it prove its work.

Anthropic recommends instructing Fable to ground progress claims against actual tool results, and says this nearly eliminated fabricated status reports in their testing.

Use prompts like:

Before reporting success, audit each claim against actual tool output from this session.

Only say something is complete if:
- The code was changed
- The relevant tests were run
- You can cite the command output
- Any skipped verification is explicitly marked as skipped

For implementation tasks:

After making changes:
1. Show the files changed.
2. Run targeted tests first.
3. Run typecheck.
4. If tests fail, stop and report the failure honestly.
5. Do not claim success unless verification passed.

This is especially useful for long sessions where the model may otherwise give an overly confident summary.

14. Keep context small and intentional

Fable has a large context window, but large context is not free.

Claude Code's cost docs say token costs scale with context size and recommend clearing between unrelated tasks, using /compact with custom compaction instructions, choosing the right model, disabling unused MCP servers, installing code intelligence plugins, and using hooks or skills to reduce unnecessary file reads.

Practical rules:

• Use /clear when switching tasks.
• Use /context to see what is consuming space.
• Use /compact Focus on test output, decisions, changed files, and unresolved risks.
• Do not keep unrelated debugging history around.
• Do not paste giant logs when a filtered error summary is enough.
• Prefer @file references over vague descriptions.
• Use CLI tools like gh, aws, gcloud, or sentry-cli where appropriate because Claude Code says CLI tools are often more context-efficient than API or MCP alternatives.

Fable works best when the context is rich, not bloated.

15. Diagnose fallback systematically

When Fable switches to Opus 4.8, do not just retry the same prompt.

Ask what category you likely hit.

• Was the task about vulnerabilities, exploits, auth, malware, payloads, or attack paths?
• Was it asking for reproduction steps instead of remediation?
• Was it asking for hidden reasoning?
• Was your CLAUDE.md or a hook injecting suspicious language?
• Was a subagent prompt phrased too broadly?
• Was the task actually better suited for /security-review or Opus 4.8?

The Claude API migration guide says Fable refusals return stop_reason: "refusal" as a successful HTTP 200 response, with stop_details.category values such as cyber, bio, or reasoning_extraction. It also describes API fallback handling to rerun refused requests on another model.

For Claude Code specifically, the CLI docs mention claude --safe-mode as useful for checking whether a customization is what triggers automatic fallback from Fable 5.

That is a practical debugging trick: if Fable behaves differently in safe mode, your local configuration may be part of the problem.

16. Use this task map

Here is the simplest practical routing map.

Great Fable tasks:

• Architecture review
• Migration planning
• Complex bug diagnosis
• Multi-file refactors
• Final PR review
• Ambiguous product requirements
• Test strategy
• Repository-wide dependency analysis
• UI review from screenshots
• Long-running agent orchestration
• Comparing multiple implementation approaches
• "Why is this system fragile?" analysis

Good but watch cost:

• Writing tests
• Generating implementation plans
• Producing documentation from code
• Performance profiling plans
• API design
• Data model review
• CI failure analysis
• Release planning
• Large codebase onboarding

Usually not worth Fable:

• Tiny fixes
• Boilerplate
• Simple file edits
• Formatting
• Single-function rewrites
• Dependency bumps
• Basic documentation cleanup
• Routine shell commands
• Simple search-and-replace work

Likely to fallback or require careful defensive framing:

• Security vulnerability review
• Authentication and authorization review
• Exploit-adjacent debugging
• Malware-like behavior analysis
• Requests involving payloads or bypasses
• Requests for hidden reasoning
• Biology or chemistry workflows

Do not use Fable for:

• Offensive exploit development
• Malware
• Credential theft
• Bypass instructions
• Attack tooling
• Jailbreak attempts
• Anything where the goal is to evade safeguards

17. A practical Fable coding prompt library

Use these as starting points.

The architecture prompt

Use Fable as a senior staff engineer.

Goal:
Evaluate the architecture for [change].

Please:
1. Map the relevant modules.
2. Identify hidden coupling.
3. Identify the smallest safe implementation path.
4. List risks and tradeoffs.
5. Define verification steps.
6. Recommend whether this should be one PR or multiple PRs.

Do not edit files yet.

The implementation handoff prompt

Turn this plan into an implementation brief for a cheaper coding model.

Include:
- Files to edit
- Exact behavioral changes
- Tests to add
- Commands to run
- Things not to change
- Acceptance criteria

The final review prompt

Review the current diff as a senior engineer.

Return:
1. Must-fix issues
2. Should-fix issues
3. Missing tests
4. Regression risks
5. Ship/no-ship recommendation

Ground every claim in the actual diff or test output.

The defensive security prompt

I am reviewing my own authorized codebase.

Perform a defensive review focused on:
- Authentication boundaries
- Authorization checks
- Input validation
- Secrets handling
- Unsafe data exposure
- Test coverage

Do not provide exploit chains, payloads, offensive tooling, or attack instructions.

For each finding, provide:
- File and line
- Risk
- Safe remediation
- Safe regression test

The fallback diagnosis prompt

Analyze why this request may have triggered fallback.

Do not try to bypass safeguards. Instead:
1. Identify ambiguous or risky wording.
2. Rewrite the task with a clearly defensive, authorized scope.
3. Remove requests for exploit reproduction or hidden reasoning.
4. Suggest whether this belongs in Fable, Opus, /security-review, or a human review.