AI Reasoning Effort Tiers: A Cost Breakdown and How to Calculate Value for Money

1. Prices Fell 20%, Yet the Actual Cost Doubled

Recently a leading LLM vendor released a new-generation flagship reasoning model. After a third-party evaluation lab published its benchmark scores, the most attention-grabbing table in the discussion was this one: the official API’s input/output price (per million tokens) was cut by about 20%, yet on the same evaluation set, the average cost per question at the highest reasoning tier rose from about $12.99 (the top tier of the previous-generation flagship) to about $26.54. So some people concluded outright: the price cut is fake, and ordinary users can afford it even less now.

This conclusion is only half right—and the wrong half is exactly the most important part.

First, let’s do the math. The cost of a reasoning model breaks down into three parts:

cost per call ≈ (input tokens × input price + output tokens × output price) / 1,000,000
where output tokens = visible answer tokens + reasoning (thinking) tokens

The key point: reasoning tokens are billed at the output-side price, just like the visible answer. And a price discount only softens the slope of each segment—it doesn’t change the volume. What changed is “how many tokens it takes to finish one question.” Public data shows that on the same evaluation set, the output volume per question at the highest tier rose from about 118K to about 274K, and the vast majority of the increase is reasoning tokens. A 0.8 price multiplier times roughly a 2.3x usage increase naturally doubles the total.

So between the “price cut” in the marketing and the actual bill sits one variable: token usage. To judge whether a pricing change is a win or a loss for you, you have to look at two things at once: how much the unit price dropped, and how much the new version’s usage structure changed. The higher the reasoning tier, the larger the thinking budget, and the growth in usage is often non-linear—which is also why the top tier’s price curve looks the steepest.

2. Reasoning Tiers Aren’t “Just a Bit More Computation”—They’re a Completely Different Cost Curve

The same evaluation lab ran every tier. The data looks roughly like this (cost is the weighted average per question in this benchmark index; it will change if you swap in your own task set):

Tier	Index score	Cost per question	Cost per point
Max	65	$26.54	≈ $0.41
Xhigh	62	$14.83	≈ $0.24
High	62	$9.08	≈ $0.15
Medium	56	$3.80	≈ $0.068
Low	54	$3.10	≈ $0.057
Previous-gen top tier (reference)	59	≈ $10	≈ $0.17

Three structural facts stand out.

First, marginal returns are already clearly diminishing around High. From Low to High, each added tier gains 2–3 points while cost rises 1.5–2x—still a reasonable trade; but from High to Max, cost nearly triples (about 2.9x) for just 3 points. That’s a textbook diminishing-returns inflection point.

Second, Xhigh is a “premium tier.” Its score is identical to High’s (both 62), yet it costs about 63% more. Unless you’ve specifically benchmarked this tier, there’s almost no rational basis for choosing it—the extra money maps to no measurable capability gain.

Third, and most interesting: the new generation’s middle tier already has a lower cost-per-capability than the previous generation’s top tier. The Medium tier scores 56 at $3.80; the same tier in the previous generation scored 43 at $5.56. Within the same tier, the score rose 13 points while the price fell about 32%—that’s the real upgrade of this generation. If you measure by “how much does each point of capability cost,” Medium is $0.068/point versus $0.17/point for the previous-gen top tier—the former is only about 40% of the latter.

By the way, most mainstream AI coding tools and general chat products default to the middle tier. That’s not vendor laziness; it’s the optimum this table computes: the middle tier covers the vast majority of everyday tasks at a fraction of the top tier’s cost. As for the “can’t afford it” verdict, looking at middle-tier data, the conclusion is exactly the opposite.

3. When Checking a Leaderboard, Verify Three Things: Tier, Metric Definition, and Data Source

The benchmark table a vendor publishes at launch is easy to trip over in cross-comparison. Check at least three things.

Tier alignment. In the same table, the vendor’s new flagship uses the highest reasoning tier on code benchmarks, while the competitor’s column is labeled “medium effort.” A comparison across mismatched tiers proves nothing about a capability generation gap—it only shows “a high-budget config beats a medium-budget config,” which is common sense. The minimum requirement for a fair comparison is: same effort tier, same whether thinking is enabled, same context and output budgets.

Metric coverage. In the same round of evaluations, it scored 51.4% on automation/computer-use tasks, trailing the reference product’s 53.9%. This shows it isn’t an across-the-board leader but has wins and losses: strong at code generation, weak at computer-use automation, with a large jump in robotics control. A single high score doesn’t imply “across-the-board superiority.”

Independently verifiable data. One robotics-control metric jumped from 27.6% to 64.9%, more than doubling, while the footnote states it’s an internal self-test. Internal self-tests aren’t unusable, but when they lack a public methodology, evaluation scripts, and environment description, their reference value is very limited—they’re better treated as “a direction the vendor thinks worth watching” than as “a number you can write into a technical-selection rationale.”

As for the vendor’s own cost accounting (the official line claims a certain model’s high-end tier roughly ties the previous-gen top tier on code benchmarks at about half the per-task cost), I generally take it with a grain of salt too. This time the third-party data points the same direction, which suggests the “middle tier offers better value” judgment is probably credible—but the exact multiple depends on your task mix.

4. Don’t Mistake “Extreme Capability Demos” for “Everyday Capability”

The two most viral cases in the launch material: an operating system that boots on a laptop written in 8 days, and a formal proof of a mathematical theorem completed in 30 hours.

What these two have in common: thousands of agents running in parallel continuously for tens of hours. They measure “exploratory capability given an enormous parallel budget and a very long time,” proving the model’s upper bound of potential on long-chain, self-correcting tasks. It doesn’t directly imply “opening a session in your editor to fix a bug will also be 100x faster.”

