We are going to name specific models in this post, which we generally avoid, because the comparison is genuinely useful right now and the tradeoffs are not obvious from the marketing. Everything here has a shelf life measured in months. Read it as a worked example of how to choose, not as a permanent answer.
The summary: Fable 5 is Anthropic's most capable widely released model and costs ten dollars per million input tokens and fifty per million output. Opus 5 is half that, at five and twenty-five, and is the model most teams should default to for agentic coding and enterprise work. If you stopped reading here you would do fine. But the reason we rarely have to make a capability judgement is that three or four hard constraints usually eliminate one option before quality enters the conversation.
The interesting question is not "which model is smarter." It is "which model am I actually allowed to run, given how my company handles data, what domain I work in, and how long my infrastructure will wait for a response."
The constraints that decide it for you
Data retention is the one that surprises people. Fable 5 requires thirty-day data retention and is not available under zero data retention. If your organisation is configured for ZDR, every Fable 5 request returns a 400 error, regardless of how well-formed it is. This is worth internalising because the failure mode is confusing: a perfectly valid payload gets rejected, and engineers burn an afternoon debugging the request body before somebody thinks to check the org's retention configuration.
For a lot of our clients this single line settles the question. Teams in regulated sectors, or anyone who negotiated ZDR as part of a security review, cannot use the more capable model at all. That is not a tradeoff to weigh; it is a door that is closed. It is also a good argument for finding out what your retention posture actually is before you architect around a model, which is the same instinct we argued for in the compliance piece: know the constraint before you build on the assumption it does not apply to you.
Domain guardrails are the second. Fable 5 runs safety classifiers targeting research biology and most cybersecurity content; it is explicitly not intended for those domains. Benign adjacent work can trip them, which means a legitimate security tooling workload or a life-sciences pipeline may see refusals that have nothing to do with the quality of your prompt. Opus 5 has elevated cybersecurity safeguards too, and can also decline, but the posture is different and the fallback story is cleaner.
On both models a declined request comes back as a successful HTTP 200 with a
refusal stop reason rather than an error, so code that reads the first content
block unconditionally will break. Check the stop reason before you read content. This is a
two-line change that will otherwise produce a confusing production incident at the worst
possible time.
The API differences that break code
Beyond the constraints, there are behavioural differences that matter more than a benchmark delta when you are actually integrating.
You cannot turn thinking off on Fable 5. Thinking is always on; an explicit request to disable it returns a 400. Opus 5 has thinking on by default but does let you disable it, provided your effort setting is high or below, pairing disabled thinking with the top two effort levels is also rejected. If you have a latency-sensitive path that relies on no-thinking responses, that path constrains your model choice directly.
Both bill thinking against your output cap. This catches teams migrating from older models where omitting the thinking parameter meant no thinking. On both of these, the default now thinks, and the maximum-tokens setting covers thinking plus the response together. A request sized tightly around the expected answer will truncate mid-output. Give it headroom or you will ship a bug that only appears on hard inputs.
Effort is the real cost lever, and it is not the one people reach for. Both models expose an effort ladder from low to max. The instinct is to run everything at the top for quality. In practice the low and medium settings on this generation are strong enough that a sweep across your own evaluation set usually finds a cheaper setting that holds quality, and a lower setting often reduces total cost more than switching to the cheaper model would. We now treat effort tuning as a required step rather than an optimisation, and it has more than once turned "we need the expensive model" into "we needed more effort on the cheap one."
The latency shape nobody plans for
The difference that has caused us the most operational trouble is not price or quality. It is that a single Fable 5 request on a hard task can run for many minutes.
That is not a defect. It is the model doing the work you asked for, and on genuinely difficult long-horizon problems it is the reason the model is worth paying for. But it breaks assumptions that are baked into ordinary infrastructure everywhere: HTTP timeouts, serverless execution limits, load balancer idle settings, job queue visibility windows, the user's patience. A request that takes twelve minutes is not a slow API call, it is a batch job wearing an API call's clothing, and it needs to be architected as one.
If you are going to use it for that kind of work, plan for streaming, plan for asynchronous check-ins rather than blocking, and give the user something to look at. Opus 5 also offers a fast mode, priced at a premium and available only through the first-party API, for the opposite case where output speed matters more than depth. Those two facts together are often what decides an interactive product: one model has a fast path and the other has a long one.
The actual decision tree
This is the sequence we walk, in order, and we usually stop before the last step.
One. Are you on zero data retention? If yes, use Opus 5. There is no decision to make. Two. Is your workload in research biology or most of cybersecurity? If yes, Fable 5 is not intended for it and you should expect refusals; use Opus 5 and build refusal handling regardless. Three. Do you need a genuinely fast interactive path, or the ability to run without thinking? If yes, Opus 5, which has both a fast mode and the option to disable thinking at moderate effort.
Four. Can your infrastructure tolerate a single request running for many minutes? If no, and you cannot change that, Opus 5. Five, and only if you reached it: is this your hardest class of work? Long-horizon autonomous runs, the most demanding reasoning, the problem your current model keeps failing. That is what the premium buys, and it is a real difference on those tasks. For everything else, including most agentic coding, Opus 5 is the better economic choice and not a compromise.
Notice that four of the five steps are not about capability. That is the actual finding here, and it generalises past these two models: as capability converges at the top of the market, the deciding factors migrate to operational and compliance properties. Which is roughly what happened with cloud providers, and with databases before that.
What we run where
Concretely, since abstractions are cheap. Our default for client work is Opus 5, at whatever effort level the evaluation sweep justifies, usually not the top one. It handles agentic coding, code review, and the bulk of production workloads without us feeling that we are economising.
We reach for Fable 5 in two situations. The first is a genuinely hard long-horizon task where we have watched the cheaper model fail: a large migration, a deep multi-day investigation, something where the cost of the run is trivial next to the cost of it not working. The second is when we want a second opinion from a different capability tier on something consequential, which is closer to how you would use a specialist than how you would use a default.
What we do not do is pick the expensive model to be safe. That is the reflex the pricing is designed to trigger, and on a workload with any volume it converts directly into the gross-margin problem we wrote about in the unit economics piece. Doubling your token price across the board to feel better about quality you have not measured is not caution, it is an unexamined cost.
The bottom line
Fable 5 is the more capable model, and on the hardest problems that gap is real and worth paying for. But the decision between it and Opus 5 is not usually a capability judgement, because your retention posture, your domain, your latency budget, and your need to control thinking will typically settle it first. Walk those constraints before you run a single benchmark. Then sweep effort levels on the model you are left with, because that dial moves cost and quality more than most teams expect and costs nothing to turn. The teams getting this wrong are not the ones picking the cheaper model. They are the ones who never checked which model they were allowed to run, and found out from a 400.