# Claude Fable 5 Costs $50 a Million Tokens Out. Stop Using It as a Task Runner.

Fable 5 bills output at five times input, so the frontier model should plan and judge while cheaper Claude tiers do the work. The model-router setup, with real 2026 prices.

Author: J.A. Watte
Published: July 17, 2026
Source: https://jwatte.com/blog/claude-fable-5-orchestrator-not-task-runner/

---

The number that should decide how you use Claude Fable 5 is not its benchmark score. It is the gap between what it charges to read and what it charges to write. Input runs about $10 per million tokens. Output runs about $50. Across the current Claude lineup the output rate is five times the input rate, and on Fable 5 that means every million tokens the model writes costs the same as five million it reads.

Most people spend that ratio in the worst possible way. They paste a task into the most expensive model on the menu, wait for it to grind through the whole thing, commit whatever comes back, and do it again tomorrow. The frontier model does all the reading, all the reasoning, and all the typing, and the typing is exactly where the meter runs hottest. You are paying premium rates for output you throw away, and the run leaves nothing behind that makes the next run cheaper.

There is a better shape, and it is not a secret. A widely shared write-up by the Agent Native team put it bluntly: Fable 5 is completely wasted on most developer workflows because people use it like a glorified task runner instead of the core engine of a system that remembers, routes, and hardens over time ([Agent Native on Medium](https://agentnativedev.medium.com/fable-5-is-completely-wasted-on-most-developer-workflows-14dba20d4391)). The short version fits on a sticky note: the expensive model should manage, not type.

## The manager does not sit at the keyboard

In any team you have ever worked on, the most expensive person is not the one writing the most lines. They decide what to build, hand the bounded pieces to people who are faster and cheaper at those pieces, and check the result before it ships. You would never put your principal engineer on data entry. Yet that is precisely what "paste the task into Fable and wait" does.

The fix is to treat the Claude tiers as a team with a payroll, and to assign roles by what each tier costs to run:

| Tier | Price in / out per million | Context | Role |
|---|---|---|---|
| **Claude Fable 5** | ~$10 / ~$50 | 1M | Orchestrate: read the whole problem, plan, delegate, synthesize, decide |
| **Claude Opus 4.8** | ~$5 / ~$25 | 1M | Specialist: the bounded hard tasks a worker cannot finish |
| **Claude Sonnet 5** | ~$3 / ~$15 (intro ~$2 / ~$10 through Aug 31, 2026) | 1M | Worker: the bulk typing, refactors, docs, tests |
| **Claude Haiku 4.5** | ~$1 / ~$5 | 200K | Verifier and router: grade the output, classify the input, gate the rest |

The one sentence to remember is that the cheapest tier gates the priciest. A Haiku-tier grader reading a diff and a rubric costs almost nothing next to a Fable-tier model writing that diff. So you let the cheap model decide whether the expensive model's work is allowed to pass, and you let it classify incoming work so the expensive model only ever sees the parts that actually need it.

This is the same instinct you already use in distributed systems. You do not put every job on the biggest machine. You put the coordinator on the machine that can reason across the whole graph, and you fan the parallel work out to cheaper boxes. Fable 5 is the coordinator. It should decide the plan, split the work, interpret the confusing failures, and update what the system knows. It should not spend $50-a-million tokens renaming a variable or reflowing a doc.

## What the routing actually saves

Put rough numbers on it. Say one unit of work, fixing a single flaky test, runs a model through 120,000 tokens of input across the session as it re-reads context, and produces 20,000 tokens of output.

Run the whole thing on Fable 5 and the input costs about $1.20 and the output about $1.00, so roughly $2.20 for that one fix. Now route it. Fable reads the state and the logs once and emits a short plan. Sonnet 5 does the actual edit and the explanation, which is the 20,000-token output half, at a third of Fable's output rate. Haiku 4.5 reads the diff and the test results and returns a verdict. The plan, the typing, and the check land closer to $0.80 for the same fix, and the routed version also leaves a written note behind so the next flake of the same kind is cheaper to diagnose. Those token counts are illustrative, not measured, and the real ones depend entirely on your task. The rates they are multiplied by are the published ones, and the shape of the saving holds: move the output half to a cheaper tier and the bill drops by more than half, because output was always the expensive half.

I built a calculator so you can run this on your own numbers instead of mine. **[Try the Model-Tier Cost Calculator](/tools/model-tier-cost-calculator/)**: enter your runs per month and the tokens per task, and it shows the whole-task cost on each Claude tier next to the routed total, with editable prices and a cache slider. It runs entirely in your browser.

Two levers make that gap bigger, and neither needs an agent framework.

**Prompt caching turns the repeated half of your input nearly free.** Most agent loops re-send the same large context every turn: the system prompt, the map of the codebase, the rubric, the coding standards. Anthropic's prompt caching bills a cache read at roughly a tenth of the normal input price, so once that stable block is cached, you stop paying full freight to re-read it on every turn ([Anthropic prompt caching docs](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). The rule is to put the frozen content first, before anything that changes per request, because a cache is a prefix match and one changed byte early in the prompt throws away everything after it. Do this right and the input half of a long session can drop by up to ninety percent.

**Batch anything that does not need an answer in the next minute.** Overnight CI triage, bulk classification of a backlog, re-labelling a month of support tickets: none of that is latency sensitive. Anthropic's Batch API runs those requests asynchronously at half the normal token price ([batch processing docs](https://platform.claude.com/docs/en/build-with-claude/batch-processing)). If a job can wait an hour, batching it is a fifty percent discount for changing one method call.

## Match the effort to the task, not to your anxiety

Fable 5 thinks by default, and you control how hard it thinks with an effort setting that runs from low through max. The reflex from earlier models was to crank everything to the top to feel safe. That reflex is expensive and often wrong. Higher effort means more reasoning tokens and more tool calls, which is exactly what you want on a genuinely hard planning step and exactly what you do not want on a routine one. Start most work at the middle of the dial and only reach for the top when correctness matters more than the bill. On the routing tasks and the grading tasks, low effort on a cheap tier is usually all the job needs.

There is also a ceiling worth setting on purpose. A task budget hands an agentic loop a token allowance up front so the model paces itself and wraps up gracefully instead of wandering until something cuts it off. It is a different thing from a hard output cap: the cap is a wall the model cannot see, the budget is a countdown the model plans around. For anything running unattended, give it a budget so a stuck loop cannot quietly spend a fortune.

## The run that leaves nothing behind did not compound

The routing above already saves money on any single task. The part that actually changes the economics is what you keep between runs. A frontier model with no memory rediscovers the same facts every session, and rediscovery on a $50-a-million model is the most expensive way to learn something twice.

So the loop worth building is small and boring. Read what the system already knows. Do the work. Verify the result with a checker that did not write it. Distill the lesson into one line. Write that line back into memory so the next run starts where this one finished. Anything that only produced a chat answer and left nothing durable behind did not compound, no matter how good the answer was.

In practice the memory is a couple of plain files that travel with the project. A `STATE.md` holds the verified facts, the standing rules, the open failures, and where the last session stopped:

```markdown
# Project memory · payments-api

## Verified facts
- CI runs Node 22 and PostgreSQL 16.
- Integration tests need STRIPE_WEBHOOK_SECRET in the environment.

## Standing rules
- Never disable a failing test to make CI green.
- Payment and billing changes require a security review.

## Open failures
- Checkout webhook test flakes when delivery and assertion overlap.
  Repro: run the CI suite against the checkout-webhook case.

## Last session
- Next: reproduce the flake, classify it, and either draft a fix or escalate.
```

A companion file tells the agent to read that memory before it touches any code, and to end every run by writing the memory back. The whole point is that the second time the checkout webhook flakes, the system already knows it is a delivery-versus-assertion race and does not pay Fable to figure that out again from scratch.

## The checker cannot be the author

The single highest-leverage piece of this is a verifier that is a different model from the one that did the work, running on a cheap tier. The maker knows why it made every choice, so it is the worst possible judge of its own patch. It will tell you the tradeoff is fine, the edge case cannot happen, and the tests were flaky anyway. A verifier that never saw the reasoning cannot make those excuses. It sees only the diff, the rubric, and the command output, and it returns a verdict.

In Claude Code you can define exactly that as a small subagent with its own model and a locked-down set of tools:

```markdown
---
name: verifier
description: Independently checks a change against the tests, the rubric, and the project rules.
model: haiku
tools: Read, Bash, Glob
---

You are an independent verifier. You did not write this change. Do not defend it.
Check: did the requested command pass? did the change solve the stated problem
without unrelated edits? did the run update the project memory? did it avoid the
protected files? Return exactly one of PASS, FAIL_WITH_FIXABLE_GAPS, or
FAIL_REQUIRES_HUMAN, and include the exact evidence: command, file path, or the
failing assertion.
```

Notice the model line. The verifier runs on Haiku, the cheapest tier, and it holds veto power over the most expensive one. That is the cheapest-gates-priciest rule made concrete. And note what it does that a green test suite cannot: passing tests answer "does the code run," but they do not answer "did the agent quietly modify the billing subsystem" or "did it forget to write the lesson back." Do not mistake a passing suite for a verifier. It is one input the verifier reads, not the whole job.

This pattern comes straight from the Agent Native write-up, which walks the full version, a CI-triage loop with a memory file, a graded skill, a goal condition that keeps the loop running until the tests actually pass, and git worktrees so parallel agents never poison each other's checkout ([the piece is worth reading in full](https://agentnativedev.medium.com/fable-5-is-completely-wasted-on-most-developer-workflows-14dba20d4391)). The build order it lands on is the right one: memory first, then a read-only verifier, then a goal condition for one real loop, then a skill that updates itself after confirmed failures, then a guard that blocks protected files, and only after all of that a parallel workflow or a scheduled routine. The fancy parts are worthless without the boring base under them. A workflow with no verifier just parallelizes your mistakes. A routine with no memory just automates forgetting.

## Copy these files and you have the loop

Here is the part that makes all of this usable by anyone, not just people running a coding agent. The memory is nothing but plain text files, and the two Claude Code features that turn a chat into a compounding system, Skills and subagents, are each a single markdown file with a few lines at the top. Copy the pieces below, change the specifics to your own work, and you have the whole loop by the end of an afternoon. None of it is code, and none of it is only for programmers.

**The standing instructions: `CLAUDE.md`.** Claude Code reads this file automatically at the start of every session, so it is where the rules that must hold on every run belong, including the two that make the loop compound: read the memory before you start, and write it back before you finish.

```markdown
# How to work here

Before you start anything, read STATE.md for what we already know.
When you finish, update STATE.md with any new fact, rule, or lesson.

## Rules that always apply
- Do only what I asked. Do not add extras I did not request.
- Before any change that is hard to undo, stop and confirm with me.
- If something fails the same way twice, that is a lesson. Write the
  failure and the fix into STATE.md so we never rediscover it.

## What "done" means
- The result exists and has been checked against the request, not just produced.
- STATE.md has been updated. A run that leaves no note behind did not count.
```

**The memory: `STATE.md`.** You saw a developer version earlier. The point worth repeating is that it is just a file, so any assistant that can read a file can use it, and it works exactly the same for work that has nothing to do with code. Here is one for someone running a client account:

```markdown
# Project memory · Acme account

## Verified facts
- Acme's fiscal year ends in March; the Q4 numbers land in mid-April.
- Press questions go to the comms team, never the CEO's office.

## Standing rules
- Never cite a number without a link to where it came from.
- Draft in their voice: short sentences, plain words, no jargon.

## Open questions
- Is the new product line counted under Services or under Products?

## Last session
- Next: settle the segment question, then draft the Q4 summary.
```

**The reusable playbook: a Skill.** A Skill is procedural memory, the how-to for a recurring job that should travel with you across every session and project instead of being re-explained each time. In Claude Code a Skill is a folder inside `.claude/skills/` with a `SKILL.md` in it, and the folder name is what you type to run it, so the file below, saved as `.claude/skills/client-update/SKILL.md`, becomes a command you invoke with `/client-update`.

```markdown
---
description: Turn raw notes into a polished client status update in our voice. Use when I ask for a client update.
---

# Client update playbook

## Steps
1. Read STATE.md for this account's facts, rules, and open questions.
2. Sort the raw notes into three piles: progress, blockers, decisions needed.
3. Write in short sentences, lead with the outcome, keep out the jargon.
4. Every number gets a source link. If you cannot source it, flag it instead.

## Lessons learned
- The client reads on a phone. Keep the whole thing under 200 words.
- Do not write "on track" unless a real milestone shipped this week.
```

The `Lessons learned` section is the entire trick. It starts nearly empty and grows by one line every time something goes wrong once, so the same mistake cannot happen a second time. The expensive model works the lesson out; from then on a cheap model just reads it and follows it. Claude also loads the Skill on its own when a task matches that `description`, so you do not even have to remember to reach for it.

**The stopping condition: `/goal`.** The last piece keeps the loop honest. In Claude Code, `/goal` followed by a plain-language condition sets a finish line, and the agent keeps working across turns until the condition is actually met, with a small, cheap model checking after each turn whether it is done ([Claude Code docs](https://code.claude.com/docs)). So a goal like "the client update is drafted, every number has a source, and STATE.md is updated" will not hand back a half-finished draft and quit. That one line is the difference between a chat that answers once and a loop that finishes the job. When you are ready to have it run on its own, on a schedule or when something changes, that is what Routines and the `/schedule` command are for, but reach for automation only after the plain loop has earned it.

Put those in place, point the assistant at them, and the architecture from the rest of this post is built. Memory so nothing is rediscovered at premium rates, a Skill that hardens every time it fails, a verifier that gates the output, and a goal that keeps it honest. Everything left is just deciding which tier does which job.

## The three things that will bite you

None of the above matters if the model quietly fails and your code treats the failure as success.

**A refusal comes back as a success, not an error.** Fable 5 runs safety classifiers on incoming requests, and when one fires you get a normal HTTP 200 response with `stop_reason` set to `refusal` and an empty or partial body, not an exception your `catch` block will ever see ([Anthropic's Fable 5 docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5)). Code that reads the first content block without checking the stop reason will run as if it worked and hand garbage downstream. Check the stop reason first, and set up a fallback: a refused request can be re-run on another Claude model, and Anthropic supports a server-side fallback that reroutes to Opus 4.8 inside the same call. Treat a refusal as state, not noise. Log it, because a class of task that keeps getting refused on Fable is a routing decision, not a one-off.

**Fable 5 requires thirty-day data retention.** It is not available under zero data retention, so a request from an organization configured for stricter retention is rejected outright ([model docs](https://platform.claude.com/docs/en/about-claude/models/overview)). Before you route anything sensitive through a long-running Fable loop, confirm the retention setting matches what the data allows. This is the kind of thing that is trivial to check up front and miserable to discover in production.

**Sometimes Fable is simply the wrong tool.** The whole argument is that the frontier model earns its price on planning, ambiguity, and hard judgment. If Sonnet or Haiku already solves the task at a fifth or a tenth of the cost, running Fable is not thorough, it is waste. The only way to know is to measure your real token volume on a real task for a week before you decide the expensive model is load bearing. Most of the time it is not, and the cheap tier plus a good loop wins.

## The bottom line

The product is not the model's one-shot output. The product is the loop you build around it. Fable 5's real contribution is that it makes longer, more ambitious loops practical, loops that plan across a whole problem and hold a task together over many steps, and that is what a system needs to compound. Use it to run the team, not to be the team. Let the cheap tiers type, let the cheapest tier judge, keep the memory so nothing gets rediscovered at premium rates, and the most expensive model on your bill quietly becomes one of the smallest line items.

If your instinct when you need a capability is to reach for the biggest, most expensive tool and point it at the whole job, that instinct is what the whole approach fixes, and it is the argument of my book **The $20 Dollar Agency** (search the title on Amazon Kindle): spend on the smallest real thing that works, learn what actually limits you, and only then spend more. For AI, the smallest real thing is a cheap tier and a loop, not a frontier model and a prayer.

## Related reading

- [Where APUs Beat GPUs for On-Prem AI](/blog/apu-vs-gpu-on-prem-ai-unified-memory/): the other side of the cost question, when you run the models on your own metal instead of renting the frontier.
- [Local AI or Cloud APIs for a Small Business](/blog/blog-smb-ai-local-vs-cloud/): the honest local-versus-cloud math, and where the token bill is a rounding error.
- [The $50 a Month AI Stack for Small Business](/blog/blog-50-month-ai-stack-smb/): the wider toolkit that this routing discipline sits inside.
- [Top AI CLIs and How to Use Them](/blog/blog-ai-clis-with-our-prompts/): the terminal tools where goal conditions, subagents, and routines actually live.

## Fact-check notes and sources

Model prices change often and are quoted per million tokens; treat these as approximate mid-2026 figures and confirm on Anthropic's own pages before relying on them.

- **Claude token prices**: Fable 5 about $10 in and $50 out; Opus 4.8 about $5 in and $25 out; Sonnet 5 about $3 in and $15 out with an introductory $2 in and $10 out through August 31, 2026; Haiku 4.5 about $1 in and $5 out. Output is billed at five times input across the lineup. Fable 5, Opus 4.8, and Sonnet 5 carry a 1M-token context window; Haiku 4.5 carries 200K ([Anthropic pricing](https://platform.claude.com/docs/en/about-claude/pricing), [models overview](https://platform.claude.com/docs/en/about-claude/models/overview)).
- **Refusal behavior and fallback**: Fable 5 can return `stop_reason: "refusal"` as a successful HTTP 200 rather than an error, and refused requests can be retried on another Claude model, including a server-side fallback to Opus 4.8 ([introducing Claude Fable 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5)).
- **Data retention**: Fable 5 requires 30-day data retention and is not available under zero data retention ([models overview](https://platform.claude.com/docs/en/about-claude/models/overview)).
- **Prompt caching economics**: cache reads bill at roughly a tenth of the base input price, and caching a large stable prefix can cut the input cost of repeated context by up to about ninety percent ([prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)).
- **Batch pricing**: the Batch API processes non-latency-sensitive requests asynchronously at 50 percent of standard token prices ([batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)).
- **Claude Code building blocks**: `CLAUDE.md` is read automatically at session start; Skills live at `.claude/skills/<name>/SKILL.md` and are invoked by folder name or loaded by description match; subagents live at `.claude/agents/<name>.md` and take a `tools:` restriction plus a per-agent `model:`; and `/goal` sets a completion condition checked after each turn by a small, fast model. See the [Claude Code documentation](https://code.claude.com/docs).
- **The orchestrator framing, the model-tier roles, and the CI-triage compounding loop** (memory file, independent verifier subagent, goal condition, worktrees, and the build order) are drawn from Agent Native, "Fable 5 Is COMPLETELY Wasted on Most Developer Workflows" ([Medium](https://agentnativedev.medium.com/fable-5-is-completely-wasted-on-most-developer-workflows-14dba20d4391)).

---

*This post is informational, not engineering or financial advice. Mentions of Anthropic, Claude, and other third parties are nominative fair use. No affiliation is implied. Model names, prices, and API behavior change quickly; verify against the current documentation before you build.*


---

Canonical HTML: https://jwatte.com/blog/claude-fable-5-orchestrator-not-task-runner/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/claude-fable-5-orchestrator-not-task-runner.webp