The more practically useful engineering judgment: the real payoff of a single session depends on the product of task length, context length, number of tool calls, and number of retries; and the cost of agent-cluster mode is a completely different order of magnitude from all of that. To assess model capability, look at the budget under which you’ll use it, not at its limit performance under no budget constraint.

5. Safety-Related Capability Limits Matter More Than Benchmarks for Some People

This release also has one limit that, for security-focused teams, ranks above any benchmark: requests like penetration testing, exploit development, and binary vulnerability analysis are blocked by a content-safety classifier and routed to the previous-generation model instead.

The practical impact of this constraint is three-layered.

First, capability gap: for the security-analysis scenarios you pay for as “flagship capability,” the actual executor is the previous-generation model, whose capability and cost profile must be re-evaluated on the previous generation’s terms—you can’t carry over the new model’s data.

Second, architectural dependency: if your security-scanning or vulnerability-audit pipeline depends on this API, its behavior can change silently from one model upgrade—latency, cost, and capability all shift at once, with no error thrown. This kind of dependency must be modeled explicitly in the architecture, not treated as a transparent drop-in replacement.

Third, compliance expectation management: a model-side content policy is part of the product, and the business side needs to design in a degradation path and a human fallback for such tasks, rather than assuming “the API can definitely do it.”

6. Turn Value-for-Money into Measurable Engineering Practice

The analysis above ultimately comes down to one question: which tier should my business use, and when should I move up a tier? You can’t decide this from leaderboards; you need your own data.

1. Build a small self-hosted evaluation set

Sample 30–100 tasks from real business, covering your actual work distribution—refactoring, bug fixing, writing tests, writing docs, code review, each represented. Each entry contains a task description and a reference implementation or acceptance criteria (whether it runs, whether tests pass). The only requirement for this set is “stable reuse”: run it after every model or prompt change to see how scores and costs move.

2. The core metric is “cost per successful task”

Don’t make decisions on per-token unit price; use this number:

cost per successful task = total spend / number of successful tasks

It reflects real spend better than unit price. For example: one model has a high single-attempt success rate but a high unit price; another is cheaper per token but needs 2–3 attempts to succeed—the latter is often more expensive, because retry cost, human-review cost, and the waiting cost from latency all have to be counted.

# Example: convert one evaluation run into cost per successful task
def cost_per_success(records, price_in, price_out):
    total = sum(r.tokens_in * price_in + r.tokens_out * price_out
                for r in records) / 1_000_000
    passed = sum(1 for r in records if r.passed)
    return total / passed if passed else float("inf")

3. Route tiers by task complexity

Always using the top tier is wasteful; always using a low tier will fail on critical tasks. A more reasonable approach is to layer:

ROUTES = [
    (0.30, "low",    "single-line edits, formatting, comment completion"),
    (0.60, "medium", "routine feature implementation, adding unit tests"),
    (0.85, "high",   "cross-module refactoring, hard bug localization"),
    (1.01, "max",    "architecture design, strict one-shot correctness"),
]
def pick_effort(task):
    score = estimate_complexity(task)   # file count, changed lines, dependency depth, historical retries
    for threshold, effort, desc in ROUTES:
        if score <= threshold:
            return effort, desc
    return "max", "complex task"

The best basis for judging complexity is task features rather than model self-assessment: number of files involved, estimated lines of change, dependency depth, and the module’s historical failure rate. These metrics all exist in your own repo and are more accurate than any generic rule.

4. Compress token consumption from both sides

• Context governance: send only the necessary files, cap the number of history turns, and avoid dumping the entire codebase into the prompt. The input side is usually the biggest source of waste.
• Structured output: ask the model to return only a patch or JSON, and don’t let it write long explanations and then paste code.
• Prefix caching: put stable system prompts, repo conventions, and code standards at the very front to maximize cache-hit rate and directly lower input cost.
• Output length limits: specify “diff only” or “conclusion only” to cut uninformative tokens.
• Batching: route offline, non-real-time tasks through an asynchronous batch channel, which usually carries a price discount.

5. Observability and cost attribution

Log every call: tier, input/output/reasoning token counts, cache-hit status, latency, task ID, and whether it succeeded.

{
  "task_id": "req-8f21",
  "effort": "medium",
  "tokens_in": 18240,
  "tokens_out": 3120,
  "cache_hit_ratio": 0.62,
  "latency_ms": 8400,
  "cost_usd": 0.0031,
  "passed": true
}

Feed these logs into a logging service, and with monitoring and alerting set a threshold-based alert for per-task cost overrun—only then can you answer “what exactly did this inference spend buy?” On general cloud infrastructure like Baidu AI Cloud, general-purpose capabilities such as object storage, message queues, container platforms, logging services, and monitoring/alerting are enough to support a complete evaluate–route–cost-attribution pipeline, without depending on any model vendor’s proprietary tooling.

7. Checklist

• A reasoning model’s “unit price” and its “bill” are two different things, with usage structure in between. A price cut doesn’t mean it got cheaper.
• Choose tiers by marginal return: High is usually the sweet spot, Medium has the best cost-per-capability, and Xhigh lacks a reason to pick without dedicated evaluation support.
• When checking a leaderboard, verify tier alignment, metric definitions, and data source; internal self-test data is only a directional reference.
• Extreme demos reflect the capability ceiling under no budget constraint, not the payoff on everyday tasks.
• Safety-related tasks may be routed to the previous-generation model, so that capability budget must be evaluated separately.
• The real basis for cost decisions is your own evaluation set and “cost per successful task,” not any public leaderboard.

Last point: model pricing structures and capabilities are iterating fast, so this evaluation workflow itself is an asset. Build it once, and after that just run a regression pass after each upgrade—your selection judgment won’t be led astray by any single release.