Nate Herk's useful point is not that Opus 4.8 secretly becomes Fable 5 if you paste in magic words. It does not.
The useful point is that Fable 5's advantage is partly process. It scopes better, checks evidence, reasons against its own plan, verifies before calling work done, and reports with more calibration. If you can turn that working discipline into a skill, checklist, or routing system, you keep more value when access, pricing, or subscriptions change.
That matters because frontier models are not infrastructure you own. Skills, process, evaluation habits, local memory, and model-routing rules are closer to an owned asset.
Video credit: Nate Herk. Nate's public site describes his work as helping people master AI agents, build automations, and turn those skills into income.
Source Note
This post uses Nate Herk's supplied transcript as commentary, plus official Anthropic and Claude Code documentation for Fable 5 prompting, effort levels, Claude Code skills, model configuration, Opus 4.8, and Fable fallback behavior. I do not reproduce leaked system prompts. The article focuses on public, reusable workflow patterns.
The strongest verified source for this angle is Anthropic's own Fable prompting guide, which says Fable 5 differs from Opus 4.8 on long-horizon autonomy, code review, ambiguity handling, delegation, collaboration, and long-running tasks. Nate's practical move is to ask: which of those behaviors can be turned into reusable operating discipline?
Link Map
| Resource | Link | Use in this post |
|---|---|---|
| Nate Herk video | How I Make Opus Think Like Fable | Primary source for the Fable-mode skill, effort-level, and model-routing workflow. |
| Nate Herk | @nateherk on X | Creator credit. |
| Nate Herk site | nateherk.com | Public background on Nate's AI automation work. |
| Prompting Fable 5 | Claude Platform docs | Official guidance on Fable behavior, long runs, instruction following, memory, and scaffolding. |
| Effort parameter | Anthropic effort docs | Explains how effort controls token spend, thoroughness, and cost tradeoffs. |
| Claude Code skills | Extend Claude with skills | Official basis for turning repeatable procedures into skill files. |
| Claude Code model config | Model configuration | Useful for understanding model and effort restrictions in organizations. |
| Fable fallback guide | Fallback and billing guide | Shows why fallback behavior should be explicit per request, especially in multi-agent systems. |
| Opus 4.8 | Anthropic Opus 4.8 release | Official source for Opus 4.8 and effort control in Claude surfaces. |
| Fable 5 release | Fable 5 and Mythos 5 | Official source for Fable 5 capability, safeguards, pricing, and Opus fallback framing. |
| Fable 5 redeployment | Redeploying Fable 5 | Context for access changes and why process ownership matters. |
The Main Idea
Nate frames Fable 5 as a teacher more than a workhorse. That is the right mental model. If you only use the best model to brute-force every task, you pay for intelligence repeatedly. If you use the best model to improve your operating system, you keep part of the benefit after the run ends.
The pattern looks like this:
- Use Fable 5 or another strongest-available model on a genuinely hard run.
- Save the session, deliverable, plan, and verification notes.
- Ask a strong model to identify what made the run good.
- Turn those habits into a skill or checklist.
- Run Opus, Sonnet, Codex, or an open model through that same discipline.
- Measure whether quality holds while cost drops.
This is not model distillation in the "copy the model" sense. It is workflow distillation: preserving habits, gates, and review criteria from successful work.
The Five Gates
Nate's Fable-mode skill centers on five gates. These are worth stealing for almost any agent workflow.
| Gate | What it means | Why it helps cheaper models |
|---|---|---|
| Scoping | Define the real goal, constraints, inputs, unknowns, and finish line before acting. | Stops the model from executing a vague task too early. |
| Evidence | Check files, docs, logs, screenshots, APIs, or source material before reasoning. | Reduces confident hallucination and stale assumptions. |
| Attack | Play devil's advocate against the plan: what could fail, be missing, or be misunderstood? | Gives smaller models a structure for risk thinking. |
| Verify | Run tests, inspect output, compare against acceptance criteria, and check edge cases. | Moves quality from "sounds good" to evidence-backed. |
| Report | Explain what changed, what was verified, what is uncertain, and what should happen next. | Creates usable handoff instead of a pile of generated work. |
Notice what is missing: magic wording. The gates are ordinary engineering discipline. Fable does more of it naturally. A skill makes other models do more of it deliberately.
Effort Levels
Anthropic documents effort as a way to trade off thoroughness and token efficiency. High effort is the default; max can be useful for the hardest work; lower effort can save time and cost on simple tasks. Anthropic's Opus 4.8 announcement also says higher effort makes Claude think more frequently and deeply, while lower effort responds faster and uses limits more slowly.
Nate's warning is practical: do not run everything on the highest effort just because you can. Higher effort can overthink, second-guess, take longer, and become more expensive. The right setting depends on the task.
| Task | Suggested effort | Reason |
|---|---|---|
| Formatting, summarizing, renaming, small edits | Low or medium | The problem is simple and mostly mechanical. |
| Normal code changes with clear files and tests | Medium or high | Enough reasoning to avoid obvious mistakes without burning the budget. |
| Architecture, multi-agent planning, migration strategy | High | The model needs to handle dependencies, tradeoffs, and unknowns. |
| Large refactor, ambiguous product decision, complex incident review | High or max | Worth spending more only when the decision cost is high. |
| Exploration with no verifiable output | Medium first | Max effort without a finish line can become expensive wandering. |
A Clean Fable-Mode Skill
The skill should not say "pretend you are Fable" or reproduce leaked prompt content. It should define working discipline. Here is a safe starter pattern you can adapt:
---
name: fable-mode
description: Use for hard work that needs careful scoping, evidence checks, adversarial review, verification, and a calibrated final report.
---
# Fable Mode
Use this skill when the task is complex, expensive to get wrong, ambiguous, or likely to require multiple steps.
## Gate 1: Scope
- Restate the user's actual goal.
- List constraints, known inputs, missing inputs, and the definition of done.
- If one question is necessary, ask only the highest-leverage question.
## Gate 2: Evidence
- Check available files, docs, logs, tests, screenshots, links, or source material before making claims.
- Do not assume a file, feature, dependency, or fact exists until verified.
## Gate 3: Attack
- Identify the most likely failure modes.
- Look for hidden requirements, edge cases, security risks, and cost risks.
- Adjust the plan before executing.
## Gate 4: Verify
- Run the relevant checks.
- Compare the output against the definition of done.
- If verification is impossible, say exactly what remains unverified.
## Gate 5: Report
- State what changed or what was found.
- State what was verified.
- State what is uncertain.
- Recommend the next best action.That skill is boring in the best way. It gives cheaper models rails. If you want it to work across teams, add project-specific acceptance criteria, test commands, house style, deployment rules, and examples of good final reports.
The Model Routing Table
The second half of Nate's workflow is routing. A strong orchestrator does not need every worker to be the strongest model. The orchestrator needs to know which model is good enough for which job.
Here is the kind of table I would give an agent:
| Work type | Model tier | Review rule |
|---|---|---|
| Strategy, architecture, ambiguous planning | Fable 5 or Opus 4.8 high effort | Human reviews before execution. |
| Code review, risk review, final acceptance | Fable 5, Opus 4.8, or strongest available reviewer | Must cite evidence and tests. |
| Routine implementation on clear tickets | Sonnet-class or cheaper coding model | Run tests; escalate if blocked. |
| Research scouting, file search, simple extraction | Haiku-class or small open model | Report sources and uncertainty. |
| Formatting, cleanup, summaries | Cheap model or local model | Spot-check output. |
| Design taste, product judgment, customer-facing copy | Best model available plus human taste | Human final approval. |
The routing rule should include more than price. Include cost, intelligence, taste, speed, context size, tool reliability, privacy, and whether the model is allowed to touch the data.
What To Avoid
- Do not paste leaked prompts into production workflows. They can be stale, incomplete, unsafe, or against the spirit of model safeguards.
- Do not assume high effort is always better. Use high effort when the task justifies it.
- Do not route sensitive work to random cheap endpoints. Privacy and retention matter.
- Do not let workers self-certify important work. Strong reviewer, tests, logs, or human approval should close the loop.
- Do not confuse a skill with a guarantee. A skill improves behavior; it does not create missing capability.
Anthropic's Fable fallback guide is also a good reminder: if you are building API systems with fallback behavior, set fallback explicitly on every request path, including retries, continuations, and subagents. Do not assume one fallback switch covers the whole system.
Builder Checklist
If you want to use this idea this week, do this:
- Pick one Fable run, Opus run, or high-quality agent session you loved.
- Extract the process: how it scoped, checked evidence, attacked the plan, verified, and reported.
- Turn that process into a skill file, not a giant prompt pasted into every thread.
- Run the same task with Opus, Sonnet, Codex, or a cheaper model using the skill.
- Measure quality, cost, runtime, and number of correction turns.
- Create a routing table for your common tasks.
- Keep the strongest model for orchestration, review, ambiguity, and taste.
- Use cheaper models for scouting, extraction, formatting, and routine execution.
- Save examples of good outputs so the skill improves over time.
- Keep human review on anything customer-facing, risky, regulated, or expensive to undo.
Sources
- Nate Herk: How I Make Opus Think Like Fable
- Nate Herk on X
- Nate Herk official site
- Anthropic: Prompting Claude Fable 5
- Anthropic: Effort parameter
- Claude Code: Extend Claude with skills
- Claude Code: Model configuration
- Claude Cookbook: Fable 5 fallback and billing guide
- Anthropic: Introducing Claude Opus 4.8
- Anthropic: Claude Fable 5 and Claude Mythos 5
- Anthropic: Redeploying Claude Fable 5
- Anthropic: Claude Fable product page