Opus or Fable? Match the coding model to the work

Theo Browne argues that choosing a coding model has become harder as options multiply. For his current work he narrows the practical choice to Claude Opus 5.5 and Fable 5.2, while acknowledging that people may have specific reasons to select something else.

Browne argues that subscription allowances can make the effective cost of a task look very different from published API prices. He claims Claude subscriptions offer particularly high usage for the price; the calculation depends on a user’s plan, workload and limits.

He displays a chart comparing model scores with estimated subscription cost per task. In his interpretation, Opus offers a strong balance, though he says performance and prices may change and a benchmark does not necessarily match real-world coding.

He stresses that subscriptions can make an expensive model’s usage more affordable than its nominal per-token API rate suggests. He expresses this strongly, but the video’s calculations reflect his chosen comparison and plan.

His initial shorthand is Opus for most work and Fable for the hardest tasks. But his own comparisons have shown Opus winning some cases and Fable missing details, so he does not treat the larger model as a universal upgrade.

Browne reviews an Anthropic guide to model selection. It lists Haiku, Sonnet, Opus and Fable, and describes Mythos as restricted access for security and life-science research. He notes that Mythos and Fable use the same underlying model with different safeguards.

One demonstration asks four models to write Python that recreates an image. Browne spots text placed at the bottom where the player controls obscure it, an example of the small presentation details he says Fable can overlook.

The guide recommends starting with Opus at medium effort. Browne finds medium occasionally ends too quickly without checking enough. After trying several settings, he prefers high for many tasks and suggests moving up from medium when the work requires it.

The guide’s default is medium effort, and Browne suggests starting there before increasing it when checks or reasoning are insufficient. His personal preference for high comes from his own workflows.

More effort is not automatically better. Browne says a maximum setting can force extensive reasoning even for simple problems, and cites benchmarks where Fable at maximum performed worse than at a lower setting. He likens this to overthinking a routine choice.

A clear specification does not necessarily make a task easy: migrations and performance work can still have difficult hidden constraints. Browne is skeptical of selecting Sonnet merely because the scope is written down, based on his own task costs and results.

In a task he calls Fish Slop, Sonnet used enough output tokens that the overall task cost rose despite its lower token price. He considers it potentially useful as a narrowly scoped tool rather than his default interactive model.

He sees Haiku as useful for high-volume pattern matching or finding occurrences across a codebase. He would not choose it to write code as a side task, even though the guide suggests smaller models for some delegated work.

The guide recommends Fable for especially hard technical problems and long unattended runs. It also suggests comparing a larger model at lower effort against a smaller one at higher effort, rather than assuming each extra reasoning level is the best value.

Browne hopes models will eventually adjust reasoning effort well enough that users no longer need to select a level. For now, he says the choice remains meaningful.

Browne uses extra-high effort for difficult verification, including Windows development and analyzing large logs. He values it when the model must build a reproduction, test edge cases or investigate a problem thoroughly before proposing changes.

He characterizes Opus as more likely to double-check and uncover details Fable glosses over. This thoroughness is not free: it can lead to excess work if the task lacks a clear boundary.

The guide assigns ordinary engineering to Opus, small high-volume tasks to Haiku, and difficult migrations or research to Fable. Browne says Opus can also coordinate substantial migrations: he used it to rewrite a compiler in Rust, including delegation to subagents.

A comparison showing Fable at high effort costing less than Opus at maximum is based on API pricing. Browne says subscription caps change the arithmetic: on his plan, Fable has a separate weekly limit, while more of the allowance can be spent on Opus.

He gives his own estimates of the API-equivalent usage available under a $200 subscription and says the difference can be larger than a simple two-to-one comparison. These are his observations, not a promise of a particular allowance.

Latency is another tradeoff. The guide recommends lower-effort settings when a person is waiting for an interactive answer and notes improvements in output speed across model generations.

Browne reports roughly 112 output tokens per second for Opus, about 145 for Sonnet and 255 for Haiku. He expected Fable to be much slower but says he observed about 106 tokens per second, close to Opus in his tests.

