Fable 5 High vs Opus 4.8 High vs Sonnet 5 High: A Practical Claude Model Guide

TL;DR

• On CursorBench 3.2, the cleanest current same-effort comparison, Fable 5 High scores 66.5%, Opus 4.8 High scores 58.0%, and Sonnet 5 High scores 56.9%.
• Fable 5 High is the capability choice. It leads Opus by 8.5 points on broad, Cursor-shaped engineering work, but Cursor reports an average cost per task of $8.77 versus $3.15 for Opus.
• Opus 4.8 High is my practical default. Its 1.1-point lead over Sonnet may not be statistically meaningful, but it used 33 steps and 33,548 tokens per task versus Sonnet’s 57 steps and 39,483 tokens.
• Sonnet 5 High is the pay-as-you-go value candidate, especially during Anthropic’s introductory $2/$10 per million input/output token pricing through August 31, 2026. Do not assume the lower token rate guarantees lower cost per completed task.
• Ultracode is not another model. It is a session setting that sends xhigh effort to the selected model and adds Dynamic Workflow orchestration for substantive tasks.
• For Ultracode, my default is Opus 4.8 as coordinator. Use Fable 5 for unusually valuable, ambiguous, long-horizon work. Use Sonnet 5 for decomposable work where cost matters more than orchestration efficiency.
• A promising experiment is Fable or Opus as the lead model with Sonnet workflow agents. Claude Code supports that override. Separately, Cognition found that an unnamed cheaper sidekick reversed the expected Fable–Opus cost ordering in its Fusion harness; that result did not test Sonnet or Ultracode.

What You Will Learn Here

• How Fable 5, Opus 4.8, and Sonnet 5 compare at the same high effort setting
• Which benchmark results are actually comparable and which use different harnesses or effort levels
• Why per-token price can disagree with cost per completed coding task
• How high, xhigh, max, and ultracode differ
• Which model I would choose for daily coding, difficult refactors, migrations, and parallel workflows
• How to implement a small Claude Code routing policy and evaluate it on your own repository

The Question Is Effort-Specific

Anthropic released:

• Claude Opus 4.8 on May 28, 2026
• Claude Fable 5 on June 9, 2026
• Claude Sonnet 5 on June 30, 2026

All three support a 1-million-token context window, up to 128,000 output tokens, adaptive reasoning, and the effort ladder from low through max. Their default effort is high.

One caveat matters before comparing them:

Anthropic calibrates effort separately for each model. The same label does not guarantee the same hidden reasoning-token allocation.

high is still the most useful operational comparison because it is the default on all three models. It is not a claim that Anthropic assigned identical compute to each run.

Unless noted otherwise, the benchmark numbers below come from Cursor’s agent harness, while the routing recommendations target Claude Code. A model score does not transfer automatically between those harnesses.

The Cleanest High-Effort Comparison

CursorBench 3.2 is the most useful current source for this specific question because it reports all three models at high in the same production agent harness.

Cursor describes the benchmark as tasks derived from real coding sessions, including ambiguous requests, multi-file edits, codebase understanding, bug finding, planning, code review, instruction following, and advanced tool use. Version 3.2 was introduced on July 8, 2026.

The useful conclusions are not simply “first, second, third.”

Fable 5 High leads most clearly on broad coding work

Fable leads Opus by 8.5 percentage points, a much larger gap than the 1.1 points separating Opus and Sonnet.

That lead costs substantially more:

Fable High average benchmark cost
    $8.77 / $3.15
    = 2.78x Opus High

This is not a reason to reject Fable. It is a reason to route it deliberately.

The premium is easiest to justify when a failed first attempt creates expensive consequences:

• a migration has to be restarted
• a human must reconstruct a partially completed plan
• a large diff needs another review cycle
• the task is difficult to decompose before the model starts
• the work will run asynchronously with little human steering

Opus 4.8 High is the strongest default

Opus scores only 1.1 points above Sonnet, and Cursor warns that small score differences may not be statistically meaningful.

