Claude Fable 5 Use Cases: 12 Things Worth Its Premium Price

Playbook

Claude Fable 5 is the best coding model on the board — 95.0 on SWE-bench Verified, the top score anywhere — and it costs $10 per million input tokens and $50 per million output. That price is the whole point of this post. Fable is not a daily driver. Run it for everything and your bill looks like a mistake, because most of what agents do all day is boilerplate that a $3 model handles just as well. The skill is knowing which jobs actually earn the premium.

We vibe code for a living, and our rule is blunt: Fable does the hard 10%, cheaper models do the volume. Below are the twelve jobs where we reach for it without flinching — and the honest line for when you shouldn't.

The economics, stated plainly

Here is what you're choosing between when you route a task. The cheap tier is genuinely good now; the gap only opens on genuinely hard work.

Sonnet is roughly a sixth of Fable's output price and only ten SWE points behind. On easy work you will not feel those ten points. On hard work they are the entire game. Live numbers are at /benchmarks.

The twelve jobs worth the price

1. Gnarly architecture decisions. When you're choosing how a system will be shaped — the module boundaries, the data model, where state lives — a wrong call poisons every line written after it. Fable's reasoning depth is cheapest exactly here, because architecture is a few thousand output tokens that govern thousands of downstream ones.
2. Hard multi-file refactors. Renaming a concept that threads through thirty files, splitting a god-object, inverting a dependency — the kind of change where a cheaper model gets four files right and quietly breaks the fifth. Fable holds the whole graph in its head with its 1M context and doesn't lose the thread.
3. Tricky concurrency and race conditions. Deadlocks, torn reads, that bug that only shows up under load. These reward a model that can actually reason about interleavings instead of pattern-matching. This is a place we've watched cheap models flail for an hour and Fable nail on the first pass.
4. Perf bugs with no obvious cause. The endpoint that got slow and nobody knows why. Finding it means holding call stacks, allocation patterns, and query plans together. Worth the flagship.
5. Security-sensitive code. Auth flows, token handling, permission checks, anything touching money or PII. The cost of Fable is a rounding error next to the cost of an injection bug in your login. Never economize here.
6. Migrating a legacy system. Understanding code nobody wrote recently, in a framework two versions behind, and moving it forward without changing behavior. Comprehension of unfamiliar code is Fable's single strongest trait.
7. Planning a complex feature. Before a single line is written, decomposing a big feature into a sane build order that a team of cheaper builders can execute. A good plan is the highest-leverage output in the whole session.
8. The code your reviewer keeps rejecting. When a Sonnet or Codex builder has taken three swings at a task and a review agent bounced all three, stop grinding. Hand the whole thread — task, attempts, rejections — to Fable. It usually sees what the cheaper model kept missing.
9. Debugging across a boundary you don't control. A bug that lives in the seam between your code and a library, an API, or the runtime. Fable is best at forming a correct theory from incomplete evidence.
10. Tricky algorithmic work. Real data-structure or algorithm design where correctness is subtle and off-by-ones hide. If getting it wrong is expensive to detect, pay up front.
11. Writing the spec's hardest section. Not the whole doc — the one paragraph describing the part everyone's hand-waving. Fable interrogating a fuzzy requirement will surface the edge cases your team was about to discover in production.
12. The final review before you ship something scary. A last read of a database migration, a payments change, a mass-delete script. One Fable pass over the diff, from a fresh context, is cheap insurance on an irreversible action.

What NOT to use Fable for

If you catch yourself running Fable for any of these, you're lighting money on fire:

• Boilerplate. CRUD endpoints, form scaffolds, config files, test fixtures. Sonnet or GPT-5.3 Codex produces identical output for a fraction of the cost.
• Reads and lookups. "Is this symbol used anywhere?" "Summarize this file." That's scout work — Gemini 3.5 Flash or Haiku, at speed.
• Well-specified, low-risk tasks. If the task is clear and the blast radius is small, a builder-tier model is the right tool. The premium buys nothing.
• Bulk generation. Fifty similar components, a hundred rows of seed data. Volume work goes to the volume tier by definition.

How we route in practice

Our default builder is Sonnet 5. Our scouts are Flash. Fable sits on the bench and comes in for the plan, the scary refactor, and the task that's already beaten a cheaper model twice. That last trigger matters most: don't start on Fable, escalate to it. Let the cheap model try first; most of the time it succeeds and you never paid the premium. When it fails twice on the same task, that failure is the signal — the task is in the hard 10%, and now Fable is the cheapest way out, not the most expensive.

For a full role-by-role breakdown of which model staffs which seat, see the best model for each agent role. And if you want to see how Fable actually behaves on real code before committing budget to it, our Fable 5 coding review puts it through its paces.

The one-sentence version

Buy Fable the way you'd hire a specialist consultant: not for the day-to-day, but for the three problems a year that would otherwise sink the project. Route the volume to models that cost a sixth as much, keep Fable warm for the hard 10%, and the premium stops being a premium — it becomes the cheapest afternoon you'll spend all month. Running a fleet of models side by side to make that routing effortless is exactly what The Vibe Father is built to do, but the discipline works with any setup: cheap by default, flagship on demand.