TokenPad

Comparison

Reasoning models vs standard models

Reasoning models bill their internal thinking as output you never see. When that buys you something, and when it is a slower, dearer way to get the same answer.

The short answer

Use a reasoning model for genuinely hard problems and a standard model for everything else. Reasoning models generate internal thinking before answering, billed as output tokens you never see — at high effort that hidden portion can be several times the visible answer. On classification, extraction and formatting they are simply a slower and more expensive route to the same result.

At a glance

Reasoning model compared with Standard model
 Reasoning modelStandard model
Hidden thinking tokensYes — billed as outputNo
Real output costSeveral times the visible answerWhat you see
LatencyHigh — thinking before first tokenLower
Hard multi-step problemsSubstantially betterWeaker
Simple structured tasksNo advantageFine
Context consumptionThinking occupies the window tooOnly the answer

When to choose which

Choose Reasoning model when

  • The problem has several dependent stepsWhere a wrong intermediate conclusion invalidates the answer, and working through it visibly improves the result.
  • Correctness matters more than latency or costAnalysis, complex debugging, anything where a wrong answer is expensive and a slow one is merely inconvenient.
  • Standard models fail on your evaluation setThe honest test. If a standard model already passes, thinking is buying nothing.

Choose Standard model when

  • Classification and extractionA small answer space and a clear prompt. Reasoning adds cost and latency without improving accuracy.
  • Formatting and rewritingTransformations where the answer is mechanical. There is nothing to reason about.
  • Anything latency-sensitiveThinking happens before the first token, so time to first token is materially worse. On a user-facing path that is felt immediately.

What it costs either way

The hidden tokens are the whole story. At medium effort the thinking is commonly around three times the visible answer, and at high effort it can be eight — all billed at the output rate, which is already four to six times the input rate.

That makes a budget built on visible answer length wrong in the same direction every time, often by a factor of several.

Thinking also consumes context window. On a long conversation, it takes space you assumed was available for history or retrieved content.

Where the provider exposes an effort setting, it is the single largest cost lever on these models — and many tasks do not need the highest one.

The mistake people make

Using a reasoning model as the default

It is easy to reach for the most capable option and assume the extra cost is proportional to the extra capability. It is not: on tasks that need no reasoning you pay several times the output rate for thinking that changes nothing, plus the latency. Where a provider reports reasoning tokens in the usage field, measure yours — the number is usually larger than people expect and it is the fastest way to end this argument internally.

How to decide

  1. 1Run your evaluation set against a standard model first. If it passes, you are done.
  2. 2If it fails, check whether chain-of-thought prompting on the standard model closes the gap — sometimes it does, at a fraction of the cost.
  3. 3If you do need a reasoning model, test the lowest effort setting before the highest.
  4. 4Measure the actual reasoning tokens from the usage field rather than estimating, and budget on that.

Price it yourself

Frequently asked questions

Can I see the reasoning tokens?
Generally not the content — providers return a summary at most. But the count usually appears in the usage field of the response, which is what you should budget on rather than a multiplier.
Does chain-of-thought prompting do the same thing?
It is the same idea applied externally: asking a standard model to work through the steps. It is cheaper and often enough. The difference is that reasoning models were trained for it and do it better on genuinely hard problems.