Claude Low Effort Compared: Fable 5 vs Opus 4.8 vs Sonnet 5

TL;DR

• On CursorBench 3.2, Fable 5 Low scores 62.1% at $4.46 per task, Opus 4.8 Low scores 53.1% at $2.02, and Sonnet 5 Low scores 47.7% at $1.30.
• Sonnet 5 Low is the cheapest, but I would reserve it for bounded, high-volume work with deterministic checks.
• Opus 4.8 Low is the measured middle tier, but only after an evaluation on your repository shows that Low is acceptable. It costs $0.72 more per CursorBench task than Sonnet and gains 5.4 points while using six fewer reported steps.
• Fable 5 Low has the highest CursorBench score among these three Low configurations. It gains another 9 points over Opus Low, but costs $2.44 more per task.
• The surprising result is cross-effort: Fable Low lands near Opus Max, Sonnet Max, and Opus Xhigh while costing less and using far fewer tokens and steps. Small score gaps may still be benchmark noise.
• CursorBench includes planning work but does not publish a planning-only Low-effort score. My planning recommendations are therefore informed judgment, not a separate planning leaderboard.
• A practical split is Sonnet Low for routine execution, Opus Low for normal plans and multi-file work after Low passes your repo eval, and Fable Low for ambiguous or expensive-to-restart plans.
• A three-model Low policy only makes sense when a team owns tests, acceptance rubrics, billing visibility, and escalation. Otherwise, keep the vendor-recommended High or Xhigh default.

What You Will Learn Here

• How the three Claude models compare at the same low effort setting
• Which model is cheapest, which has the highest benchmark score, and which offers the best middle ground
• Why Fable Low can be more economical than Max or Xhigh configurations of cheaper models
• What the published evidence does and does not say about planning
• Which Low-effort model to use for routine edits, reviews, plans, and migrations
• How to implement and evaluate a small Low-effort routing policy

Low Effort Is Not a Smaller Model

Claude’s effort parameter controls overall response-token spending, including thinking, user-facing text, tool calls, and function arguments. It does not replace the selected model with a smaller one.

At low:

• the model is less eager to spend response tokens
• tool calls and explanations may be shorter
• simple requests may skip extended reasoning
• latency and cost generally decrease
• moderately complex work has a higher risk of under-thinking

The same label is not identical compute across models. Anthropic calibrates the effort scale per model, so Fable Low, Opus Low, and Sonnet Low should be treated as product configurations rather than equal hidden token budgets.

All three models default to high, not low. Anthropic’s current guidance is:

• Fable 5: use High for most work and Medium or Low for routine work; lower Fable settings often exceed Xhigh performance on prior models.
• Opus 4.8: start at Xhigh for coding and agentic work; step down only after your evals show that quality holds.
• Sonnet 5: use Low for high-volume, latency-sensitive, simple work; Anthropic warns that moderately complex tasks can under-think at Low.

That guidance matters. Low is a cost optimization that needs an escalation path, not a universal replacement for High.

This article is the Low-effort companion to Fable 5 High vs Opus 4.8 High vs Sonnet 5 High. That piece covers High, Xhigh, Max, Ultracode, and broader benchmark checks. The question here is narrower: if you deliberately operate on the Low frontier, how do these three models rank, and when can a stronger model at Low beat a cheaper model at expensive effort?

Adaptive-thinking defaults also differ. Fable always uses adaptive thinking, Sonnet enables it by default, and Opus API requests require thinking: {type: "adaptive"} to enable it. Effort still controls text and tool-call spending when thinking is disabled.

The Same-Effort Comparison

CursorBench 3.2 is the cleanest public three-way comparison at Low. CursorBench is Cursor’s offline evaluation suite, based on real engineering sessions and tasks paired with committed solutions through Cursor Blame. Its current task set covers editing, refactoring, bug fixing, codebase understanding, bug finding, planning, code review, instruction following, and advanced tool use.

