Fable 5 vs Opus 5: Picking a Frontier Model for Real Engineering Work

Claude Opus 5 shipped on July 24th, seven weeks after Claude Fable 5. So there are now two models sitting in what used to be one slot, and the second one costs half as much as the first.

That's the part worth thinking about. Fable 5 is $10 per million input tokens and $50 output; Opus 5 is $5 and $25 — exactly half, on both sides. Same 1M context window, same 128K max output, same 30-second-glance capability tier.

This post is three days old at time of writing, so treat it accordingly: I've read the API surface closely and run both against a couple of real workloads. I have not run a proper eval suite yet. What follows is how I'm making the call, not a benchmark.

The positioning, stated plainly

The model IDs are claude-fable-5 and claude-opus-5 — exact strings, no date suffixes, which is a nice change from the era of claude-3-5-sonnet-20241022.

Fable 5 is built for the hardest end of the difficulty curve: long-horizon autonomous work, deep multi-step reasoning, tasks where a single request legitimately runs for many minutes. Thinking is always on and cannot be turned off.

Opus 5 is the everyday frontier model — agentic coding, tool-heavy work, knowledge tasks — landing close to Fable's capability at half the price. Anthropic's own docs point you here first for complex agentic coding and enterprise work, and Fable stays as the top tier.

If you were on Opus 4.8, Opus 5 is a drop-in at identical pricing. That's the easy decision. The harder one is whether any of your workload justifies Fable's premium.

Where I think the premium is real

Not "which model is better on a benchmark." The question is which tasks change outcome — not just quality score — under a more capable model.

In my experience that comes down to one property: does the task fail catastrophically or gracefully when the model gets it slightly wrong?

Fable-shaped work:

• Overnight autonomous runs. A large refactor or migration that needs to hold coherence across hours and hundreds of tool calls. If it drifts at hour two, you've lost the whole run — not 5% of quality.
• One-shot implementations of well-specified systems. Where the alternative is a human spending two days.
• Genuinely novel problems with no obvious decomposition, where the model has to find the shape of the problem before solving it.

Opus-5-shaped work — which for me is most of it:

• Multi-file features and ordinary refactors
• Agentic loops with tool calls, retrieval, and a review step
• Code review and bug-finding
• Anything running per-request in a product, where latency and cost per session are real constraints

The rough test: if the work is supervised — a human reads the output, a test suite gates it, an eval catches regressions — take the cheaper model and put the savings into more attempts. If the work is unsupervised and long, the premium buys you something you can't get back later.

Three API details that will bite you

More consequential than the capability question, honestly, because these produce errors and surprise invoices rather than slightly-worse output.

1. Thinking defaults changed, and max_tokens caps thinking plus text together.

On Opus 4.8, omitting the thinking parameter meant no thinking. On Opus 5, omitting it runs adaptive thinking. Same request payload, different behavior — and since max_tokens is a hard cap on thinking and response text combined, a route that sized max_tokens tightly around its expected answer can now truncate mid-sentence.

You can still turn thinking off on Opus 5, but only at effort high or below. Pair thinking: {type: "disabled"} with xhigh or max and you get a 400 — validated per request, so a later call that raises effort fails even though earlier ones in the same conversation didn't.

On Fable 5 you can't disable it at all. {type: "disabled"} is a 400 at any effort; omit the parameter entirely and control depth with output_config.effort.

// Opus 5 — thinking on by default; effort is the depth control
const res = await client.messages.create({
  model: 'claude-opus-5',
  max_tokens: 64000,              // must cover thinking + response
  thinking: { type: 'adaptive' }, // equivalent to omitting it here
  output_config: { effort: 'xhigh' },
  messages,
})

Also gone on both, carried over from the Opus 4.7 generation: temperature, top_p, top_k, budget_tokens, and last-assistant-turn prefills all return 400. If you're coming from something older than 4.7, that's a real migration, not a string swap.

2. A refusal is an HTTP 200.

Both models run safety classifiers, weighted toward cyber and research-biology content. A declined request comes back as a successful response with stop_reason: "refusal" and a stop_details category — not an exception, not a 4xx.

Which means this is a live bug in a lot of code:

// Breaks on refusal — content may be empty
return response.content[0].text

// Check stop_reason first
if (response.stop_reason === 'refusal') return handleRefusal(response)
return response.content[0].text

