CL-SN55 941 —
GPT-61S 885 —
GPT-56T 861 —
GPT-6S 825 —
CL-OP55X 818 -0.1%
MUSE-SPK 793 —
QWEN-38X 779 —
GPT-6A 778 —
CL-OP5H 711 -0.1%
CL-OP5X 709 -0.1%
KIMI-K3X 699 -0.1%
CL-OP46H 694 -0.1%
CL-FAB5H 692 -0.1%
CL-OP55H 692 -0.1%
CL-OP47H 683 -0.1%
GEM-37FH 648 -0.2%
GEM-38FH 633 -0.2%
INKL 531 —
CL-OP47 529 -0.2%
GPT-56S 529 -5.9%
GEM-3P 493 —
CL-OP46 488 —
CL-OP48 481 —
GEM-31P 453 -0.2%
GPT-6L 436 —
CL-SN55 941 —
GPT-61S 885 —
GPT-56T 861 —
GPT-6S 825 —
CL-OP55X 818 -0.1%
MUSE-SPK 793 —
QWEN-38X 779 —
GPT-6A 778 —
CL-OP5H 711 -0.1%
CL-OP5X 709 -0.1%
KIMI-K3X 699 -0.1%
CL-OP46H 694 -0.1%
CL-FAB5H 692 -0.1%
CL-OP55H 692 -0.1%
CL-OP47H 683 -0.1%
GEM-37FH 648 -0.2%
GEM-38FH 633 -0.2%
INKL 531 —
CL-OP47 529 -0.2%
GPT-56S 529 -5.9%
GEM-3P 493 —
CL-OP46 488 —
CL-OP48 481 —
GEM-31P 453 -0.2%
GPT-6L 436 —
← Back to feed

The Price Reversal Problem: Listed API Rate Is the Wrong Number for Reasoning Models

Reasoning models charge for thinking tokens. The problem, documented in a 2026 study by Chen et al. titled “The Price Reversal Phenomenon,” is that listed prices capture none of that variance — and the difference is large enough to invert the cost ranking between models in nearly a third of real-world comparisons.

The Core Finding

In 32% of model-pair comparisons, the model with the lower listed price per token ends up costing more once a task is complete. The reversal reaches 28x at the extreme. The mechanism is thinking token consumption: on the same query, one reasoning model can consume 900% more thinking tokens than another. Repeated runs of a single query on the same model vary by as much as 9.7x in thinking token usage.

Listed prices reflect none of that variation. A per-million-token rate assumes a fixed token budget per query. Reasoning models do not have fixed token budgets.

A Worked Example

The OpenRouter analysis uses Claude Sonnet 5 and GPT-5.4 mini as a reference case, with prices as of July 27, 2026.

GPT-5.4 mini is listed at $0.75 per million input tokens and $4.50 per million output — roughly 2.4x cheaper than Sonnet 5 at $2.00/$10.00 on a token basis.

For a task requiring 2,000 input and 800 output tokens: if Sonnet 5 succeeds on the first attempt 95% of the time, it costs approximately $12.63 per thousand completed tasks. For the mini to match that cost-per-completed-task, it needs to succeed on the first attempt at least 40% of the time. Below 40%, the cheaper-listed model costs more per delivered result.

The same calculation, plotted across all success rates, shows the crossover point varies substantially by task complexity. For hard tasks with low success rates, the listed price advantage of cheaper models collapses.

Why This Matters for Frontier Model Selection

The practical implication is that model selection based on listed price is unreliable for agentic and reasoning workloads. The relevant metric is cost per completed task, which requires knowing the success rate and the token consumption distribution for that specific task. Neither is available from a rate card.

The study finds the reversal is not an edge case. At 32%, it is common enough that defaulting to the lower listed-price model produces the higher actual bill in more than one in four comparisons. At the 28x extreme, the difference is not a rounding error — it changes the economics of a deployment.

The drivers are:

  • Thinking token variance between models: Two models with similar listed prices but different reasoning architectures spend tokens at dramatically different rates on the same query.
  • Run-to-run variance within a model: The same model on the same query varies 9.7x in thinking token usage across runs, meaning average-case estimates from a handful of test runs can mislead.
  • Success-rate coupling: A model that fails more often requires retries, multiplying token consumption on the path to a completed result.

What Accurate Cost Evaluation Requires

Accurate cost comparison for reasoning models needs three inputs that listed prices do not provide:

  1. Task-specific success rate for each candidate model
  2. Token consumption distribution (not an average — the variance matters)
  3. Cost per completed task, not cost per token

OpenRouter’s live data surfaces per-task cost alongside benchmark scores, and its MCP server allows querying this data directly from an editor. The same pattern applies to any evaluation: shortlist on benchmarks, validate on actual prompts, measure cost on completed tasks.

The listed rate is the starting bid, not the final bill.