Reasoning Models Explained: Thinking Tokens and When They Pay

A normal AI model starts writing its answer straight away, one token after another, without working through the steps first. On a multi-step problem it can skip a step and never notice.

Picture a common setup. A maths tutoring app answers doubts from students preparing for engineering entrance exams. A doubt is what many Indian students call a question they are stuck on. The setup is made up, but the problem is real.

One evening, a student sends this doubt: "A bag has 4 red and 6 blue balls. Two are drawn without replacement. What is the chance both are the same colour?"

The app replies 13/25 in two seconds, with a confident explanation. A maths teacher who checks the app's answers works it out by hand.

Both red is 4/10 times 3/9, which is 12/90. Both blue is 6/10 times 5/9, which is 30/90. Together that is 42/90, or 7/15.

Now put the first ball back before the second draw. Then it is 4/10 times 4/10 plus 6/10 times 6/10, which is 0.52, or 13/25. The app missed two words: without replacement.

The teacher then checks 100 hard doubts from last week, and the app got 61 right. On 200 easy doubts, like asking for a formula, it got 194 right. The app answers about 20,000 doubts a day, so mistakes on hard doubts add up fast.

The team has heard that reasoning models do better on doubts like this. This guide follows their decision, from what these models are to whether they pay.

You need five words. Each one comes with a plain meaning and an example from the tutoring app.

Token. A token is a small piece of text, roughly a word or part of a word. Models read and write text as tokens, and model services charge by them. Example: the ball doubt above is 28 tokens on two widely used tokenizers, the programs that split text into tokens.

Output tokens. Output tokens are the tokens the model writes, as opposed to the input tokens you send it. On the price lists of two large model services, output tokens on the main models cost five times as much as input tokens, as of 19 October 2026.

Thinking tokens. Thinking tokens are the tokens a reasoning model writes while working through the problem, before its final answer. Example: the rough work for the ball doubt might run to a few thousand thinking tokens.

Thinking budget. A thinking budget is the most thinking tokens you allow for one request, such as 4,000 for a probability doubt. Some services take a number, and others take an effort level such as low, medium or high. As of 19 October 2026, the newest models on the three large services we checked take an effort level.

Latency. Latency is how long the student waits for the answer. The model writes thinking tokens one after another before the answer starts, so more thinking means a longer wait.

Reasoning models are AI models that spend extra tokens working through a problem before they answer, while a normal model starts writing the answer straight away. The final answer may be the same length, but a lot of work came before it.

Think of two students in a coaching class. One calls out the first answer that comes to mind. The other works it out in the margin, step by step, checks it once, and then answers.

The second student is slower, but far more often right on hard problems. On 7 times 8, both are right, and the margin work was wasted. Writing out steps like this before the answer is called chain of thought.

Where the picture breaks: a student's margin work is how they really got the answer. A model's written steps may not be, as the warning below explains.

The idea is older than reasoning models. A 2022 research paper put a few worked examples with written-out steps into the prompt, the text sent to the model. Large models then got much better at maths word problems. The paper reports that this ability emerges in sufficiently large models, so do not expect it from small ones.

Reasoning models are trained so that this margin work is their normal habit, not something you must ask for in the prompt. The diagram follows one doubt through both modes.

In reasoning mode, the thinking for the ball doubt might list the cases, work out both red, then both blue, and add them. Papers on these models report that they learn to re-check their own working, which is how a slip like 13/25 can get caught.

Published recipes start from a pretrained language model and add reinforcement learning on problems a program can check. Many also add a stage of learning from worked solutions. Exact recipes differ between builders and are often not public.

Pretraining. The model reads a huge amount of text and learns to predict the next token. This gives it language and general knowledge, but no special habit of careful working.

Fine-tuning on worked solutions. Builders show the model many problems solved step by step, like a solved exercise book. This is called supervised fine-tuning: the model learns to copy the style of good working.

Reinforcement learning. The model tries many practice problems, and a program checks each final answer, like a student checking past papers against the answer key. Attempts that reach a right answer are rewarded, so the habits behind them become more likely.