He compares his measurements with figures from Artificial Analysis and says Fable’s output rate is within the range he sees for Opus. The figures are observations, not guaranteed response times for every user or task.

In his experience both Opus and Fable handle tools, orchestration and long-running work well. He cautions that he has only used Fable 5.2 for roughly two days, whereas he has spent much longer with Opus; his impressions may change.

He personifies Opus as a diligent student: it follows instructions, checks work and persists, but can also expand a project or keep implementing feedback beyond what is useful. A strong tendency to comply does not mean it always challenges the original task.

Browne also looks for an agent that can still explain its work after a long conversation and repeated context compaction. He considers maintaining a clear account of the task distinct from merely continuing to act.

One prompt adjustment he finds useful is to ask the model to proceed if the idea is sound and otherwise suggest an alternative. In his experience that creates more room for pushback rather than automatically carrying out the requested approach.

His student analogy highlights a possible failure mode: an agent can remain diligent and still overlook a problem. He says asking for disagreement when appropriate has improved the usefulness of its responses.

He compares Fable to a different student who can find an unexpectedly clever answer but may skip details. The analogy is his way of describing observed behavior, not a claim about a model’s intentions or personality.

He invokes a classroom test that instructs students to read the entire paper before acting. In his analogy, Opus is more likely to follow that instruction, while Fable may take a shortcut that is useful in other situations.

For work where all requirements and edge cases must be read carefully, he tends to favor Opus. Fable may instead be useful when the task needs a new approach and the operator can independently check what it produces.

A T3 Code performance problem illustrates the combination. Long-running conversation threads became slow to load, so Browne wanted the models to reproduce the issue across machines and environments and test possible fixes.

He says Opus built a useful test environment and improved several cases. But an unresolved task list near the beginning of a long thread still caused the whole history to be included, and Opus did not initially recognize that source of excess data.

Browne then asked Fable to verify the work, explore the edge cases and propose solutions. It identified the persistent task-list issue and suggested passing the goal separately from the large history. He says that reduced data transferred by around 150 times in some cases.

In his parallel experiment Fable was less thorough at constructing the testing environment, even though it found a useful fix. The example supports using the models together, with each checking work the other has done.

Browne warns that an agent can keep acting on review feedback even when comments are minor. Without a stopping rule, a small change can expand into a much larger one. He adjusts his review loop to constrain that growth.

He compares two human reviewers: one knows the codebase and checks every rough edge; the other has broad experience and makes a faster judgment. He would choose the meticulous reviewer for high-risk work and the other when the priority is deciding whether to ship.

The codebase expert may leave numerous comments about prior failures and local conventions. The experienced outsider may focus on broader patterns and approve quickly; Browne says neither approach is automatically right for every change.

In this analogy Opus is the thorough reviewer and Fable is more willing to say a change is good enough. Browne values both styles, but says Fable can miss real problems while Opus can spend time on edge cases that matter less.

His rough distinction is whether success is readily verifiable. For work such as a language migration, he expects a careful model to improve against tests; for visual design or searching for unconventional approaches, he finds Fable more likely to offer variety.

He recommends starting with Opus and trying Fable when the result is unsatisfactory or the proposed options are too similar. He also reports cases where switching in the opposite direction solved a task, so he does not describe a fixed capability ceiling.

He speculates about why the models behave differently, including possible differences in training. He presents this as his interpretation rather than confirmed information about how Anthropic trained them.

For changes stuck in repeated reviews, he sometimes asks Fable to assess whether the remaining issues justify further work. He says Fable is more willing to regard a change as ready, which can help break a cycle of minor revisions.

In his own review evaluations, Fable sometimes misses issues caught by Sonnet and Opus. Browne says he inspected the missed reports and found some less important or incorrect, but acknowledges that the more permissive behavior can let real issues through.

Browne notes that his model-based judging system can reward reviewers for flagging every issue. He therefore inspects the underlying comments instead of treating the score alone as a definitive ranking.

Browne says the changes Fable advised him to merge had worked out so far, while explicitly allowing that this could change. His practical advice is to match the reviewer to the risk and use a second perspective when an agent is stuck.