Fable 5.2 is powerful, but Theo Browne still prefers Opus for everyday coding

Theo Browne opens with his reaction to Anthropic’s Fable and Mythos 5.2 release. After a day of tests, he sees a capable model with notable strengths but says it still needs careful supervision.

He compares it with the earlier Fable 5.1 and Opus 5.5 models, saying the new release improves speed and price while offering some different tradeoffs.

Browne jokes about counting em dashes in the announcement before outlining the areas he will examine: benchmarks, subscription usage, coding examples and visual design.

The release announcement describes software, hardware and scientific tasks. Browne says some coding demonstrations resemble things he had already seen other models do.

He describes Fable and Mythos as the same underlying model offered with different access and safety controls. He says the latter is available through verification programs for certain research uses.

He reads the announced API prices of $8 per million input tokens and $40 per million output tokens, and says an optional faster mode costs more. These are the figures discussed at release.

Browne says he has only skimmed the lengthy system card and plans a deeper review. He also notes the company’s suggestion to use Opus as a daily driver and reserve Fable for harder technical work.

He agrees strongly about Opus as a daily model but says his own experience with Fable leads him to qualify some of the broader recommendations.

Browne walks through the published benchmark tables. He highlights strong results in agentic coding, science, cybersecurity and protein design, while noting that access controls differ between the two versions.

His own codebase analysis tests tell a different story: he says Fable 5.2 sometimes falls behind Opus and Sonnet, even as it outperforms some other models in that set.

He describes Fable as capable of unusually clever answers but also prone to missing context and making surprising mistakes. He treats that variability as a reason to check outputs.

Browne cautions against assuming the highest reasoning setting is best for coding. In the results he reviews, maximum effort can cost more and perform worse than a lower setting.

He notes improvements on hardware-design benchmarks and anticipates more applications of coding-agent techniques in electrical engineering.

The company’s announcement describes large portions of its code changes as AI-written and gives a Python-to-Rust migration example. Browne compares those demonstrations with his own projects.

He reviews claims about science, mathematics and robotics, but says his own results on data analysis have been mixed: novel suggestions can coexist with unsupported leaps or missed context.

Browne says data-retention settings influence enterprise adoption. He contrasts the restrictions he describes for Fable with the availability of Opus for organizations with strict policies.

Using his T3 Code traffic as an example, he reports a sharp shift toward Opus 5.5 after release. These are observations from his own product rather than a measure of the whole market.

His evaluations ask models to analyze codebases and review real pull requests. For a TypeScript-to-Rust project, he reports that Fable made four incorrect claims out of 61 and cost about $23 in that run.

He says another model made fewer claims without false ones in that specific run, while Opus led his T3 Code analysis. He cautions that the results vary by project.

In pull-request review, he found Fable thorough but slow: the batch of eight reviews took roughly two hours. He values its willingness to overlook minor issues while noting that it can miss important ones too.

He recounts asking Fable to improve a page comparing usage costs. Although the redesign changed the appearance, he felt the first revision failed to make the numbers easy to compare.

Browne explains the subscription limits he observed: a model-specific weekly limit also counts against the overall weekly limit. Exhausting one does not necessarily mean the other is exhausted.

He tests a model-limit reset and observes how it changes the available weekly allowance without changing the reset schedule. He contrasts this with the scheduling behavior he has experienced elsewhere.

Using his own heavy-usage assumptions, he compares the notional API value of subscription usage. He emphasizes that API list prices and actual underlying costs are different quantities.

He reports approximately 106 output tokens per second for Fable 5.2 in his testing versus 112 for Opus. He speculates about why the newer model is faster and cheaper, without having confirmation of its architecture.

He estimates how combining Fable and Opus usage affects his monthly allowance, then notes that the actual number of useful turns depends on task length and how often a task finishes in one turn.

In frontend examples, he likes some animations and colors but dislikes other layouts. Turning off a design skill produces more generic results in the examples he shows.

He says he has needed to stay more involved with Fable than he hoped. The model can resolve hard problems but may pursue an obviously poor design decision until corrected.

One example concerns a slow machine: he compares the explanations he received from different models and prefers a concise account that identifies the storage difference.

In a discussion of MCP setup, he says Fable challenged a recommendation, then changed its position after being directed to relevant history. He values both pushback and the ability to revise an answer.

He also reports a privacy-display mistake: a page intended to hide an email address displayed it in a banner. The example reinforces his advice to audit generated results.

His distinction is that the model may be more capable at overcoming technical obstacles without being proportionally more autonomous at making judgments that need a human.

He describes praising an audit before noticing that he had accidentally run Opus rather than Fable. The mistake reinforces his view that Opus remains strong for routine work.

For a team handoff, he requested an explanation of an internal tool. The result looked polished but omitted the architecture diagram he wanted; a follow-up request added one.

Before the game demonstration, he encounters an input bug in the tool he is using and acknowledges that his own T3 Code product also has bugs.

He compares versions of a fish game produced with Fable and Opus. He likes the Fable version’s visuals but says the Opus version had a more enjoyable gameplay loop.

His conclusion is to combine the models where useful: he sees Fable as a strong specialist for demanding problems and Opus as a more practical default for his daily work.

Browne speculates about the version numbering but acknowledges he does not know the internal reason. He expects to revisit the comparison after more use.