One detailed 2025 paper shows what those checks look like. Maths answers had to be given in a set format so a simple rule could compare them. Code was run against prepared test cases.

The authors avoided a trained scoring model as the judge. They warn that the model being trained may learn to fool such a judge, which is called reward hacking.

The same paper trained one version with reinforcement learning alone, straight after pretraining. It learned on its own to think longer, from hundreds to thousands of tokens, and to re-check its approach. Its working was hard to read and mixed languages, so the main model first learned from thousands of long worked solutions.

In the reinforcement learning stage, nobody writes the thinking rules by hand. Splitting a problem into parts, trying a second method and checking before answering all grow because they lead to rewarded answers. The diagram shows the practice loop.

Researchers have also tried rewarding each step, not just the final answer. This is called a process reward: a checker scores every step, so a lucky guess built on broken steps earns less.

A 2023 paper compared two checkers on hard maths problems: one judged only final answers, the other judged every step. Each picked the best of 1,860 attempts per problem. The step checker's pick was right on 78.2% of 500 test problems, against 72.4% for the final-answer checker. The paper used these checkers to pick answers, not to train the model.

Step labels are costly, though. For that paper, people marked about 800,000 single steps as good, bad or neutral by hand.

That is one reason the published recipes centre on checkable work like maths and code. For tasks with no single right answer, such as writing a friendly message, a simple rule cannot hand out the reward. Test before you assume a gain there.

Use a reasoning model when the task needs several steps that depend on each other and you can tell whether the answer is right. Skip it when the job is a lookup, a format change or a short rewrite.

Go back to the two students in the coaching class. Margin work pays off when a slip in step two ruins step five. It is wasted when the answer is a single fact that you either know or do not.

Signs that reasoning mode will help:

• Multi-step maths, like the bag of balls or a mechanics problem with three forces.
• Planning, like building a 30-day revision timetable around mock test dates and weak chapters.
• Tricky code, like finding why a ranking function gives the wrong rank to students with tied scores.
• Questions with hidden traps, where one phrase such as without replacement changes the whole method.

Signs that it will not help much:

• Simple lookups, like the formula for the area of a circle.
• Formatting, like turning an answer into numbered steps or a table.
• Short rewrites, like making an explanation friendlier or translating it into Hindi.
• Anything where speed matters more than depth, like suggesting a chapter name while a student types.

Thinking also does not supply missing facts. If a doubt needs this year's exam pattern and the model was never given it, more thinking just builds a longer argument on a wrong base. Put the facts in the prompt instead.

A thinking budget is a limit on how many thinking tokens the model may use for one request. Enough thinking is the smallest budget that gets your hard questions right; past that point, extra tokens mostly add cost and wait.

Research on test-time compute points the same way. Test-time compute is the computing a model does while answering, rather than during training. A 2024 study found that the best way to spend it depends on how hard each question is, so it should be handed out per question.

In the same study, extra answer-time compute beat a model about 14 times larger, with total compute matched. That held on questions the smaller model could already solve some of the time. Spending more compute at answer time can stand in for being bigger, but only on questions within reach.

A 2025 paper showed a simple way to control the budget, called budget forcing. To stop early, you end the thinking and make the model answer. To make it think longer, you append the word Wait when it tries to stop, and the authors report this often makes it fix wrong steps.

Too much thinking has a name: overthinking. A 2025 survey describes reasoning models writing long, repeated working that adds cost. In worse cases, it says, the extra steps introduce errors and lead to wrong answers.

So the team tries four budgets on the teacher's 100 hard doubts. No thinking gets 61 right, 1,000 tokens gets 78, 4,000 gets 87, and 8,000 gets 88 (made-up results). Doubling the budget from 4,000 bought one more right answer, so the team picks 4,000. If your service takes effort levels instead, run the same test across its levels.

The output-limit trap

