Reasoning Models

Everyday chat models, when given a problem, typically carry a relatively fixed computation budget and generate answers along the most direct path. Here, budget refers to the compute actually spent during decoding: how many tokens to generate and how many computation steps to take. Ordinary models treat simple and difficult problems equally and "just keep writing"; when they encounter problems requiring multi-step derivation or comparison of multiple paths, they easily make mistakes midway without realizing it.

Reasoning models differ in the training stage. After specialized post-training, they learn to dynamically allocate intermediate computation according to the difficulty of the problem: break the problem into subproblems, compute step by step, switch to another path when hitting a dead end, and check and correct their intermediate results. Therefore, a reasoning model's "slowness" is not a malfunction but more compute spent on the process of finding the correct solution. Empirically, this extra computation budget often improves success rates on math, coding, and complex logical tasks.

There is a point where the interface can be misleading: "thinking" is not the same as the text shown to the user. Some open models return the full reasoning trace, so users can see each step of the calculation; some products hide the raw trace and give only the final answer or a brief summary. Regardless of whether there is a "thinking process" panel in the interface, you cannot judge from it whether the model used reasoning computation internally—a product that hides the trace may well have done a great deal of decomposition, search, and verification internally, and only hand over the conclusion.

From the input-output perspective, a reasoning model receives a task to be solved and the resources that go with it: available reasoning budget, candidate solution generation methods that can be called upon, and verification tools. What it outputs is not "a paragraph written by feel" but an answer that has gone through decomposition, search, checking, and correction. The key behind all this is the specialized processing during the training stage: the model learns to direct extra computation toward the process of solving difficult problems, not simply to make the visible explanation text longer. The raw trace may or may not be shown, but the internal computation process is what separates reasoning models from ordinary models.

The scope and boundaries also deserve to be made clear. Extra budget often brings significant gains on tasks that are highly structured and have verifiable answers, such as math and coding; on other types of tasks, the gains depend on the nature of the task, the model's own capabilities, and the size of the budget. No mechanism guarantees that "thinking longer is necessarily more correct"; reasoning models improve the expected success rate, not a promise of correctness for every problem.

"Think first, then answer" sounds almost the same as Chain-of-Thought, and the two are indeed closely related, but the dividing line lies in one question: who is making the model think.

Chain-of-Thought is a prompting technique. What triggers it is the prompt itself—provide examples of step-by-step reasoning in the prompt, or directly ask the model to "work step by step." After receiving such instructions, the model unfolds the process of originally producing an answer in one shot into visible intermediate steps. Its ability comes mainly from knowledge already accumulated in the model during the Pre-training stage: the model can already reason, and Chain-of-Thought prompting simply makes these capabilities explicit. In terms of computation, it usually generates a visible trace of intermediate steps, and users can see each step.

Reasoning Models take another path. The mechanism that makes the model think is trained into the model itself: through post-training methods such as Reinforcement Learning, verifiable rewards, process supervision, or outcome supervision, what is optimized is the model's strategy for allocating a reasoning budget, rather than temporarily changing behavior through a single prompt. In use, the model and service provide a reasoning budget or effort level, and the model itself decides to compute more steps on difficult problems and spend less effort on simple ones; moreover, the original reasoning trace is not necessarily shown to the user. In terms of computation, a Reasoning Model can follow a longer single trajectory, and can also combine diverse sampling, search, verification, or even tool use, offering choices far richer than "writing out the intermediate steps."

When the two are compared side by side, the differences fall along four dimensions. Triggering method: Chain-of-Thought relies on examples in the prompt or a "step-by-step" request, while Reasoning Models rely on budgets and effort levels provided by the service. Source of ability: Chain-of-Thought mainly uses capabilities already present from Pre-training, while Reasoning Models rely on strategies learned through post-training. Computation method: Chain-of-Thought usually has only a single visible chain of intermediate steps, while Reasoning Models can use multiple candidates, search, verification, and tools. Trace visibility: the intermediate steps of Chain-of-Thought are presented directly, while Reasoning Models may hide the original trace.

