Use Opus 5.5 by default, Fable 5.2 for creative or stuck work, and set effort to high
Theo Browne explains how he picks between Anthropic's Opus 5.5 and Fable 5.2 for coding. He dismisses every other model, then covers cost, effort levels, speed and each model's working style. It is for developers who use coding agents daily and want a practical rule for which model to pick.
Why it matters
Most developers pick models by price per token or benchmark rank. Theo argues both mislead you. Subscriptions are heavily subsidized, so a Claude plan gets far more work done per dollar than cheaper models. The two top models also fail in opposite ways: Opus over-checks and bloats scope, while Fable skips details but finds clever fixes and is willing to ship. Matching the model to the task, and setting effort to high instead of max, should get you better results and fewer stalled PRs.
Key takeaways
- Only two models matter for real coding. Theo says that without a very specific reason, using anything other than Opus 5.5 or Fable 5.2 is a mistake. 00:53
- Subscriptions beat API pricing. He claims a $100 Claude plan gets more work done than $300 on any other model, so a tight budget is a reason to buy the plan, not to use cheaper open-weight models. 03:18
- High effort is the sweet spot. Medium ends turns a bit early, low is bad, and max forces overthinking even on simple tasks. Start at medium and move to high or X high when the model misses things. 07:51
- Fable is not slower than Opus. He measures Fable 5.2 at about 106 tokens per second, within error of Opus 5.5. Speed is no longer a reason to choose between them. 19:32
- Opus checks everything but bloats scope. Opus rarely misses things but lets features creep and seldom pushes back. Adding 'if you think this is a good idea, do it, otherwise suggest something else' to prompts improved his results. 23:46
- Provable tasks to Opus, unprovable to Fable. If the work can be verified and hill-climbed, such as a port to Rust, Opus is enough. Creative, exploratory or judgment-heavy work suits Fable. 35:35
- Use Fable to unstick stalled work. When Opus keeps finding more to do, Fable will audit the work, call it fine and ship it. So far, everything it cleared turned out fine. 38:57
- Haiku for bulk analysis, not code. He rejects using Haiku 5.5 for side tasks or writing code. Use it to scan large amounts of data or files for patterns that are hard to find with code. 11:17
In their words
"Everything else is cope."
00:59
"And then max is just garbage. Don't use it."
08:23
"Opus knows it's not as smart. So it double and triple checks everything."
14:20
"I have gotten much better results from Opus when I started adding to my prompts. If you think this is a good idea, do it. Otherwise, suggest something else."
23:48
"If you want a simpler way to choose, you can split this to be provable versus unprovable."
35:39
"I think this is one of the most underrated aspects of Fable is that it's willing to say you ship."
41:28
Where to watch
- 00:00 Many models available, narrowed down to Opus and Fable
- 01:47 Sponsor segment: Browserbase and the Stagehand SDK
- 02:58 Why Claude subscriptions are cheapest even on a tight budget
- 05:26 Simple split, then Addy Osmani's Anthropic guidance article
- 07:33 Effort levels: medium, high, X high and max compared
- 09:42 When Sonnet 5.5 and Haiku 5.5 make sense
- 17:38 Latency and subscription limits for Opus versus Fable
- 21:18 Opus as teacher's pet, Fable as lazy genius student
- 27:29 T3 Code performance example where Fable found the fix
- 31:13 Allen versus Brad analogy and the provable/unprovable rule
Caveats
- Most of this is Theo's opinion from his own work and evals. Little of it is shown as reproducible data.
- He had used Fable 5.2 for only about two days and says his view may change.
- The cost argument depends on current subscription subsidies and limits, which he notes could change.
- His dismissal of other models and of needs like zero data retention will not fit every team's privacy, budget or vendor constraints.