All metrics below are a July 16, 2026 snapshot. Sonnet 5 currently uses its introductory $2/$10-per-million-token pricing through August 31, 2026. If the same benchmark usage cost scaled linearly to the September 1 standard price of $3/$15, Sonnet Low would rise from $1.30 to about $1.95 per task. Opus Low’s listed premium would then shrink from $0.72 to roughly $0.07. Recheck the live leaderboard before making a lasting policy.

Cursor calculates task cost from recorded API usage and published token prices, including cache reads and writes. The score and cost use the same task weights. Cursor also warns that small score differences may not be statistically meaningful.

These three points form a cost–quality frontier:

lower cost                                              higher capability

Sonnet Low ----------------> Opus Low ----------------> Fable Low
$1.30 / 47.7%              $2.02 / 53.1%              $4.46 / 62.1%

Among these three Claude Low configurations, none is strictly dominated by another: every increase in benchmark score also increases task cost.

What Each Upgrade Buys

At current pricing, Sonnet-to-Opus is a 55% task-cost increase for an 11% relative score improvement. The September pricing change could remove most of that listed cost gap if usage stays constant.

Opus used more tokens than Sonnet but Cursor reports six fewer steps per task. Cursor does not publicly define step on the leaderboard or show that fewer steps reduce drift, so any operational benefit is a hypothesis to test.

Fable’s published token rates are exactly twice Opus’s in every category. Cursor nevertheless reports $4.46 versus $2.02 per task—a 2.21-times ratio—because aggregate token totals do not expose the input, output, cache-read, and cache-write mix used for the cost calculation.

This is the central Fable trade-off:

You are paying for a stronger model, not necessarily for a longer trace.

Fable Low is not the cheapest route. It is the configuration to consider when avoiding a failed or incomplete first pass is worth more than roughly three additional benchmark-task dollars.

The Cross-Effort Surprise

The most useful finding appears when Low is compared with expensive configurations of the other models:

On this benchmark:

• Fable Low scores 2.7 points above Opus Xhigh at nearly identical cost. That score gap may still be noise; the larger difference is Fable’s lower token and step count.
• Fable Low is only 0.2 points below Opus Max while costing 23% less.
• Fable Low scores 0.6 points above Sonnet Max while costing 31% less.
• Fable Low uses dramatically fewer tokens and steps than either Max configuration.

The 0.2- and 0.6-point gaps may be noise. Against the Max configurations, the cost, token, and step differences are large. Against Opus Xhigh, cost is nearly identical, although Fable uses fewer tokens and steps.

This does not prove that Fable Low replaces Opus Max or Sonnet Max on every workload. It shows that model capability and effort must be tuned together. Turning up a cheaper model can cost more than selecting the stronger model at Low.

For the High, Xhigh, Max, and Ultracode comparison, see Fable 5 High vs Opus 4.8 High vs Sonnet 5 High.

CursorBench is the only public same-harness three-way Low comparison I found as of July 16, 2026. Cognition’s July 13 Fusion experiment also reports strong Fable Low economics with an unnamed cheaper sidekick. It uses a different orchestration stack and does not replace CursorBench for Claude routing; treat it only as directional evidence that a Low-effort lead can delegate economically.

Which Low Model Is Best for Coding?

My Sonnet rule is intentionally narrow:

If the expected patch is obvious from the task
and deterministic tests can decide success,
Sonnet Low is a reasonable first attempt.

Anthropic recommends Opus Xhigh for coding and says to step down only after evaluation. Calling Opus Low the middle tier is therefore a team policy, not vendor guidance. Fable has the strongest Low aggregate here and Anthropic reports improvements in ambiguity handling, review, debugging, and delegation, but Cursor does not publish those as separate Low subscores.

If the work is interactive editing inside Cursor rather than Claude Code or the API, also benchmark Composer 2.5 Fast. Sonnet Low is a Claude-platform volume lane; it is not automatically the cheapest Cursor-native coding loop.

Which Low Model Is Best for Planning?

There is no clean public planning-only Low leaderboard for these three models as of July 16, 2026.

