Fable 5.1 or Opus 5.5 in Claude Code? A Decision Matrix Built on Evidence, User Reports, and Effort

1. The answer: start with Opus, then choose effort or Fable based on the failure

Which should you select in Claude Code: Fable 5.1 or Opus 5.5? As of October 29, 2026, the most reproducible starting point is Opus 5.5 at its default medium effort, followed by a change only when an observed result calls for one. Anthropic's selection guide likewise says to start most work with Opus 5.5 and consider Fable 5.1 for demanding reasoning, long-horizon agent work, or tasks that still fail on Opus at higher effort. That is vendor guidance, not a measured winner for every codebase. ^[1][2]

Two questions make the decision manageable. If the agent missed a relevant file, skipped tests, or stopped halfway, inspect its context and instructions and then raise effort if appropriate. If it read the right material, investigated thoroughly, and still made the wrong design or root-cause judgment, try Fable. Anthropic's Claude Code explanation makes a similar distinction between insufficient work and insufficient capability. ^[6]

This matrix is an editorial operating proposal built from public evidence, not an Anthropic rule. File or step count alone should never trigger Fable. A ten-file fix can require difficult architectural judgment; a much larger change can be mechanical if the correct procedure is clear. Size and reasoning difficulty are different dimensions.

2. Release order and model tier are different things

Fable 5.1 arrived on September 1, 2026, and Opus 5.5 on September 22. Opus is the newer release. The current primary Claude API lineup comprises Fable 5.1, Opus 5.5, Sonnet 5.5, and Haiku 5.5. Anthropic presents Fable as its highest-capability generally available tier and Opus as a primary choice for complex agentic engineering and knowledge work. Both Fable 5.1 and Opus 5.5 offer a one-million-token context window and a 128,000-token maximum output. A large repository does not require Fable because of a uniquely large context window. ^[3][4][1]

The official Claude Code documentation describes Fable as suited to long autonomous sessions, more investigation before action, and more self-verification. It is not the account-type default on any plan, so users must select it explicitly. /model fable or claude --model fable is the usual route; on some gateways the alias may resolve to another Fable version, so verify the actual model ID. The opus alias may also resolve differently by provider. A fair experiment records the model actually used. ^[5]

Neither “newer Opus always wins” nor “higher Fable tier always wins” follows. Capability varies with task and settings. Claude Code's instructions, accessible tools, permissions, test environment, and repository context also affect the outcome. Keep those factors comparable when interpreting what seems to be a model difference. ^[6]

Model selection changes which capabilities are available. Effort changes how thoroughly the agent investigates and verifies. They are different controls.

3. What benchmarks do and do not tell us

In Anthropic's Opus 5.5 launch evaluation, Terminal-Bench 4.0 scored Opus at 66.4% versus Fable at 55.8%; FrontierCode v1.1 scored 54.4% versus 50.3%; CursorBench 4.0 scored 57.8% versus 51.8%. On Humanity's Last Exam with tools, the figures were 67.7% versus 65.6%. These are strong reasons to try Opus. They are also vendor evaluations under particular harnesses, effort levels, and scoring rules. They cannot be translated directly into the quality difference on your next pull request. ^[7]

Independent evaluator Artificial Analysis reported an Intelligence Index of 58 for Opus 5.5 at max effort and 53 for Fable 5.1 in its September 22 assessment. It also found Opus at medium, high, xhigh, and max on its quality-versus-cost Pareto frontier. Yet this index combines several evaluations rather than scoring one complete, long engineering project. Its measurement also allowed a default model fallback. Without matching the measured configuration, “five points better on every task” is an unjustified reading. ^[8]

For long-horizon work, METR's predeployment report offers another perspective. On tasks tied to AI research and development, it assessed Opus 5.5 as a modest improvement over Fable 5.1. It did not see a huge jump and noted that both still have weaknesses in difficult, open-ended judgment. This challenges a blanket rule that long work always favors Fable. It remains an AI R&D evaluation and cannot settle every software or research workflow. ^[9]

Fable's remaining value is real as a possibility, not guaranteed as a result. Anthropic's Fable introduction documents strong long-horizon agentic coding, multi-step research, and artifact work; its current model guide still offers Fable when the highest capability is required. Public benchmarks favoring Opus do not rule out Fable succeeding on an unusually difficult task in your environment. Equally, the possibility alone does not justify selecting Fable for everything. ^[10][2]

4. How people use them: reports are a map, not a census

Public Claude Code discussions include people using Opus for daily implementation and saving Fable for initial project design or an impasse. One daily user reported barely noticing a difference on ordinary coding work, using Opus for nearly everything and Fable when beginning a project or when Opus could not progress. Another discussion describes assigning multi-repository design and review to Fable while Opus carries out implementation once requirements are clear. ^[11][12]

There are contrary reports. A user switching from Fable to Opus described more changes that drifted from existing code and preferred Fable for keeping direction during long work. Others describe Opus as more direct and less inclined to overthink. These are different projects, plans, prompts, dates, and human judgments, with no controlled assignment. Disagreement is a reason to test your own task categories, not to vote for a universal winner. ^[13][11]

The sources reviewed here do not provide a public statistic for what share of users abandoned Fable worldwide. Reddit post counts, upvotes, and a dedicated usage display do not supply that denominator. Fable's separate plan treatment is not evidence that it must be technically preferred. Claude Code documentation says that, depending on plan and seat tier, Fable use may draw on extra usage credits rather than included limits. ^[5]

The useful recurring pattern is to distinguish implementation, ambiguous design, long research, and final review. “Always let Fable review” is still too strong. Confirm review comments with reproduction or tests, and record which model wrote the change and which one found an actual defect.

Implementation, design, and review ask for different capabilities even within the same project. Reconsider the choice for each kind of work.