On the three large model services we checked, as of 19 October 2026, thinking tokens count toward the same maximum output limit as the answer. That limit is the most tokens one reply may contain. One service lets the thinking budget be larger than that limit when thinking is spread across tool calls, because the budget covers the whole turn. A tool call is where the model pauses to ask your code for data. The output limit still caps each reply. If that limit is too low, the model can spend it all on thinking.

One service's docs say the cut-off can come before any visible answer is written. The student then gets nothing, and you still pay for the thinking.

Two checks catch it. Set the limit above the thinking budget plus the longest answer you expect. Then log how each reply ended. Two of the services mark a reply cut off at the limit as incomplete, so alert when that count rises.

One service still accepts a token budget on older models. It calls that budget a target, not a strict cap, and says the maximum output limit stays the hard ceiling. So in your code, set both.

On the services we checked, thinking tokens are billed at the output token price, so a request with 4,000 thinking tokens can cost several times more. They also add wait time, because the model writes them before the answer starts.

Here is the team's maths, with made-up prices. Input costs Rs 0.10 (rupees) per 1,000 tokens and output costs Rs 0.40 per 1,000 tokens. On the two real price lists we checked, main-model output costs five times input; four times keeps these sums simple. A typical request sends 500 input tokens, the app's instructions plus the doubt, and gets a 500-token answer.

Say the model writes about 100 tokens per second (made up). The short Python function below does the sums, so you can run it yourself.

PRICE_IN = 0.10    # rupees per 1,000 input tokens
PRICE_OUT = 0.40   # rupees per 1,000 output tokens
SPEED = 100        # output tokens written per second

def cost_and_wait(input_tokens, thinking_tokens, answer_tokens):
    output_tokens = thinking_tokens + answer_tokens   # thinking is billed as output
    cost = input_tokens / 1000 * PRICE_IN + output_tokens / 1000 * PRICE_OUT
    wait = output_tokens / SPEED                      # seconds, ignoring the network
    return round(cost, 2), round(wait, 1)

print(cost_and_wait(500, 0, 500))      # normal mode: (0.25, 5.0)
print(cost_and_wait(500, 4000, 500))   # reasoning mode: (1.85, 45.0)

Run it with Python 3 and you should see (0.25, 5.0) and then (1.85, 45.0): rupees per doubt, then seconds. The first line inside the function is the one that matters. Thinking tokens are added to answer tokens, because both are billed as output.

The wait ignores network time and the time to read the prompt. Almost all of the extra 40 seconds pass before the first word of the answer appears.

On hard doubts, reasoning mode fixes 26 more answers out of 100. On easy doubts, it fixes one more out of 200 at over 7 times the cost. That gap is the whole case for sending only some doubts to reasoning mode.

The cost of each extra right answer

Price per request hides the real trade. The number that settles it is what each extra right answer costs.

Moving 100 hard doubts from normal to reasoning mode costs Rs 160 more, which is 100 times Rs 1.60. It fixes 26 answers, so each extra right answer costs about Rs 6.15.

At the full 8,000 budget, a doubt costs Rs 3.45, which is Rs 1.60 more than at 4,000. Over 100 hard doubts that is another Rs 160, for one more right answer. That answer costs about 26 times as much as each of the first 26.

You route by adding a cheap first step that labels each request, then sending only the hard ones to reasoning mode. Everything else goes to normal mode, so most requests stay fast and cheap.

A router is a step that looks at each request and picks a path for it. In the tutoring app, a small, cheap model gives each doubt one label: lookup, format or multi_step. The only choice here is whether to think.

The team adds one more path. Every answer has a Still confused button under it. Tapping it sends the doubt again with reasoning mode on, so a wrong quick answer gets a second, more careful try.

A label the router does not recognise also goes to reasoning mode. When unsure, the team would rather pay a little more than show a wrong answer.

Here is the router in Python. Two helpers stand in for real calls to your model service, so the code runs as it is. The helper ask_model takes thinking_budget, the most thinking tokens it may use, and 0 means normal mode.

CHEAP_LABELS = {"lookup", "format"}

def ask_small_model(instruction, text):    # stand-in for a cheap labelling model
    return " Multi_step\n" if "balls" in text else "lookup"

