← All posts

Jul 10, 2026·7 min read

Why the Most Expensive Models Will Cost You Less

Benchmark data from Anthropic and Artificial Analysis shows that frontier models at reduced effort settings repeatedly beat cheaper models at maximum effort on both quality and cost per task. Per-token pricing is the wrong selection criterion.


The Problem

Model selection is still mostly driven by per-token pricing. Claude Fable 5 launched at $10 per million input tokens and $50 per million output, exactly double the $5/$25 of Claude Opus 4.8. The obvious conclusion is that the expensive model is a specialty tool you save for hard problems, and the cheaper model is the default.

Benchmark data from multiple sources contradicts this. When you measure cost per task instead of cost per token, the more expensive model at a reduced effort setting repeatedly beats the cheaper model at any effort setting, with higher scores at lower total cost. Per-token price and per-task cost often rank models in opposite order.

The Metric That Matters

The unit that matters is not the token but the completed task. Cost per task decomposes into two factors:

cost per task = price per token × tokens consumed per task

Reasoning models made the second factor dominant, and effort controls made it configurable. Every current frontier model exposes a parameter that governs how much the model deliberates, and with it how many tokens it consumes: effort on the Claude API, reasoning_effort on OpenAI's, thinking levels on Gemini.

This means a model no longer has a single cost. It has a curve of score against cost per task, one point per effort level. Comparing models is comparing curves, and the curves of expensive and cheap models overlap. The question is whose curve sits higher in the overlapping region.

Evidence

Case 1: Claude Fable 5 vs Claude Opus 4.8

The Fable 5 announcement includes results on Cognition's FrontierCode benchmark (diamond subset: the hardest 50 of 150 tasks), plotted as score against mean cost per task across effort levels:

FrontierCode accuracy vs cost per task: Claude Fable 5, Claude Opus 4.8, and GPT-5.5 across effort levels

Opus 4.8's best configuration is xhigh effort: roughly $8 per task at a score of 13.4%. Fable 5 at medium effort scores 17.8% at roughly $7 per task. The model that costs twice as much per token exceeds the cheaper model's best configuration by 4.4 points while costing about a dollar less per task. At the low end, Fable at low effort matches Opus at max effort for approximately half the cost.

The chart shows two other things:

  1. Effort-induced regression. Opus 4.8 at max effort ($10.50 per task, 11.4%) scores two points below its own xhigh setting at higher cost. Past a model's capability ceiling, additional reasoning budget buys second-guessing rather than accuracy. This is consistent with the overthinking phenomenon documented in the efficient-reasoning literature.
  2. Flat scaling. GPT-5.5's curve is nearly flat from about $1.80 to $6.25 per task. Effort scaling only converts spend into accuracy when the model has capability headroom to begin with.

Case 2: GPT-5.6 Sol vs Terra

Artificial Analysis measured the same relationship across OpenAI's GPT-5.6 family: Sol ($5/$30 per million tokens), Terra ($2.5/$15), and Luna ($1/$6):

Artificial Analysis Intelligence Index vs cost per task for GPT-5.6 Sol, Terra, and Luna across reasoning efforts

Terra at max effort scores 55 on the Intelligence Index at $0.55 per task, figures the article states directly. Reading Sol's high-effort point off the chart gives approximately 56 at roughly $0.45 per task. The model with double the per-token price is again both smarter and cheaper. The same thing happens further down the curves, where Sol at low effort edges out Terra at high effort at lower cost per task.

Artificial Analysis states the general result directly: for any Terra effort level, there is a Luna or Sol effort level that is more intelligent at no extra cost, or equally intelligent at lower cost. The mid-tier model is strictly dominated. The large model dialed down and the small model dialed up cover its entire operating range. On the pricing page Terra looks like the sensible middle option; on the cost-per-task chart it has no niche.

Case 3: Claude Opus 4.5 vs Claude Sonnet 4.5

The pattern is not new. It was already measurable in November 2025, when Anthropic shipped the first version of the effort parameter with Opus 4.5. The chart plots SWE-bench Verified accuracy against output tokens:

SWE-bench Verified accuracy vs output tokens: Opus 4.5 at low, medium, and high effort vs Sonnet 4.5

Opus 4.5 at medium effort matched Sonnet 4.5's best score while using 76% fewer output tokens. In dollars: Sonnet 4.5 consumed roughly 22,500 output tokens at $15 per million (≈$0.34 of output per task), while Opus at medium used roughly 5,400 tokens at $25 per million (≈$0.14). The model with the higher per-token price cost less than half as much in output per solved task. Even Opus at high effort, which exceeds Sonnet by 4.3 points, used 48% fewer tokens and remained cheaper on output. At no point on the curve did the cheaper model spend less on output, though Opus at low effort does give up about a point of accuracy against Sonnet's best.