Therefore, to sum up in one sentence: Chain-of-Thought uses prompts to elicit intermediate steps, while Reasoning Models learn through post-training how to use a reasoning budget more effectively. The two are related but not equivalent, and they can be used together—a post-trained model can also accept Chain-of-Thought-style prompts. A confusing corollary follows: outputting a long explanation is neither a sufficient nor a necessary condition for being a Reasoning Model. Ordinary models can also be prompted to write verbose "thinking," while a true Reasoning Model may only return a brief conclusion, even though it has internally searched and verified many paths.

Past efforts to make models stronger mainly used pre-training scaling: scaling up parameter count, training data volume, and training compute together during training, advancing along scaling laws. This path remains effective, but the cost is getting higher and higher—training costs continue to climb, while high-quality available data is approaching an upper limit. Reasoning models open up a second axis: test-time scaling (test-time scaling). It does not change training; instead, at answer time, it invests more compute in the same model or model system. Specific means include extending a single reasoning trajectory, sampling multiple candidate answers and then voting, searching in the solution space, calling tools for verification, or having a verifier filter candidates. More compute can indeed improve accuracy on many difficult problems, but it usually comes with diminishing returns; if the search strategy itself is wrong, the extra compute may also be wasted.

Why multiple candidates might be useful can be seen in a purely intuitive numerical example. Assume each candidate answer is independent of the others, and the probability that a single candidate is correct is 35% (p = 0.35). When sampling 4 candidates, the probability that all 4 are wrong is (1 − 0.35)⁴, so the probability that "at least one is correct" is:

1 − (1 − 0.35)⁴ ≈ 82%

A single candidate has only a 35% chance, but after sampling several candidates, the event that "one of them is correct" becomes quite reliable. But this introduces a second component: the verifier. That a correct answer is hidden among the candidates does not mean the system can ultimately pick it out. Assume that when a correct answer exists, the verifier has an 80% probability of selecting it (q = 0.80); then the end-to-end upper bound is approximately:

0.82 × 0.80 ≈ 66%

In other words, to go from 35% to an upper bound of about 66%, the system pays nearly 4 times the computation. The meaning of each step in this example needs to be read carefully: 82% is the probability that "at least one candidate is correct," and it depends only on the coverage ability of the candidates; 80% is the probability that the verifier selects the correct candidate when it exists, and it characterizes the reliability of the filtering stage; 66% is the end-to-end upper bound obtained by multiplying the two, meaning that no matter how complete the coverage is, the final result will still be truncated by verifier errors.

Figure 1 shows this trade-off: a normal model receives a question and answers directly, while a reasoning model first invests in longer thinking before giving an answer, exchanging the extra computation spent at answer time for higher accuracy. Note that long reasoning is only one implementation method of test-time scaling; multi-candidate sampling, search, and verification also belong to test-time scaling.

Abstract the inputs and outputs of this example: the inputs are the probability p that a single candidate is correct, the number of candidates k, the correlation between candidates, and the probability q that the verifier selects the correct candidate; the output is an end-to-end success estimate under additional computation. Under the independence assumption, the core formula is 1 − (1 − p)^k. Substituting p = 0.35 and k = 4 gives about 82%, and multiplying by q = 0.80 gives an upper bound of about 66%. The boundary is also clear: real-world candidate answers are highly correlated—multiple answers sampled by the same model using similar reasoning often tend to be all correct or all wrong—so the actual benefit is usually lower than the value given by the independence assumption. The role of this numerical example is to build budget intuition, not a performance guarantee; to truly improve, both a more accurate verifier and more diverse candidates are needed at the same time.

