Fable 5: Theo’s Take on Fallbacks, Subscription Limits, and Cost

I keep seeing claims that Fable 5 cannot code, has been weakened, or is unusably expensive. My opening repeats those claims sarcastically; I do not agree with them. After using the model, I want to separate what has been announced, what I observed and what remains uncertain.

The questions are fallback behavior, subscription availability and cost. Anthropic’s announcement said some routine coding and debugging could fall back to Opus 4.8. I think that wording caused confusion, but my experience alone cannot establish exactly how often routing happens for everyone.

During my first day and a half of ordinary work I did not notice a fallback. I have encountered refusals or rerouting on some cryptography-related puzzles and while configuring a development phone. Those examples show that false positives or restrictions can affect legitimate tasks, even though my ordinary work mostly continued.

I discuss safety screening as more than a simple keyword match: systems can examine both the request and the response. My interpretation of why a particular puzzle triggered a fallback is speculation; I cannot see the classifier’s internal decision for that request.

Anthropic has described research into a two-stage classifier: a lightweight probe screens interactions and can escalate suspicious cases to a more expensive classifier. The paper’s reported costs and error rates apply to its stated experimental setup. The video does not establish that every detail of that research is identical to Fable’s deployed routing.

The research claims fewer successful jailbreak attempts and lower overhead for the cascade compared with a more expensive screening approach. Those figures are test-specific, not a guarantee that harmful requests are always blocked or benign requests never refused. Improving protection and reducing false positives are both important.

I think Anthropic’s communication was poor, but in my own day-to-day use the restrictions were much less disruptive than some reactions suggested. Other people’s work can encounter different triggers, so they should test their actual tasks and report incorrect refusals rather than infer a universal result from mine.

A widely shared chart appeared to show a severe before-and-after performance drop. I question the benchmark’s reliability and say I had not personally investigated its full methodology. My skepticism and anecdotes do not independently prove that no regression occurred; the comparison needs transparent methods and reproducible evidence.

I looked at other results from the same benchmark and found rankings that conflicted with my experience. That is a reason to inspect the tasks, settings and methodology more closely, not by itself a scientific refutation. In my use the model still felt very capable.

Subscription access was a separate, real concern. At the time of the video, Anthropic said Fable would count for up to half of eligible plans’ weekly usage through July 7 and then be available through usage credits. That was a time-limited announcement, not a statement of current availability.

My usage screen had a separate Fable weekly meter. I had used about 23% at that moment, while acknowledging that I was using more than one plan. Limits, resets, workload and account arrangements differ, so my meter should not be interpreted as a typical allowance.

I suspect limited compute capacity and enterprise demand help explain the temporary restriction. I also speculate about pricing, marketing and the economics of serving a large model. Those are my interpretations of incentives, not confirmed details of Anthropic’s internal planning or margins.

One possible reason for a short access window is to observe how heavy users consume capacity across a week. I find that plausible, but it remains a hypothesis. A company’s announcement about capacity does not by itself prove every part of that explanation.

The statement I show says Anthropic aimed to restore Fable as a standard subscription offering when capacity allowed. It expresses an intention at that time, not a guaranteed date or current entitlement. Anyone making a purchase decision should check the provider’s present terms.

Cost can still be significant, whether billed directly or reflected in an allowance. My first practical suggestion is to compare reasoning settings. In my experience high worked well, while xhigh and max could use much more without a meaningful improvement for the tasks I tried.

I would start with high, low or medium and measure results rather than assume the most expensive setting is always best. My claim about large cost increases is based on my own runs; the best setting depends on the task, model version and quality requirement.

In one long session I triaged a backlog, closing, rewriting and merging PRs. I estimate the combined usage across Fable and delegated models at roughly $150–$200 at full token rates. I used subscriptions, so this is an estimated equivalent rather than a bill for that exact amount.

My other tactic is to have the coordinating model delegate work to other models when appropriate. I taught Claude Code to use Codex for some implementation and computer-use tasks. Routing can reduce the load on the expensive model, but only if the delegated output is actually good enough and reviewed.

Large document analysis, codebase scans and long computer-use sessions can consume many input tokens, especially when screenshots are involved. I use another model for some of these steps and return the findings to Fable for coordination. That reflects my available tools and subscription economics.

I report merging more than 15 PRs and closing others in this workflow. The equivalent usage estimate includes multiple models, and the subscription percentages I show depend on my reset timing. A count of merged PRs is not a direct measure of correctness or value.

The workflow does not need an elaborate collection of custom tools to begin. The important parts for me are giving the agent suitable instructions, delegating work with clear boundaries and reviewing what comes back. More detail about my configuration is in the follow-up demonstration.

My conclusions are provisional: try lower reasoning effort and route tasks where it makes sense; read the actual subscription terms; and evaluate fallback and performance claims with more than a viral chart or one person’s anecdotes. I remain enthusiastic about the model based on my own work.