The efficiency signals are more interesting:

• Opus used about 15% fewer tokens per task
• Opus used 33 steps per task versus Sonnet’s 57
• Cursor’s listed task cost was slightly lower for Opus despite Opus having the higher API token rate

That does not prove Opus will always be cheaper. It shows why model selection should use cost per accepted result, not rate-card price alone.

For an engineer who wants one dependable Claude Code default, I would start with Opus 4.8 High.

Sonnet 5 High is still the volume candidate

Sonnet’s API price is:

• $2 per million input tokens and $10 per million output tokens through August 31, 2026
• $3 per million input tokens and $15 per million output tokens afterward

Opus is $5/$25 and Fable is $10/$50.

That makes Sonnet attractive for:

• high-volume feature work
• bounded bug fixes
• test generation
• documentation
• worker agents with narrow scopes
• workloads where a human is already steering each loop

But the CursorBench result is a warning against simplistic cost claims. Sonnet took more steps and tokens than Opus in that harness. After the promotional price ends, the cheaper model per token may not be the cheaper model per completed task.

High answers which model should handle an ordinary coding session. Ultracode asks a different question: which model should coordinate a substantive generated workflow. I return to that distinction after cross-checking the High result.

Cross-Checking the Result

One benchmark should not decide a production routing policy. The other public results generally support the hierarchy, but their configurations need careful labeling.

Terminal-Bench shows a narrower Fable advantage

In the Fable 5 system card, Anthropic reran Terminal-Bench 2.1 with the mini-SWE-agent harness at high:

Sonnet is included for context, not as an apples-to-apples High comparison.

The 1.6-point Fable–Opus gap is far smaller than the 8.5-point gap on CursorBench. My inference is that Fable’s premium becomes more valuable as work grows broader, more ambiguous, and more dependent on sustained codebase judgment. A bounded terminal task gives Opus more opportunity to stay close.

There is another important caveat: 20.9% of Fable’s Terminal-Bench trials triggered a safety refusal and fell back to Opus 4.8 for the rest of the trajectory. The reported 84.3% is therefore a deployed Fable configuration, not a pure Fable-only result.

SWE-bench shows Anthropic’s published Max-effort results

Anthropic’s system cards report the following SWE-bench results, generally using adaptive reasoning at max effort:

These numbers are useful for understanding Anthropic’s maximum published capability order. They are not High-effort results and should not be placed beside CursorBench High without that qualification. Fable’s production-configuration results can also include safeguards and Opus fallback.

SWE-bench Verified is also nearing saturation at the frontier. SWE-bench Pro and private, current coding tasks provide more separation, but no benchmark perfectly predicts performance on your repository.

FrontierCode warns us to keep benchmark versions current

Cognition’s original FrontierCode methodology evaluates whether a patch is correct, disciplined, tested, and mergeable—not only whether it passes one visible test.

On July 7, 2026, Cognition released FrontierCode 1.1 and:

• refined its fair-internet-use policy
• audited more than 1,000 grading criteria
• demoted 75 overly strict blocker criteria
• deprecated the Diamond subset because its hardest-task results were too noisy

That is a useful benchmark-literacy lesson: do not keep repeating an old leaderboard row after the benchmark author changes the methodology.

On the earlier FrontierCode v1 Main comparison at xhigh, Fable scored 46.3% and Opus scored 34.3%. Sonnet’s later system card reported 38.8% using its standard Max configuration, so the three rows should not be treated as one same-effort leaderboard. The defensible claim is narrower: Fable led the comparable Fable–Opus v1 run. Applying that result to long-horizon production work remains an inference.

Specifications and Cost Shape

Sonnet 5 also uses a new tokenizer that Anthropic says can produce roughly 1.0–1.35 times as many tokens for the same input as Sonnet 4.6, depending on content. That does not make Sonnet 5 a bad value. It means migration estimates should use observed token counts rather than multiplying old traffic by the new rate card.