How much additional success can one more round of thinking bring, and are these additional successes worth the extra latency and cost they require? This can be quantified with an expected-utility formula. Let b be the reasoning budget—it can be the number of candidates, the number of search steps, or the level of reasoning effort. The probability of task success at budget b is denoted P_success(b), the value brought by success is denoted V, and the budget incurs two kinds of cost: compute cost C_compute(b) and latency cost C_latency(b). The expected utility of budget b is then the success benefit minus the two kinds of cost:

U(b) = P_success(b) × V − C_compute(b) − C_latency(b)

The meaning of this formula is: adding budget raises the success probability, thereby raising expected benefit, but it also burns compute and slows down responses. What should actually be examined is not "whether adding budget helps," but whether the marginal utility brought by one more level of budget—the additional success benefit minus the additional cost—is still positive.

Use a simplified teaching example to get a feel for diminishing returns. Suppose that on the same batch of 100 problems, when the budget increases from level 1 to level 4, the number of correct answers rises from 48 to 67: an extra 300 units of compute buy 19 new correct answers, with each additional correct answer costing about 16 units of compute at the margin. When the budget is further increased from level 4 to level 8, the number correct only rises from 67 to 70, 3 more problems, but it costs another 400 units of compute, so each additional correct problem costs more than 130 units. This example does not represent any specific model, but the pattern it illustrates is universal: early budget spending has high return, while later spending becomes increasingly expensive and yields less. Since that is the case, a reasonable system should route budget according to problem difficulty, verifiability, and the cost of errors, rather than assigning the same highest budget to every request.

To allocate budget according to the nature of the task, compare the following set of situations:

The logical thread of this table is "verifiability determines the value of budget". When answers can be quickly judged right or wrong by unit tests, substitution, or formal rules, the extra compute spent on multi-candidate search can quickly be converted into a higher success rate, so the budget is worth spending. When there is no external ground-truth signal, however, extending the same model’s thinking often merely polishes errors into a more complete and more confident form, and the value of the budget drops sharply. Obscure factual questions are typical of the latter: no matter how much longer the model thinks, it cannot conjure up evidence it does not already know, and the more effective approach at that point is to retrieve, cite, or directly refuse to answer. The lesson for high-impact decisions is slightly different: adding verification is correct, but if the verifier comes from the same source as the generation side, it may make the same mistakes, so the verification stage should introduce independent tools, formal rules, and human review rather than simply piling up reasoning length.

Reasoning budget is not free; it is spent in three specific areas. First, slowness and cost: longer reasoning trajectories, more candidate answers, additional verification steps—each increases computational load, response latency, and billing costs. Second, resource occupation: regardless of whether reasoning tokens are shown to the user or hidden, candidate trajectories and tool-call results genuinely consume reasoning budget; whether these consumptions count toward the user-visible context is determined by each service's implementation and must be confirmed via the specific interface before use. The third type of cost is opportunity cost: not all tasks are worth these costs. For simple requests like "format today's date", forcing it to think long is pure waste—slower, more expensive, but the answer will not be better.

Therefore, the reasonable approach is to "adapt the strategy to the task". Difficult multi-step reasoning tasks—mathematics, code, complex logic—are where reasoning models provide the best value, because the success-rate improvement brought by the budget is enough to cover the cost; for everyday simple Q&A, a single generation with a regular model is sufficient. Many products do exactly this: automatically switch whether to enter a "think more" mode based on problem difficulty, rather than uniformly enabling maximum reasoning for all requests.

To engineer cost analysis, its inputs include trajectory length, number of candidates, number of verification passes, number of tool calls, latency SLO, and task difficulty; outputs are cost, response time, resource usage, and the routing decision made accordingly. The routing conclusion is consistent with the budget allocation section: simple formatting uses single-pass generation, difficult math problems enable multiple candidates plus verification, and high-impact tasks add independent checks rather than merely lengthening the text. A specific engineering caveat is that services differ in how they bill hidden reasoning tokens and how they handle context windows; you cannot assume from the public-facing interface—you must measure according to the interface actually used.