5. Measure cost per accepted task, not just price per token

Published API prices per million tokens are $10 input and $50 output for Fable 5.1, versus $4 input and $20 output for Opus 5.5. For ordinary input and output, Fable's unit price is 2.5 times Opus's. Cache reads are $0.25 for Fable versus $0.20 for Opus, a 1.25-times difference. Claude Code sessions often reread cached context, so 2.5 times cannot be assumed as the full-job cost ratio. Cache writes, misses, output, and retries all matter. ^[3][4][14]

As a fixed-volume illustration, assume one uncached task uses exactly 200,000 input and 50,000 output tokens on either model. Opus costs $1.80 and Fable $4.50 at those list prices. This is not a prediction of any actual Claude Code task. Fable might finish in fewer attempts, or Opus might need repeat work; the opposite can also happen. Anthropic's cost guide reports that, on its SWE-bench Pro subset, default-effort Opus 5.5 matched default-effort Fable 5.1 within run-to-run noise, at about one-fifth the cost per solved task. This is an internal measurement on particular tasks, not a forecast of your bill. ^[14]

Subscription users face a different constraint. API dollar prices and remaining Pro or Max usage, or extra credits, are not the same metric. If frequent Fable use exhausts a weekly allowance sooner, that opportunity cost matters. If Fable gets a consequential job accepted and saves substantial human rework, buying the cheapest tokens may cost more overall. Track completion rate, elapsed time, human review time, and allowance use together.

6. How effort and Ultracode change the answer

Effort is more than seconds spent reasoning. In Anthropic's description it can change how many files Claude reads, how many tools it calls, how thoroughly it verifies, and how far it proceeds before checking in. Opus 5.5 defaults to medium effort; Fable 5.1 defaults to high. Reports from the two untouched defaults are therefore not same-effort comparisons. Even the same label, such as high, does not mean identical underlying compute across models. ^[15][5]

Use low for light work you will inspect immediately, medium for well-scoped daily engineering, high for bugs in existing code and work with edge cases, and consider xhigh for long-running tasks. max is an experiment for the hardest jobs; official documentation cautions that it can lead to diminishing returns and overthinking. If raising Opus from medium to high fixes omitted verification, switching models may be unnecessary. If a well-investigated design judgment is wrong, comparison with Fable is more informative than endlessly raising effort. ^[5][15]

Three similar names refer to different controls. Ultracode is a Claude Code setting that organizes substantive work into a dynamic workflow, not a sixth effort level. Toggling it with /effort ultracode leaves the current effort level in place. Launching claude --effort ultracode, however, enables Ultracode and sets effort to xhigh; both variables changed, so record both in a comparison. ultrathink is a keyword requesting deeper reasoning on one turn. Where supported it may raise that turn to xhigh; it is distinct from the session's effort setting. ^[5]

Model, effort, and Ultracode are separate choices. Difficult work does not require maximizing all three at once.

7. Design a routing skill that separates advice from execution

Claude Code skills support model and effort frontmatter. A model override applies for the current turn while the skill is active; the session's model returns on the next user message. This is useful for a fixed-purpose /deep-audit skill. It is not a good foundation for a skill that edits its own frontmatter mid-run to permanently change the parent session's model. Claude Code also documents /model, --model, and subagent model selection as distinct mechanisms. ^[16][5]

A minimal router asks only five things before execution: (1) Can a test or other verifier check success? (2) How ambiguous is the problem? (3) Does it cross domains or repositories? (4) Will it run for a long time? (5) How costly is human recovery if it fails? It then gives a concise model, effort, reason, and escalation trigger. The following is an editorial design sketch, not a built-in Anthropic policy.

if routine && verifiable:
  recommend Sonnet 5.5 / medium, or Opus 5.5 / low
else:
  recommend Opus 5.5 / medium
if missed-files-or-tests:
  improve context and acceptance checks; retry Opus / high
if deep-work-and-uncertain-root-cause:
  compare Opus / high with Fable 5.1 / high on the same rubric
if Opus-high-clearly-tried-but-failed:
  try Fable / high; reserve xhigh or max for measured need

An output might say: “Opus 5.5, high. This crosses existing authentication paths and needs regression tests. If the tests pass but the root-cause explanation remains wrong, repeat the investigation with Fable 5.1 at high.” Explaining why and when to escalate is more useful than a sprawling point system. A fixed-purpose skill can specify model: opus and effort: high; a launcher for variable tasks can pass claude --model ... --effort ..., or dispatch to task-specific skills. Organization restrictions and environment variables may take precedence, so log the model and effort actually used. ^[16][5]

To calibrate, select several past jobs in each category: small edit, existing-code bug, cross-cutting change, and long research. Give each candidate the same request, environment, and acceptance criteria. Record reproducible defects, test outcomes, unnecessary diff, human review time, elapsed time, and token or plan use. Re-running only failures at higher effort or on Fable is also a strategy evaluated in Anthropic's cost guide. Success-only examples make every setting look sufficient. ^[14]

8. The practical rule: specify why a job deserves Fable

Start normal Claude Code engineering on Opus 5.5 at medium effort. Compare Sonnet or low effort for work you can verify quickly. When results are shallow, inspect the files read and checks performed, then improve context or effort. Add Fable 5.1 for difficult root-cause work, long autonomous tasks, or designs crossing several domains when Opus has investigated but has not met the acceptance bar. Neither model is universally best; your task's acceptance criteria decide.

Public user reports offer useful starting patterns, but they cannot establish how many people stopped using Fable or a file-count threshold above which it becomes necessary. The defensible October 2026 approach is to start with Opus and require a concrete gain to justify Fable's extra cost. For high-stakes research or a consequential pull request, put both against the same rubric once and keep the observed result. ^[2][14]