For coding agents, use this cost model:

cost per accepted result =
  lead-model tokens
  + worker-model tokens
  + cache reads and writes
  + failed attempts
  + repair loops
  + human review time

The model with the lowest first-request price can lose if it needs more turns, produces a larger diff, or requires another human review cycle.

My Opinionated Routing Recommendation

This is a starting policy, not a universal leaderboard.

The strongest reason to override it is your own acceptance data.

Ultracode Changes the Comparison

Claude Code’s model-configuration documentation defines Ultracode precisely:

Ultracode is a session setting that sends xhigh effort to the model and additionally has Claude orchestrate Dynamic Workflows for substantive tasks.

In short, CursorBench High is Cursor’s agent harness with one selected model at high. Ultracode is xhigh plus automatic workflow planning. A generated workflow may run steps sequentially or in parallel; it does not necessarily include dedicated reducer and verifier stages.

Calling Ultracode an effort level is convenient in the CLI, but technically incomplete. It adds a harness behavior that normal xhigh does not. For the full workflow architecture, limits, and guardrails, see the Ultracode architecture blueprint.

Xhigh is the closest benchmark proxy

CursorBench 3.2 reports:

Cursor calls this row Extra High; Claude Code exposes the corresponding setting as xhigh. max is different: it removes the reasoning-token constraint and can improve the hardest coherent single-agent tasks, but Anthropic warns about diminishing returns and overthinking. Ultracode uses xhigh, not max, because it adds workflow orchestration rather than unconstrained reasoning to every model call.

Moving from High to Xhigh produced:

Those are single-agent benchmark costs. A real Dynamic Workflow can launch multiple agents, so its total session cost may be much larger.

The Xhigh table tells us about the reasoning setting. It does not independently prove how much the workflow layer improves completion.

Fable 5 with Ultracode

Use this for:

• codebase-wide migrations
• broad investigations with several uncertain work streams
• difficult tasks that must remain coherent across long execution
• high-value asynchronous work with a strong test oracle

Why it is compelling:

• Fable has the largest coding-benchmark lead
• Anthropic positions it specifically for long-running agents
• Cursor reports that Fable leads from Medium effort upward

Why it is risky:

• Fable Xhigh already costs $11.73 per CursorBench task before workflow fan-out
• Dynamic workers multiply context and review volume
• cybersecurity, biology/chemistry, distillation, or frontier-LLM-development context can switch the Claude Code session to its configured Opus target
• a weak task definition can turn expensive capability into expensive churn

My recommendation: reserve Fable Ultracode for tasks where the acceptance criteria are measurable and the expected value of avoiding a failed run is high.

Opus 4.8 with Ultracode

This is my default Ultracode configuration.

Opus Xhigh is within 0.7 points of Sonnet Xhigh on CursorBench, while using 40 steps instead of 67. It is much cheaper than Fable and avoids Fable’s content-based model fallback.

Use it for:

• large but bounded refactors
• migrations with clear package or service boundaries
• repository audits that need independent verification
• work that benefits from several parallel discovery lanes

Opus is the least dramatic recommendation, which is exactly why it is useful: it offers a strong coordinator without making every workflow a frontier-model budget event.

Sonnet 5 with Ultracode

Sonnet is credible when the workflow is wide but not deeply ambiguous:

• one worker per independent package
• repetitive fixes with deterministic tests
• documentation or test generation across many modules
• parallel investigations that produce evidence rather than overlapping edits

The concern is single-agent efficiency. On CursorBench Xhigh, Sonnet used 67 steps versus Opus’s 40. Whether Dynamic Workflows amplify or reduce that difference has not been independently measured.

My recommendation: use Sonnet Ultracode when tasks are already easy to partition and worker outputs are cheap to verify. Do not select it solely because its per-token price is lower.

A Strong-Lead, Cheaper-Worker Experiment