Treating a high budget as a guarantee of correctness is the most important intuitive mistake to guard against when using reasoning models. The benefit of test-time scaling rests on two premises: the search direction is basically correct, and the verification step can distinguish good from bad. Once these two premises collapse, adding computation only amplifies errors—the model may search deeper and more confidently on a wrong premise, and the verifier may also be fooled by "plausible-looking" answers, thereby sending wrong candidates all the way to the output.

Visibility creates an additional blind spot here. The explanations that reasoning models show users do not guarantee a faithful reflection of all their internal computation; the "thinking process" in the interface may be a summary, a rewrite, or even far from the actual computation path. Conversely, for products that hide the original traces, users have no entry point for direct auditing at all. Therefore, whether or not traces are displayed, you should not use "it looks like it thought very hard" to endorse an answer.

Correct acceptance verification should be carried out independently for each task type, rather than relying on the model's own claims. Mathematical conclusions should be independently checked, for example by plugging the answer back into the original expression; code should actually be executed and tested, not judged correct after a glance; factual statements should be verified against sources, rather than believing that the more detailed the model is, the more reliable it is. Organize these methods into a limitation-assessment process: the inputs are the search premise, candidate coverage, verifier independence, available external evidence, and final tests; the output is one of four possible conclusions—accept the answer, continue searching, switch to retrieval, or refuse to answer. When the model searches deeper and deeper along a wrong premise, and the verifier and the generation side make mistakes from the same source, this external verification is the only gate that can stop the error.

"High budget but still wrong" is not a single fault, but a failure in one link of the entire pipeline. To fix it, you must first locate which layer the failure occurs in: candidate coverage, candidate correlation, verifier selection, stopping rule, or missing evidence. Each layer has its own observable symptoms and corresponding priority fixes:

The diagnostic sequence given by this table is: first check whether a correct candidate appears, and then check whether it is selected after appearing. If you have sampled countless times without ever seeing a correct path, the problem lies in candidate coverage, and what should be changed is model capability, prompting, tools, or task decomposition strategy; if multiple candidates merely reword the same error, that is candidate correlation, requiring higher sampling diversity or heterogeneous methods; if a correct candidate is present but is outweighed by an incorrect answer, that is a verifier selection failure, and what should be supplemented is verification data, process checking, and independent rules. Stopping rules form a separate category: stopping too early misses a correct solution that has not yet appeared, while stopping too late continues to burn compute with no marginal benefit; both require the system to decide when to stop based on marginal benefit, confidence level, and a hard budget cap. The last category is missing evidence—the answer is logically coherent, but its factual premises cannot be verified at all. In this case the correct action is to retrieve, call tools, or refuse to answer, rather than letting the model continue introspection, because introspection cannot produce information about the external world.

The verifier's status needs additional clarification: it is not an arbiter of truth. Process supervision can indeed help locate errors in intermediate steps, but the verifier itself is also limited by training distribution, coverage, and bias, and can make mistakes just like the generation side. Therefore, production evaluations should record two metrics separately: whether a correct candidate appears, and whether it is selected after appearing. Only by separating these two things can you know whether the next budget should be spent on the generation side or the verification side. The inputs to the entire diagnostic process are all candidates, the differences between candidates, the verifier's ranking, the stopping point, the budget curve, and external evidence; the output is attribution to the five failure layers above. First check "is there a correct one", then check "was the correct one selected"; if there is no candidate, fix the model and decomposition tools; if a candidate was not selected, fix the verifier.

String the individual links together into a complete causal chain, and the entire logic of Reasoning Models becomes clear.

The chain's starting point lies in post-training. Reasoning Models undergo specialized post-training and learn to direct more computation toward decomposition, search, verification, and correction, thereby dynamically allocating a reasoning budget on difficult problems. This distinguishes them from prompted chain-of-thought: the two are related, but the Reasoning Model's computational strategy is trained into the model itself; the raw trajectory can be hidden, and the form of computation is not only a stretched-out text chain—it can also involve multiple candidates, search, verification, and tool calls.