CursorBench is relevant because its task set includes planning, codebase understanding, and review. Its public leaderboard is an aggregate, so it cannot answer:

What percentage of planning tasks did each Low model pass?

The recommendations below are therefore editorial judgment informed by the aggregate benchmark and vendor behavior guidance. For phase-based planning and implementation routing, see A Phase-by-Phase Model Strategy for GitHub Spec Kit; this section stays at the model-effort layer.

Opus leads Sonnet’s aggregate score by 5.4 points, but Cursor publishes neither a planning-only breakdown nor confidence intervals. Fable has the highest aggregate Low score of these three and stronger vendor positioning for ambiguity and delegation. Neither fact proves a planning-specific win.

My Opinionated Routing Policy

Incoming task
    |
    +--> Mechanical, narrow, deterministic?
    |       -> Sonnet 5 Low
    |
    +--> Normal code change or implementation plan?
    |       -> Opus 4.8 Low, only after the repo eval passes
    |
    +--> Ambiguous, cross-system, expensive to restart?
    |       -> Fable 5 Low
    |
    +--> Low result fails tests or review?
            -> Escalate effort or model; do not repeat blindly

When a Low-Effort Policy Is Worth Owning

A three-model Low router pays off only if the team can maintain:

• deterministic tests or explicit acceptance rubrics per task class
• an escalation owner who chooses effort up, model up, or human review
• billing visibility by model and effort
• periodic rechecks when benchmarks, harnesses, or pricing change

If those controls are missing, standardize on Opus 4.8 High—or your organization’s approved default—before experimenting with Low. This is especially important because Anthropic recommends Xhigh, not Low, as the Opus starting point for coding.

Implement the Router in Claude Code (API/CLI)

Use full model IDs so third-party provider aliases do not silently select an older model:

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

task_class="${1:?usage: claude-low <routine|normal|ambiguous> [prompt]}"
shift

case "$task_class" in
  routine)
    exec claude --model claude-sonnet-5 --effort low "$@"
    ;;
  normal)
    exec claude --model claude-opus-4-8 --effort low "$@"
    ;;
  ambiguous)
    exec claude --model claude-fable-5 --effort low "$@"
    ;;
  *)
    echo "unknown task class: $task_class" >&2
    exit 2
    ;;
esac

These model selections require Claude Code 2.1.197 or later. Fable 5 requires 2.1.170 or later, Opus 4.8 requires 2.1.154 or later, and Sonnet 5 requires 2.1.197 or later. Provider availability and organization allowlists can still reject or substitute a model.

CursorBench scores reflect Cursor’s harness. If you run tasks in the Cursor IDE, map routine to Sonnet, normal to Opus, and ambiguous to Fable through model selection, keep effort at Low where exposed, and validate separately rather than treating this CLI wrapper as IDE-equivalent.

The wrapper chooses a starting configuration. It does not decide whether the result is acceptable.

Pair it with a bounded escalation rule:

1. Run the selected Low configuration once.
2. Execute deterministic acceptance checks.
3. Review the plan or diff against a fixed rubric.
4. If evidence fails, classify the failure:
   - task was underspecified -> improve the task
   - model under-thought -> raise effort
   - model lacked capability -> route to a stronger model
5. Rerun once, then stop for human review.

Do not hide repeated Low retries behind a lower per-call price. Three cheap failed attempts can cost more than one appropriate configuration.

Evaluate Low Effort on Your Repository

Run the same tasks against all three Low configurations.

Include:

• routine edits as easy baseline tasks
• normal bug fixes with hidden tests
• code-review tasks with seeded defects
• plans with a known dependency graph
• ambiguous repository-scoping tasks

Use the same repository commit, prompt, tools, and acceptance criteria. Start with at least five repeats per condition as a pilot, then choose the final sample size from observed variance and the confidence your decision requires.

Track:

type LowEffortRun = {
  taskId: string;
  category: "routine" | "code" | "review" | "planning" | "ambiguous";
  model: "fable-5" | "opus-4.8" | "sonnet-5";
  accepted: boolean;
  testsPassed?: boolean;
  planRequirementsCovered?: number;
  planRequirementsTotal?: number;
  inputTokens?: number;
  outputTokens?: number;
  totalCostUsd?: number;
  agentSteps?: number;
  wallTimeMs: number;
  humanReviewMinutes: number;
  escalationNeeded: boolean;
};

Calculate:

cost per accepted result =
    total cost across all attempts
    / accepted results

For planning, also measure:

• requirement coverage
• missing dependencies
• invalid assumptions
• implementation rework caused by the plan

A plan that costs $1 less but creates an extra implementation cycle is not cheaper.

Caveats

1. CursorBench uses Cursor’s harness. Claude Code, API agents, and custom tools may change the ranking.
2. The public score is aggregated. There is no planning-only Low score in the current leaderboard.
3. Cost per task depends on token mix and caching. Your prompts, repository, cache hit rate, and provider can change it.
4. Effort labels are model-relative. Low does not guarantee equal thinking-token allocation.
5. Sonnet promotional pricing is temporary. The $2/$10 per-million-token launch price ends August 31, 2026; test using the price your deployment will actually pay.
6. Fable safeguards affect some domains. They cover cybersecurity, biology and chemistry, frontier-model development or distillation, and requests to reproduce internal reasoning. Depending on the surface and configuration, a flagged request may return stop_reason: "refusal" or fall back to Opus 4.8; benign work can also trigger classifiers.
7. Benchmark proximity can be noise. Treat Fable Low versus Opus Max as effectively tied on score, not a definitive 0.2-point loss.
8. Low needs an escalation policy. It is a cost-control setting, not permission to accept weaker evidence.

Final Recommendation

If the question is simply “which Low model should I use?”:

Cheapest:
    Sonnet 5 Low

My best one-model balance after the repo eval passes:
    Opus 4.8 Low

Highest CursorBench score among these three:
    Fable 5 Low

My team policy would be:

1. Use Sonnet Low for narrow work whose correctness is cheap to test.
2. Use Opus Low for normal coding and planning only after a small repository eval confirms that Low passes acceptance checks; otherwise follow Anthropic’s High/Xhigh guidance.
3. Use Fable Low when ambiguity, architecture, or restart cost dominates token price.
4. Escalate based on failed evidence, not model preference.

The key finding is not that Fable wins or Sonnet is cheap.

It is that model choice and effort must be optimized together. On CursorBench, Fable Low reaches roughly the same score as Opus Max and Sonnet Max while costing less per task. That is the kind of inversion a rate-card-only comparison misses.

Related Reading

• Companion: Fable 5 High, Xhigh, Max, and Ultracode comparison
• 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

• Cursor, “CursorBench 3.2”, accessed July 16, 2026.
• Cursor, “How we compare model quality in Cursor”, March 11, 2026.
• Claude Platform Docs, “Effort”, accessed July 16, 2026.
• Claude Platform Docs, “Pricing”, accessed July 16, 2026.
• Claude Platform Docs, “Models overview”, accessed July 16, 2026.
• Claude Platform Docs, “Model IDs and versioning”, accessed July 16, 2026.
• Claude Platform Docs, “Refusals and fallback”, accessed July 16, 2026.
• Claude Platform Docs, “Prompting Claude Fable 5”, accessed July 16, 2026.
• Claude Platform Docs, “Prompting Claude Opus 4.8”, accessed July 16, 2026.
• Claude Platform Docs, “Prompting Claude Sonnet 5”, accessed July 16, 2026.
• Claude Code Docs, “Model configuration”, accessed July 16, 2026.
• Claude Code Docs, “CLI reference”, accessed July 16, 2026.
• Anthropic, “Introducing Claude Opus 4.8”, May 28, 2026.
• Anthropic, “Claude Fable 5 and Claude Mythos 5”, June 9, 2026.
• Anthropic, “Introducing Claude Sonnet 5”, June 30, 2026.
• Cognition, “Making Fable Cheaper Than Opus”, July 13, 2026.