The evidence in this section is indirect. Cognition tested its own Fusion harness with the same unnamed cheaper sidekick for both lead models. It did not test Sonnet workers or Claude Code Ultracode.

Claude Code lets you override the model used by subagents, agent teams, and workflow agents with CLAUDE_CODE_SUBAGENT_MODEL.

That enables a useful experiment:

CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-5 \
  claude --model claude-fable-5 --effort ultracode

On the native Anthropic API, the intended role split is:

Fable Xhigh main session
    -> interpret the request and generate the workflow

Sonnet workflow agents
    -> execute every agent role spawned by that workflow

The override applies to every workflow agent, not only implementation workers. It can therefore move researcher, reducer, or verifier roles to Sonnet when the generated workflow contains them. On third-party providers, use the provider’s full Sonnet 5 model ID rather than assuming the sonnet alias resolves to Sonnet 5.

Cognition reported a related result with its Fusion architecture on FrontierCode 1.1:

Fable’s lead used 11.5 turns per run with the unnamed sidekick, while Opus used 26.5. Cognition’s conclusion was that better delegation and context management outweighed Fable’s higher per-token rate.

This is promising evidence for asymmetric model routing. It is not evidence for Sonnet specifically, and it is not proof that Claude Code Ultracode will reproduce Fusion’s economics. The harness, worker model, prompts, model efforts, and orchestration policy differ.

Treat the command above as an experiment and measure the whole session.

Implement a Small Routing Policy

You do not need a platform router to test this model split. Start with a small wrapper:

#!/usr/bin/env bash
set -euo pipefail

task_class="${1:?usage: claude-route <routine|complex|migration>}"
shift

case "$task_class" in
  routine)
    exec claude --model claude-sonnet-5 --effort high "$@"
    ;;
  complex)
    exec claude --model claude-opus-4-8 --effort high "$@"
    ;;
  migration)
    export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-5
    exec claude --model claude-fable-5 --effort ultracode "$@"
    ;;
  *)
    echo "unknown task class: $task_class" >&2
    exit 2
    ;;
esac

The policy is intentionally conservative:

routine
  -> cheapest capable daily loop

complex
  -> stronger single coordinator, no automatic fan-out

migration
  -> strongest lead, Xhigh reasoning, workflow orchestration,
     cheaper bounded workers

Starting Ultracode with --effort ultracode requires Claude Code v2.1.203 or later. Ultracode is session-only. If Dynamic Workflows are unavailable or disabled, the command falls back to Xhigh without workflow orchestration.

Evaluate the Policy on Your Repository

Use at least 12 representative tasks:

• four routine edits
• four complex bug fixes or refactors
• four broad migrations, audits, or multi-package changes

Run every eligible model/mode against the same repository commit, tool policy, task text, and acceptance tests. Use at least five repeats per condition because agents are nondeterministic, then compare medians and result ranges rather than selecting one favorable run.

This eval is narrower than the general model and Ultracode evals in the related articles. It deliberately crosses:

• the same commit and task across all three models
• high, xhigh, and Ultracode as separate modes
• Fable runs with explicit fallback-model tracking

Record:

type ClaudeModelRun = {
  taskId: string;
  model: "fable-5" | "opus-4.8" | "sonnet-5";
  mode: "high" | "xhigh" | "ultracode";
  accepted: boolean;
  deterministicTestsPassed: boolean;
  inputTokens?: number;
  outputTokens?: number;
  totalCostUsd?: number;
  wallTimeMinutes: number;
  agentSteps?: number;
  workerCount: number;
  repairLoops: number;
  humanReviewMinutes: number;
  fallbackModel?: string;
};

Choose with these metrics:

1. accepted-task rate
2. cost per accepted task
3. human review minutes per accepted task
4. wall-clock time
5. fallback, retry, and repair frequency

Do not promote a model because it produced the most code or launched the most agents. Promote it when it produces more accepted work within your cost and review budget.

Benchmark and Deployment Caveats

Keep these limitations visible:

1. CursorBench is relevant, not universal. It uses Cursor’s production agent harness and Cursor-shaped tasks.
2. Small differences may be noise. Cursor explicitly warns that close scores may not be statistically meaningful.
3. Anthropic’s headline system-card tables usually use Max. They should not be mislabeled as High.
4. Harness choice can move scores substantially. Terminal-Bench results differ between mini-SWE-agent, Terminus-2, Claude Code, and Codex CLI.
5. Benchmark contamination is an active problem. Cursor and Cognition both changed evaluation practices in 2026 to reduce retrieving existing fixes instead of deriving them.
6. Fable results can include Opus fallback. That is realistic product behavior but complicates pure model attribution.
7. Ultracode needs a separate eval. Xhigh single-agent scores do not measure the full Dynamic Workflow layer.
8. Parallelism moves the bottleneck. More workers can reduce wall time while increasing token use, merge conflicts, and human review.

When a Team Should Adopt This Policy

A three-model policy is worthwhile only when the team can maintain it. Someone must own model allowlists, billing, benchmark refreshes, fallback behavior, and exceptions. Repositories also need deterministic tests or explicit acceptance criteria; otherwise the stronger model merely produces a more expensive result that is still hard to approve.

If those controls are missing, standardize on Opus 4.8 High first. Add Sonnet for measured high-volume lanes and Fable only after the team can identify expensive-to-fail work consistently.

Final Recommendation

If I had to standardize one policy today:

Default coding:
    Opus 4.8 High

High-volume, bounded work:
    Sonnet 5 High

Hard, long, expensive-to-fail work:
    Fable 5 High

Large substantive workflow:
    Opus 4.8 Ultracode

Exceptional migration with strong acceptance tests:
    Experiment with Fable 5 Ultracode + Sonnet workflow agents

The important distinction is not simply model size.

It is task shape:

bounded and steerable
    -> optimize unit cost and latency

complex but still one coherent problem
    -> optimize coordinator efficiency

ambiguous, long-running, and expensive to restart
    -> pay for the stronger model and verify aggressively

Fable 5 is the benchmark winner. Opus 4.8 is the operational default. Sonnet 5 is the volume tool.

Ultracode does not erase those roles. It makes routing and total workflow cost more important.

Related Reading

• Claude Code Ultracode Architecture Blueprint for Cursor and Custom Agents
• Build an Ultracode-Like Coding Workflow with Agno and AgentOS
• Build an Ultracode-Like Coding Workflow with LangGraph
• A Phase-by-Phase Model Strategy for GitHub Spec Kit in 2026
• Claude Sonnet 4.6 1M vs Composer 2.5 Fast
• When to Use Subagents vs. the Main Chat Thread

Sources

• Anthropic, “Introducing Claude Opus 4.8”, May 28, 2026.
• Anthropic, Claude Opus 4.8 System Card, May 28, 2026.
• Anthropic, “Claude Fable 5 and Claude Mythos 5”, June 9, 2026.
• Anthropic, Claude Fable 5 and Claude Mythos 5 System Card, June 9, 2026; corrected June 11, 2026.
• Anthropic, “Introducing Claude Sonnet 5”, June 30, 2026.
• Anthropic, Claude Sonnet 5 System Card, June 30, 2026.
• Claude Platform Docs, “Models overview”, accessed July 15, 2026.
• Claude Code Docs, “Model configuration”, accessed July 15, 2026.
• Claude Code Docs, “Orchestrate subagents at scale with Dynamic Workflows”, accessed July 15, 2026.
• Cursor, “CursorBench 3.2”, accessed July 15, 2026.
• Cursor, “How we compare model quality in Cursor”, March 11, 2026.
• Cursor, “Reward hacking is swamping model intelligence gains”, June 25, 2026.
• Cognition, “Introducing FrontierCode”, June 8, 2026.
• Cognition, “FrontierCode 1.1”, July 7, 2026.
• Cognition, “Making Fable Cheaper Than Opus”, July 13, 2026.