Summary of Cases

CaseBenchmarkCheaper model, best configExpensive model, reduced effortResult
Fable 5 vs Opus 4.8FrontierCode (diamond)Opus xhigh: 13.4% @ ~$8.00Fable medium: 17.8% @ ~$7.00+4.4 pts, ~12% cheaper
GPT-5.6 Sol vs TerraAA Intelligence IndexTerra max: 55 @ ~$0.55Sol high: ~56 @ ~$0.45+1 pt, ~18% cheaper
Opus 4.5 vs Sonnet 4.5SWE-bench VerifiedSonnet (best): 76.5% @ ~$0.34 outputOpus medium: ~77% @ ~$0.14 outputMatched score, ~60% cheaper

The same inversion shows up across vendors and benchmarks.

The Mechanism

Why does the more capable model consume fewer tokens? A few factors compound:

Weaker models take longer paths. A model operating at the edge of its capability backtracks, re-derives established intermediate results, and pads its reasoning with verification it cannot trust. All of it is billed output. A more capable model reaches the same conclusion through a shorter chain.

Agentic workloads amplify the gap. In an agent loop, an extra reasoning step is not just extra output. It is another full pass over the context: files re-read, tests re-run, patches retried. A model that completes a task in 8 steps instead of 20 saves input tokens, output tokens, and latency on every step it skipped.

Failed attempts are the most expensive tokens. When the cheaper model does not complete the task, the cost is the failed attempt plus the retry plus the eventual escalation to the larger model. A failed $0.30 run costs more than a successful $0.45 one.

Effort decouples capability from spend. Per-token price buys capability headroom, and the effort parameter decides how much of it each task actually draws. Before effort controls, picking the frontier model meant paying for its full appetite for deliberation on every request. Now capability and spend are tunable independently.

Boundary Conditions

The inversion does not hold universally, and the exceptions follow from the same cost-per-task logic:

  • Tasks a small model completes reliably in one attempt, like classification, extraction, and structured transforms at volume, will not be beaten per task by any frontier configuration. Earlier experiments on this blog found a mini model at high reasoning outperforming a frontier model at high reasoning on structured ETL tasks. That result and this one are the same principle applied to different task structures.
  • Latency-sensitive paths optimize for time-to-first-token, a dimension cost-per-task charts do not capture.
  • Models without capability headroom (GPT-5.5's flat curve) convert additional spend into nothing. Effort scaling is only worth buying on models that respond to it.

None of these are exceptions to the metric. They are the metric picking different winners for different task structures.

Selection Procedure

The data supports a simple procedure, and it is not "pick a model":

  1. Fix the quality bar first. Define the score your workload requires.
  2. Find the cheapest (model, effort) pair that clears it. On current curves this is frequently the frontier model at low or medium effort, not the mid-tier model at max.
  3. Treat maximum effort as a verified special case. The Opus 4.8 max-effort regression shows it can cost more and score less, and Anthropic's own effort documentation carries the same warning: on structured or less intelligence-sensitive tasks, max effort "can lead to overthinking". Enable it only where measurement shows the additional depth pays.
  4. Measure your own distribution. Published curves are someone else's workload. Logging output tokens per completed task and multiplying by prices produces the real curve for yours.

References

  1. Introducing Claude Fable 5 and Claude Mythos 5 (Anthropic, 2026). FrontierCode accuracy vs cost-per-task data across effort levels.
  2. GPT-5.6 benchmarks across Intelligence, Speed and Cost (Artificial Analysis, 2026). Intelligence Index vs cost-per-task curves for Sol, Terra, and Luna; Pareto dominance analysis.
  3. Introducing Claude Opus 4.5 (Anthropic, November 2025). Effort parameter; SWE-bench Verified accuracy vs output-token measurements.
  4. Effort (Claude Platform Docs). API reference for effort controls.
  5. Stop Overthinking: A Survey on Efficient Reasoning for Large Language Models (TMLR, 2025). Documents accuracy regression under excess reasoning budget.

Summary

Per-token pricing was a usable heuristic when every model spent a comparable number of tokens per answer. Effort controls ended that. In the Opus 4.5 case above, the model priced 67% higher per output token consumed 4× fewer output tokens per task, and the effort parameter moves that number on demand.

Across Anthropic's and OpenAI's current lineups, the measured result is consistent. The expensive model at reduced effort is smarter and cheaper per task than the cheap model at maximum effort, and mid-tier models risk being strictly dominated from both sides. The correct comparison is not price per token between models but cost per completed task between (model, effort) configurations. By that measure, the most expensive model on the pricing page is often the cheapest one on the invoice.