Skip to main content

You Don't Deserve Fable (Yet)

· 5 min read
Gergely Sipos
Gergely Sipos
Frontend Architect

Claude Fable is the most capable model Anthropic has shipped — above Opus class, frontier reasoning, genuinely impressive on hard problems. It's also the fastest way to burn through your token budget if you haven't built the discipline to use it correctly. Most developers will reach for it because it's the best, use it for tasks Haiku could handle, and wonder why their costs exploded. This post is about earning the right to use Fable by mastering the cheaper models first.

The Lineup You Need to Internalize​

Anthropic's model family is a cost-capability ladder. Each step up is significantly more expensive per token:

ModelRoleCostSweet Spot
HaikuFast, cheapLowestExploration, simple transforms, file reading
SonnetBalancedModerateDay-to-day coding, refactoring, explanations
OpusPowerfulHighComplex multi-file work, architecture, novel problems
FableFrontierVery highTasks that push past what Opus can reason about

This isn't just a menu — it's a routing discipline. Every task has a right-sized model. Using Fable for something Sonnet handles fine is like hiring a senior architect to change a lightbulb. The lightbulb gets changed, but you're paying architect rates.

The Hidden Multiplier: Thinking Effort​

Cost per token is only half the equation. Thinking effort is the other half — and it's the one people forget about.

Higher thinking effort means more internal reasoning tokens before the model produces output. On Fable, high thinking effort can multiply your effective cost dramatically. The model is already expensive per token; asking it to think deeply on a routine task is burning money twice.

When to use high thinking:

  • Novel algorithmic problems Opus struggled with
  • Complex multi-constraint synthesis
  • Architecture decisions with many interacting tradeoffs

When to dial it down:

  • Applying a well-defined pattern to new code
  • Following explicit instructions with clear context
  • Tasks where the hard thinking was already done by a cheaper model

If you're not actively managing thinking effort per task, you're leaving cost savings on the table — regardless of which model you're using.

The Prerequisite: Model Routing Discipline​

Here's the test: can you confidently decide, before sending a prompt, whether it belongs on Haiku, Sonnet, or Opus?

If the answer is "I just use whatever's default" or "I always pick the best model available," you don't have routing discipline yet. Adding Fable to that workflow just adds another expensive option you'll misuse.

Routing discipline means:

  • You use Haiku for exploration. File search, reading unfamiliar code, quick checks, simple transformations. Haiku is fast enough that using anything bigger is pure waste.
  • You use Sonnet for production work. Standard code generation, refactoring, explanations, documentation. This is 70-80% of your daily tasks. Sonnet handles them well.
  • You use Opus when Sonnet visibly struggles. Complex multi-file refactors, subtle architectural reasoning, problems requiring deep context synthesis. You escalate to Opus — you don't start there.

Until this routing is second nature, Fable is a trap. You'll default to it "just in case" and hemorrhage tokens on tasks that didn't need frontier reasoning.

How to Actually Use Fable​

The right pattern isn't "send everything to Fable." It's: use cheaper models to prepare the ground, then give Fable a focused, high-value task.

The subagent workflow:

  1. Haiku explores. Read the codebase. Search for relevant files. Map dependencies. Gather context. This is cheap — let it run broadly.
  2. Sonnet preprocesses. Summarize findings. Draft initial approaches. Identify the hard sub-problem. Maybe generate a first attempt that's 80% right.
  3. Fable finishes. With context pre-gathered and the problem pre-scoped, Fable gets a clean, focused prompt. It applies frontier reasoning to the genuinely hard part — the part that actually needs it.

This is the difference between giving Fable a 50-file codebase and saying "refactor this" versus giving it a well-defined problem statement with relevant context already extracted. Same model, dramatically different token cost, often better results because the prompt is cleaner.

tip

Think of Fable as a specialist consultant. You don't hand a consultant a raw problem and say "figure it out." You do the research, narrow the question, and bring them a specific decision that needs their expertise. The preparation is what makes their time valuable instead of wasted.

When Fable Is Actually Worth It​

After all that gatekeeping — yes, there are tasks where Fable genuinely earns its cost:

  • Problems where Opus plateaus. You've tried Opus, it produces reasonable but not quite right solutions, and the gap requires a reasoning capability Opus doesn't have.
  • Complex synthesis across multiple domains. Combining constraints from security, performance, API design, and user experience simultaneously — where the interaction effects are what matter.
  • Novel problem-solving after pre-research. The exploration is done, the context is gathered, and now you need the model to find a creative solution in a large design space.

If you can't articulate why Opus isn't sufficient for a specific task, you probably don't need Fable for it.

The Payoff​

Teams that build routing discipline before adopting Fable get:

  • Lower average cost per task — most work stays on Sonnet where it belongs
  • Better Fable results — because they give it prepared, focused prompts instead of raw dumps
  • Sustainable frontier access — they can afford to use Fable when it matters because they're not burning budget on tasks that don't need it

The goal isn't to never use Fable. It's to use it deliberately, on the tasks that actually need it, with the preparation that makes it effective. Earn it first.

Further Reading​