def ask_model(text, thinking_budget):      # stand-in: returns the budget it got
    return thinking_budget

def answer_doubt(text, still_confused=False):
    if still_confused:                     # retry: always think
        return ask_model(text, thinking_budget=4000)
    label = ask_small_model(
        "Label this maths doubt with one word: lookup, format or multi_step.",
        text,
    ).strip().lower()
    if label in CHEAP_LABELS:
        return ask_model(text, thinking_budget=0)       # normal mode
    return ask_model(text, thinking_budget=4000)        # reasoning mode

print(answer_doubt("Formula for the area of a circle?"))                      # 0
print(answer_doubt("Two balls drawn without replacement, both red?"))         # 4000
print(answer_doubt("Formula for the area of a circle?", still_confused=True))  # 4000

Run it and you should see 0, then 4000, then 4000. The second doubt comes back labelled with stray spaces and a capital letter, which the strip and lower calls clean up.

The retry check comes first, so a confused student skips the router. And the last line catches everything that is not a cheap label, including any odd word the small model returns. If your service takes effort levels, map 0 to thinking off or the lowest level your model accepts, and 4000 to the level you tested.

Now redo the daily bill. Say 3,000 of the 20,000 doubts are hard. Reasoning mode on those costs 3,000 times Rs 1.85, which is Rs 5,550, and normal mode on the other 17,000 costs Rs 4,250.

The router adds Rs 0.02 per doubt, or Rs 400. The total is Rs 10,200 a day plus a little for retries, against Rs 37,000 for thinking on everything.

You evaluate it by running both modes on the same checked questions from your own app, then comparing accuracy, cost per right answer and wait time. Public leaderboards rank models on shared tests that may look nothing like your users' questions.

An evaluation set is a fixed list of real inputs with known right answers. The team's set has 300 doubts, 200 easy and 100 hard, each checked by the teacher.

1. 1

   Build the set

   Collect real doubts from the app logs, remove student names, and have the teacher write the correct final answer for each. Keep easy and hard doubts in separate groups.

2. 2

   Check answers with code where you can

   Most answers are a number or a fraction, so a script can compare them. The teacher also reads a sample of explanations, because a right number with wrong working still confuses a student.

3. 3

   Run every mode and budget

   Run normal mode, then reasoning mode at 1,000, 4,000 and 8,000 tokens. Record thinking tokens, cost, wait and the stop reason for every answer.

4. 4

   Compare each group on its own

   Look at hard and easy doubts separately. One average over both hides where reasoning mode helps and where it only costs money.

5. 5

   Test the router too

   Count the hard doubts the router sent to normal mode. Each one is a wrong answer you could have prevented.

6. 6

   Run it again after every change

   Rerun the set whenever the model, prompt, budget or router changes. Answers can differ between runs of the same doubt, so run the hard doubts more than once.

Also watch wait time by percentile, not just the average. The p95 latency is the wait that 95 out of 100 students stay under. A few doubts may think up to the full budget, so reasoning mode can have a long tail.

After launch, keep logging thinking tokens per request. If the average creeps up after a model update, your bill rises even though your code did not change.

Explain them as a trade: more thinking tokens buy better accuracy on multi-step problems, at the price of money and wait time. Then show that you would pay that price only where it earns something back.

1. 1

   Define the idea

   Say that a reasoning model writes thinking tokens before answering, and that you usually pay for them at the output token price.

2. 2

   Split the traffic

   Name which requests need several steps and which are lookups or formatting.

3. 3

   Do rough maths

   Work out cost and wait for each mode out loud, then the cost of each extra right answer. Say the numbers are guesses to check later.

4. 4

   Route and cap

   Add a router, a thinking budget set in code, an output limit above it, and a retry path for answers that users flag.

5. 5

   Design the wait

   Explain what the user sees during a long think, and what happens at the timeout, the longest you let a request run.

6. 6

   Prove it with evaluation

   Describe the checked question set, the results per group, and how you would watch thinking tokens after launch.