Once this capability reaches the answering stage, it becomes test-time scaling: by increasing trajectory length, candidate count, search depth, or verification count, more compute is invested at answer time to trade for accuracy. The benefits vary by task and have diminishing returns—moving from low to medium budgets often yields clear gains, but beyond that the cost-effectiveness drops rapidly. Therefore the budget must be allocated according to task value, difficulty, and verifiability: simple tasks that can be deterministically checked use a single generation; difficult tasks with verifiable answers merit multiple candidates plus verification; tasks lacking facts rely on retrieval, citation, or refusal, not on thinking more. The cost of allocating this way is real: longer trajectories, more candidates, and extra verification bring higher compute, latency, and expense, and also take up Context Window—forcing long thinking on simple tasks is just slower, more expensive, and not necessarily better.

The chain's endpoint is a reminder: thinking longer does not necessarily mean being correct. Insufficient candidate coverage, highly correlated candidates, a wrongly selected verifier, inappropriate stopping rules, missing factual evidence—if any of these links breaks, high budget will amplify errors rather than correct them. Therefore mathematics requires independent rechecking, code requires executing tests, and facts require source verification; the verifier is only one link, not the judge of truth.

Conversely, tracing back from the endpoint to the starting point also reveals design points: production evaluation should separately record "whether the correct candidate appears" and "whether it is selected after appearing", and then decide whether the next budget should go to the generation side or the verification side; every incremental increase or decrease of budget must be measured by marginal utility, not by assuming more is better. Mastering this chain means grasping the core of Reasoning Models: its difference from chain-of-thought lies in "who makes it think" and whether the computational strategy is trained into the model; and test-time scaling is a new scaling axis precisely because it does not rely on continuing to scale up training, but instead trades compute for accuracy at answer time, standing alongside Pre-training scaling as a direction for improving model capabilities.

Placed in the larger concept map, its position is clear.

There are three prerequisite concepts: Chain of Thought (CoT), large language models, and scaling laws. Chain of Thought is the point of comparison for this page—only by understanding what it means to "elicit intermediate steps through prompts" can you clearly see the difference that reasoning models train reasoning strategies into the model itself; large language models provide foundational capability, and reasoning models are a further shaping of that capability; scaling laws provide the background—when pre-training scaling becomes increasingly expensive and data increasingly scarce, test-time scaling qualifies as a new scaling axis.

The core concepts on this page form an interlocking cluster: reasoning post-training answers where capability comes from; reasoning budget characterizes the amount of computation invested when answering; long trajectories, multiple candidates, search, and verification are the specific ways the budget is spent; hidden CoT serves as a reminder of the difference between "interface visibility" and "internal computation"; diminishing returns sets an economic boundary on the budget. Stringing these five concepts together gives the complete logic of reasoning models from training to deployment.

There are four adjacent extension directions. RLHF (reinforcement learning from human feedback) and reasoning post-training both belong to the post-training family; comparing them reveals how reward signals and supervision methods affect model behavior; self-consistency is a direct extension of the multiple-candidates-plus-voting idea, and the numerical examples on this page can transition smoothly to it; Tree of Thoughts (ToT) extends "a single trajectory" into an explicit search tree, deepening search-based test-time scaling; the context window is a tight engineering constraint—all visible or hidden reasoning tokens must occupy it, and the longer the reasoning, the more prominent the window and cost issues become.

Extensions further afield are likewise naturally derived from this page's concepts: synthetic data relates to the training data issues of reasoning models; evaluation follows up on the engineering requirement that "production environments must separately record whether correct candidates appear and whether they are selected"; interpretability follows up on the blind spot that "visible explanations may not faithfully reflect internal computation"; AI Agent is the natural next step after reasoning models are paired with tool calling—the threads of "verification" and "tools" on this page will unfold there into complete action capabilities.