Benign security work trips these occasionally — which matters if you build anything security-adjacent. Opus 5 added a fallbacks: "default" parameter that re-runs a declined request on a substitute model server-side, routed by refusal category. Worth turning on rather than pinning a specific fallback model yourself, since the right substitute depends on why the request was declined.

3. Fable 5 requires 30-day data retention.

This is the one that decided it for me on one project, and I nearly missed it.

Fable 5 is not available under zero data retention. If your organization's retention configuration doesn't meet the 30-day requirement, every Fable request returns a 400 — with a perfectly valid payload and no hint that retention is the problem.

For the healthcare work I've done, ZDR wasn't a preference, it was a term in an agreement. That makes Fable unavailable regardless of how good it is, and no amount of architecture fixes it. If you're in a regulated environment, check this before you evaluate anything else — it's a five-minute conversation that can save you a week.

Effort is the lever people ignore

Both models take output_config.effort at low through max. This is where most of the cost/quality tuning actually lives, and it's where prior-model defaults transfer worst.

For Opus 5, start at xhigh for coding and agentic work, high elsewhere — then sweep downward, because low and medium on this model are unusually strong. In several cases I've now seen medium produce equivalent output for a fraction of the tokens and latency.

Two things I'd flag from the docs that match what I've seen:

• Higher effort up front often reduces total cost on agentic work, because it plans better and takes fewer turns. The relationship isn't monotonic, so guessing doesn't work — you have to measure.
• At xhigh or max, give max_tokens real headroom. Start at 64K.

And a nice small win: Opus 5 dropped the minimum cacheable prefix to 512 tokens, from 1024 on Opus 4.8. Prompts you'd written off as too short to cache may cache now with no code change. Worth re-auditing if you followed the caching advice from a few months back.

One footgun: if you were disabling thinking on Opus 5 to save money, don't. It can occasionally write a tool call into its visible text instead of emitting a proper tool_use block — the turn succeeds, the call never runs, nothing errors, and in an agentic loop that phantom text pollutes every later turn. Leave thinking on and use low or medium effort instead. Same saving, no silent failure mode.

Delete your prompt scaffolding

This is the part I did not expect, and it's the most actionable thing in this post.

Opus 5 verifies its own work without being told. Instructions like "include a final verification step" or "use a subagent to double-check" now cause over-verification — extra tokens, extra latency, no quality gain. The fix is a delete, not a rewrite. Same for harness-level verification stages carried over from an older model.

Note that this inverts standard prompting advice. "Ask the model to check its answer" is generally sound and is wrong here. If you maintain a prompt library with that rule applied globally, it needs a carve-out.

Subagent delegation flipped direction. Opus 4.8 under-reached for subagents and needed encouragement to delegate. Opus 5 reaches for them readily — which multiplies cost, because each subagent re-establishes context, explores, reports back, and then the coordinator re-reads the report. If you added "delegate more" guidance for 4.8, take it out and add an explicit cap instead.

Fable 5 wants less prescription, not more. Prompts and skills written for earlier models are frequently too prescriptive for it and measurably reduce output quality. State the goal and the constraints; drop the step-by-step scaffolding. If you migrate a workload, A/B it with the old procedure removed — that's a real quality lever, not a tidiness exercise.

Both are more verbose by default. For Opus 5 specifically, effort is not the lever for output length — lowering it moves thinking volume without reliably shortening the visible response. A short explicit conciseness instruction is what works.

How to actually decide

Same answer as always, and it's the reason I keep banging on about evals:

Run both against your suite at three effort levels. Compare cost per resolved outcome, not cost per token. Then route — the hard 10% of your workload to Fable if it earns it, everything else to Opus 5.

The teams that adopted Opus 5 within a day of release are the ones with evals. The teams that will still be arguing about it in September are the ones running on vibes. That gap widens every time a model ships, and models are shipping every few weeks now.

Two logistics notes worth knowing before you shift traffic: Opus 5 draws on a separate rate-limit bucket from the combined Opus 4.x pool, so moving over neither inherits your existing headroom nor frees it up. And Priority Tier doesn't cover Opus 5 — a Priority request naming it fails validation.

---

My working default as of this week: Opus 5 at high or xhigh for essentially everything, Fable 5 reserved for long autonomous runs where a mid-run derail costs more than the price difference. I'll revisit once I have real eval numbers rather than three days of impressions.