Cheaper tokens can mean a bigger bill
Choose a model that can do the job, tune its thinking effort, and compare the cost of the completed task. A lower token price is only part of the bill.
Watch the reel
A lower price per token does not guarantee a lower bill. One setup may need more thinking, longer answers or more attempts to finish the work.
That is why we separate two decisions: which model can handle the task, and how much thinking effort to give it. Then we compare the completed job.
Start with the job
Describe what a usable answer must do before choosing a model.
Extracting a few fields from a clear invoice is different from working through an ambiguous business decision. The first has explicit rules and values we can check. The second may require more context, judgement and reasoning.
A lighter model can be a sensible starting point for structured work. A more capable model may be needed for difficult work. Neither label tells us whether a particular answer is correct.
For important, demanding work where time and budget are secondary, a top model at high effort can provide a useful baseline to test. That is a starting point, rather than a reason to use maximum effort on every request.
Then adjust the effort
Model capability and thinking effort are separate controls. A lighter model working harder does not become the same model as a stronger one. A stronger model using less effort does not lose all of its capability.
Anthropic describes effort as a control over how many tokens a model spends responding, including thinking, answers and tool calls. More effort can help on harder work, but it can also consume more tokens and take longer. It does not guarantee a better answer to every task.
Two useful starting points:
- Simple and urgent: try a lighter model with low effort, then check the answer.
- Difficult and important: establish a capable baseline, then test whether a cheaper or faster configuration still meets the requirement.
The interesting question comes next: for the same quality target, is a lighter model with more effort better value than a stronger one with less?
Compare the whole bill
A token rate is a unit price. A task bill depends on both the rate and the amount of work the system actually does.
Add the applicable input, cached-input and output charges, plus tool charges and further attempts. Thinking tokens can contribute to the bill too. Avoid counting the same charge twice: the provider's billing rules matter.
For a useful operational comparison, record:
- Acceptance: did the result meet the checks you set in advance?
- Total cost: what did all attempts and tools cost to get that result?
- Elapsed time: how long until you had a usable result, including any review or correction?
For repeated work, cost per accepted result is more useful than the price of one attempt. A fast, cheap answer that needs substantial repair can be poor value. Human review time is a separate cost to consider; it is not included in the benchmark dollars below.
A published example
The reel uses an Artificial Analysis comparison of Sonnet 5.5 at extra-high effort and Opus 5.5 at medium effort, both with default fallback. The snapshot was checked on 25 October 2026; the prices, task costs and index values below were rechecked on 26 October.
| Published metric | Sonnet 5.5 · extra-high | Opus 5.5 · medium |
|---|---|---|
| Intelligence Index | 52 | 51 |
| Input / 1M tokens | $2 | $4 |
| Output / 1M tokens | $10 | $20 |
| Cost per benchmark task | $2.01 | $1.34 |
Opus has the higher unit rates but the lower task cost in this pair. The index scores are close; they do not establish identical answers or equal performance on your task. The benchmark methodology explains the wider measurement context.
The reel also shows estimated completion times from its 25 October snapshot. Those estimates can change as the live page updates; they are not timings from a task we ran. Check the current comparison if latency drives your decision.
Try it on your own task
Choose a small, representative set of examples. Include a difficult case and a case where a wrong answer would be easy to miss. Define the checks before running the comparison.
Try a capable baseline and a lighter alternative at a different effort level. Give them the same relevant information and tools, then judge the answers against the same checks. Record cost, time, retries and any manual fixes. If the results vary, repeat enough examples to see whether the difference is useful rather than a lucky answer.
Keep the setup that meets the quality requirement within your time and cost constraints. Recheck it when the task, model or pricing changes.
Compare the cost of doing the job, not just the price of the tokens.
More practical AI on Instagram, @thinkingcornerlab. For the basics behind the bill, see Where tokens go.
Published benchmark data, not a test performed by The Thinking Corner. Scores describe aggregate benchmark performance, not a universal quality threshold. Examples of work are illustrative. Source snapshot: 25 October 2026; prices, index scores and task costs rechecked 26 October 2026. The reel is an animated explanation with an AI voice.