Why Can Large Language Models Adjust Their Reasoning Intensity?

Why can the same model think less, yet also think longer?

The same problem, the same model.

When you adjust reasoning intensity from low to high, the answer can sometimes improve significantly.

But the model parameters haven’t increased, the number of neural network layers hasn’t changed, and training has long been completed. Where does this extra capability come from?

The key isn’t that the model suddenly knows more things, but that it is allowed to invest more computation before producing the final answer.

This is the most important change behind reasoning effort:

The performance of large language models has begun to depend not only on what they learned during training, but also on how much computation they invest in answering the current problem.

In the past, we mainly adjusted capabilities by swapping models: using small models for simple tasks and large models for complex tasks.

Now, the same reasoning model can operate at different gears, making trade-offs between answer quality, response speed, and computational cost.

Reasoning effort essentially adjusts:

How many steps this problem is worth, how many times to check, and when to stop.

1. Ordinary Chat Models Also Reason, But Typically Enter the Final Answer Faster

The most fundamental way a large language model works is by predicting the next token.

After the user inputs a question, the model reads the current context and predicts the most likely next token; after generating it, subsequent predictions are conditioned on this new token to continue generating the next step.

This process can be expressed as:

tn+1 ~ Pθ(tn+1 | x, t1, t2, …, tn)

where:

• x is the user input;

• t1 to tn are the tokens already generated;

• tn+1 is the next token to be generated;

• θ is the model parameter fixed after training.

This formula reveals a very important thing:

Every time the model generates a new token, subsequent predictions will take it as a new condition.

From a mathematical expression, the model’s next step references all previous context. In engineering practice, KV Cache is usually used for incremental computation, rather than recalculating the full context from scratch for each token generated.

Ordinary chat models can also exhibit analytical and reasoning abilities. Sometimes, telling it to “explain step by step” can produce a seemingly complete logical process.

Therefore, the difference between reasoning models and ordinary chat models is not that the former can think while the latter cannot at all.

A more accurate distinction lies in:

• Whether they have undergone specialized reasoning post-training;

• Whether they can stably utilize longer intermediate computational processes;

• Whether they allocate a dedicated reasoning budget before the final answer;

• Whether they support controlling this computational investment through parameters.

Many traditional chat models can generate reasoning processes, but they usually do not expose an adjustable reasoning budget and may not have been specifically trained to stably utilize longer test-time computation.

For tasks like translation, rewriting, classification, and information extraction, this is usually sufficient. However, when faced with complex problems, the first answer that comes to mind is often just a starting point.

For example, a user might ask:

An order interface occasionally causes duplicate deductions. Where should I start troubleshooting?

A quick answer might be:

Check if the interface is being submitted repeatedly and add an idempotency mechanism for payment requests.

This answer is not wrong.

But real duplicate deductions can originate from many different points:

• User clicking repeatedly;

• Client-side timeout retry;

• API gateway automatic retry;

• Payment succeeds, but the response is lost in the network;

• Message queue duplicate delivery;

• Payment callback being consumed repeatedly;

• Database transaction commits successfully, but business status is not updated in time;

• Idempotency key only works on part of the chain.

Complex tasks do not just require quickly giving a seemingly reasonable answer, but rather unfolding a complete processing flow:

Confirm the phenomenon, break down possible causes, gather evidence, eliminate hypotheses, verify the fix, and finally reach a conclusion.

What reasoning intensity affects is precisely how far this process can be unfolded.

2. What Actually Happens Computationally When the Model “Thinks a Bit Longer”?

High reasoning intensity is not about temporarily adding more network layers to the Transformer.

Nor can it be simply understood as: low uses a small model, high secretly switches to a large model. There might be server-side routing in commercial systems, but variable reasoning itself does not require changing the model.

A more accurate explanation is:

Before outputting the final answer, the model forms a longer intermediate reasoning trace, thus executing more serial autoregressive computations.

One inference can be abstracted as:

x → z1 → z2 → … → zk → y

where:

• x is the original problem;

• z1 to zk are intermediate reasoning states;

• y is the final answer;

• k represents the length of the reasoning trace.

Each intermediate state is generated by the model continuing:

zi ~ Pθ(zi | x, z1, z2, …, zi−1)

The final answer is then generated based on the previously formed reasoning trace:

y ~ Pθ(y | x, z1, z2, …, zk)

In publicly available variable reasoning models, the model weights can remain unchanged, while the distribution of reasoning trace length k changes with the reasoning level: higher levels usually allow the model to form longer intermediate processes.

For closed-source systems, tool budgets, stopping strategies, candidate search, and server-side routing may also change simultaneously, and the specific implementation is not fully disclosed.

Back to the duplicate deduction example.

The model might first form an intermediate judgment:

First distinguish whether the duplicate deduction occurs on the request side, payment side, or asynchronous callback side.

In the next round of computation, the model no longer sees only the user’s original question; it is also influenced by this newly formed state.

Then, it might continue to judge:

If the payment platform only received one request, but the system recorded two orders, the problem is more likely to be in the local transaction or callback consumption.

This judgment then becomes the condition for the next step of analysis.

The reasoning trace might gradually unfold:

Order duplicate deduction → Distinguish duplicate request vs duplicate consumption → Check payment platform request logs → Check gateway and client retries → Check message consumption and callback idempotency → Check transaction boundaries → Design verification method → Give fix priority

The physical depth of the model’s network has not changed, but it has obtained more serial computation steps, forming a longer effective computational path.

Why do reasoning tokens have computational value?

Because the generated tokens affect subsequent predictions.

Intermediate tokens can serve roles similar to these:

• Store current hypotheses;

• Record directions already eliminated;

• Store intermediate computational results;

• Mark unresolved issues;

• Record data returned by tools;

• Remind what needs to be verified next.

It’s a bit like scratch paper, and a bit like temporary variables in a program.

When an engineer troubleshoots duplicate deductions, they don’t restart from the original problem at every step. They record:

• The payment platform has only one deduction record;

• The gateway experienced one timeout retry;

• The callback consumer has no unique constraint;

• The database contains two identical business transaction IDs.

These records form the state that subsequent judgments depend on.

Reasoning tokens can play a similar role for the model.

However, we must avoid an overly anthropomorphized understanding: the model’s intermediate reasoning is not necessarily a complete, clear article readable by humans.

More precisely:

Reasoning tokens can serve as a serialization carrier for intermediate states, preserving useful information for subsequent computations.

The model’s complete internal state still exists in computational structures like hidden representations, attention mechanisms, and KV Cache, and cannot be fully equated with visible text tokens.

3. Making the Model Write Longer Does Not Automatically Produce Stronger Reasoning

Since longer intermediate traces provide more computational opportunities, would any model become smarter if we simply increase the maximum output length?

It’s not that simple.

A model not specifically trained for reasoning, even if given more generation space, might simply:

• Repeat points already made;

• Elaborate further on incorrect assumptions;

• Fabricate more unverifiable details;

• Constantly rewrite the same conclusion;

• Already have the answer but not know when to stop.

More tokens only represent more computational opportunities, not a guarantee that those opportunities will be used effectively.

Giving a student more exam time does not automatically improve their grade.

If they don’t know how to break down problems, check work, and correct errors, the extra two hours might just let them dwell longer on wrong answers.

For more computation to translate into real capability, the model needs to learn a set of reasoning strategies:

• Which conditions to process first;

• How to break down complex problems;

• When to try a different route;

• How to identify contradictions;

• When to call external tools;

• How to verify results;

• When to stop.

This is where reasoning post-training comes into play.

From a reinforcement learning perspective, the model is no longer just facing:

What should the next token be?

But rather:

Given the current state, what next action is more likely to eventually complete the task?

The “action” here is an abstraction. It might manifest as:

• Forming an intermediate conclusion;

• Splitting off a sub-problem;

• Modifying the current hypothesis;

• Calling a search tool;

• Running code;

• Checking the answer;

• Ending the reasoning.

In verifiable tasks, the training system can more clearly judge the quality of the result:

• Is the math answer correct;

• Does the code pass the tests;

• Did the tool call achieve the goal;

• Does the output satisfy constraints;

• Does the execution result pass the verifier.

The model will try different reasoning traces.

Some paths are short and effective, some are long but worthless, and some can detect errors midway and backtrack.

Through supervised fine-tuning, reinforcement learning, verifiable rewards, and post-training on tool usage, more effective strategies are gradually reinforced:

Split first, then execute; backtrack when evidence conflicts; critical conclusions need verification; end when the answer is sufficiently reliable.

Thus, the breakthrough of reasoning models is not just about being able to output more text.

What’s really important is:

The model has begun to learn how to organize longer generation processes into effective computation.

4. What Exactly Does Reasoning Effort Control?

Once a model has reasoning ability, it also needs to learn to use different reasoning gears for different tasks.

“Rewriting a paragraph to make it smoother” and “troubleshooting a distributed system failure” obviously should not consume the same amount of computational resources.

To describe this process, we can use a conceptual model:

Pθ(z, y | x, e)

where:

• x is the task input;

• e is the reasoning intensity, e.g., low, medium, high;

• z is the intermediate reasoning trace;

• y is the final answer.

This is not an exact network architecture or training objective disclosed by vendors, but a mathematical abstraction to help us understand variable reasoning.

It expresses:

Under the same problem x, different reasoning intensities e may lead the model to form different intermediate traces z, and thus generate different final answers y.

Using the chain rule of conditional probability, it can also be written as:

Pθ(z, y | x, e) = Pθ(z | x, e) × Pθ(y | x, z, e)

The first part indicates:

Given the current problem and reasoning intensity, what kind of reasoning process will the model form?

The second part indicates:

Based on this reasoning process, what final answer will the model generate?

Under lower reasoning intensity, the model usually tends to:

• Quickly identify the main pattern;

• Reduce search branches;

• Do less repeated verification;

• Generate the final answer earlier.

Under higher reasoning intensity, the model may tend to:

• Split out more sub-problems;

• Explore alternative explanations;

• Check key assumptions;

• Backtrack and try new routes;

• More actively call tools in models that support tool use;

• Delay the final answer.

Back to the duplicate deduction example.

Low reasoning intensity might quickly lock onto “idempotency” as a common cause and give a general suggestion.

High reasoning intensity might continue to ask:

• Did the duplicate deduction really occur at the payment platform?

• Was the same payment order deducted twice, or did the system generate two payment orders?

• Does the request carry a stable business idempotency key?

• Is the idempotency record written before the transaction, or after the transaction?

• Do the gateway, client, and message system each have their own retries?

• Could third-party callbacks arrive concurrently?

• Can a database unique constraint serve as a last line of defense?

• Does the fix cover the scenario of “deduction succeeded but response lost”?

This is not just writing the answer longer; it’s expanding more hypothesis, checking, and verification steps.

What can be confirmed

Based on public information and open models, it can be stated with confidence that:

• Reasoning intensity affects the average number of reasoning tokens used;

• Higher reasoning intensity usually increases latency and computational cost;

• The same model weights can be conditioned on different reasoning levels;

• In some models that support tool calls, reasoning intensity affects the tendency to call tools;

• Different tasks benefit differently from extra reasoning.

The open-weight model gpt-oss supports reasoning levels like low, medium, and high. Public documents show that increasing the reasoning level increases the average chain-of-thought length and, on some complex benchmarks, shows a trend of improvement with increased test-time computation.

APIs can also separately count reasoning tokens. Reducing reasoning effort usually reduces reasoning tokens and decreases response time.

What is not fully disclosed

How closed-source models internally convert low, medium, high into specific execution strategies is usually not fully disclosed by vendors.

Possible system mechanisms include:

• Hidden control tokens;

• Soft reasoning budgets for different levels;

• Dynamic stopping thresholds;

• Maximum number of tool calls;

• Multi-candidate path generation;

• Additional verifiers;

• Decoding strategy adjustments;

• Server-side model routing.

These are all reasonable engineering possibilities, but they cannot be regarded as certain mechanisms adopted by all closed-source models.

Therefore, it is not accurate to equate reasoning intensity directly to a fixed number, such as:

low equals 500 tokens, high equals 5000 tokens.

Real systems are more likely to implement it as a set of trained and calibrated strategies.

Reasoning Effort is more like a level of computational strategy; reasoning tokens are one of the observable results produced by this strategy.

5. The Challenge in Mature Reasoning Systems Is Not “Thinking More,” But “Knowing When to Stop”

Since extra computation can potentially improve quality, why not use the highest reasoning intensity for all tasks?

Because reasoning has costs and diminishing marginal returns.

We can represent it with a conceptual model:

U(k) = Q(k) − λC(k)

where:

• k is the number of reasoning steps already invested;

• Q(k) is the expected answer quality from these steps;

• C(k) is the corresponding computation, latency, and tool cost;

• λ represents the system’s sensitivity to cost;

• U(k) is the overall utility.

Whether it is worth continuing to reason can be further expressed as:

ΔQ > λΔC

That is:

Only when the expected quality improvement from the next reasoning step still outweighs the extra cost it incurs, is it worthwhile to continue computing.

This is not a precise training formula disclosed by vendors, but a conceptual model for understanding reasoning budgets and stopping mechanisms.

Under low reasoning intensity, we can think of λ as relatively large.

The system values speed and cost more, so it tends to stop earlier.

Under high reasoning intensity, we can think of λ as relatively small.

The system is willing to invest more computation to try to reduce answer uncertainty.

Continuing the analysis of the duplicate deduction problem, the initial steps are usually very valuable:

• Clarify at which layer the duplication occurs;

• Find the source of retries;

• Check the idempotency key;

• Check unique constraints and transaction boundaries.

But continuing to expand infinitely, the model might also start discussing:

• Extremely low probability payment platform anomalies;

• Cross-region consistency irrelevant to the current architecture;

• Network attacks with no supporting evidence;

• Components that do not exist in the actual system.

Stopping too early misses critical conditions.

Stopping too late can complicate simple problems or even introduce new wrong assumptions.

Higher reasoning intensity also does not automatically fix:

• Wrong knowledge;

• Wrong input;

• Wrong objective;

• Wrong premise;

• Missing critical data.

Thinking longer might allow the model to find errors.

But it might also make the error more complete.

A mature reasoning system must first learn not to endlessly extend the reasoning chain, but to judge:

Is it still worth continuing to compute?

6. Which Tasks Deserve More Reasoning?

The benefits of reasoning intensity are highly dependent on task type.

The following is an empirical classification, not a universal law applicable to all models and all datasets. Actual benefits still need to be confirmed through evaluation.

Extra reasoning usually yields low returns

• Information extraction;

• Text classification;

• Format conversion;

• Rewriting;

• Translation;

• Simple summarization.

Extra reasoning may yield medium returns

• Routine programming;

• Document analysis;

• Multi-condition plan comparison;

• Data interpretation;

• General architecture design.

Extra reasoning is more likely to yield high returns

• Complex code debugging;

• Mathematical and scientific reasoning;

• In-depth research and cross-validation;

• Long-range agent tasks;

• Multi-tool collaborative tasks;

• Complex analysis with high error cost.

The answer path for simple tasks is usually short.

Extracting a date from an email, converting content to JSON, or determining which category a text belongs to does not require a long search for solutions.

Increasing reasoning intensity at this point often just increases waiting time and cost.

Complex tasks are different.

For example, troubleshooting duplicate deductions requires the model to manage multiple hypotheses simultaneously, distinguish between different system layers, read logs, check databases, and even call query and code tools.

Its process is closer to:

Estimate problem scope → Split possible causes → Gather evidence → Eliminate hypotheses → Execute verification → Correct plan → Output conclusion

Such tasks have more intermediate nodes, and thus more opportunities to benefit from extra reasoning.

Public information also shows significant differences in how sensitive different tasks are to reasoning intensity. Some relatively simple long-context retrieval tasks see limited returns from increasing reasoning beyond a low level, while complex visual reasoning tasks may see more significant improvements.

In real products, you shouldn’t just look at whether the answer improved, but also measure:

• How much the success rate increased;

• How much the response delay increased;

• How many more reasoning tokens were used;

• How much tool call costs increased;

• The total cost per successful problem resolution.

A more reliable metric is not “single answer score,” but:

Cost per successful task = Total cost of all requests ÷ Number of successfully completed tasks

And:

Latency per successful task = Total time of all requests ÷ Number of successfully completed tasks

The optimal choice is usually not to always use high, but to match task complexity, error risk, and computational budget.

7. The Real Change Is That the Model Begins to Participate in Allocating Computational Resources

On the surface, reasoning effort is just one more parameter in the API.

But over a longer time scale, it represents a structural change in large language models.

In the past, we were used to viewing the model as a one-shot input-output function:

y = Fθ(x)

Input a problem, output an answer.

Reasoning models are increasingly becoming an execution process that continuously updates its state.

This can be expressed with an abstract formula:

st+1 = Fθ(st, x, e, ot)

where:

• st is the current task state;

• x is the user goal;

• e is the reasoning intensity;

• ot is an observation returned by a tool or the environment;

• st+1 is the updated state.

This is also a conceptual abstraction, not a specific public network interface from any vendor.

What it aims to express is:

The system no longer performs just one input-output; it can form a current judgment, take action, read results, update the state, and then decide whether to continue or stop.

In ordinary Q&A, this might just mean checking a few more steps.

In an agent system, it might mean:

• Search for information one more time;

• Read one more document;

• Execute one more database query;

• Run one more test;

• Re-plan based on failure results;

• Call another tool for cross-validation.

The reasoning budget controls not just a segment of “thinking” before the final answer, but potentially how many resources the entire task execution process can use.

Today, this budget is often set manually by the user or developer:

low, medium, high

In the future, more mature systems may judge for themselves:

• How hard is this task;

• How uncertain is the current conclusion;

• How high is the cost of error;

• How much latency can the user tolerate;

• How much computation does the current budget allow;

• Is external evidence needed;

• Is it worth running another verification.

The execution process may gradually become:

Estimate difficulty and risk → Allocate initial budget → Start execution → Check current uncertainty → Add computation if necessary → Stop when returns are insufficient

This is adaptive reasoning.

Simple tasks are completed quickly, complex tasks get more resources, high-risk tasks automatically increase verification.

From this perspective, a new dimension is emerging in the competition among large language models.

In the past, it was about who had stronger fixed capabilities.

Next, it will be about:

• Who can more accurately judge task difficulty;

• Who can complete the same task with less computation;

• Who knows when to continue;

• Who knows when to stop;

• Who can combine reasoning, tools, and verification more effectively.

Conclusion

Reasoning effort does not regulate how much knowledge the model stores, nor just how long the final answer is written.

It controls how many steps the model is willing to take on the current problem, how many hypotheses to expand, how many checks to perform, and when to stop.

To understand it, you can grasp four layers of principle.

First layer, the model runs autoregressively token by token:

tn+1 ~ Pθ(tn+1 | x, t1, t2, …, tn)

Second layer, intermediate tokens can carry useful information during the reasoning process, forming a variable-length computational trajectory:

x → z1 → z2 → … → zk → y

Third layer, reasoning intensity serves as a control condition, influencing what reasoning strategy the model chooses:

Pθ(z, y | x, e)

Fourth layer, the system needs to decide whether to continue or stop, balancing potential quality gain against computational cost:

U(k) = Q(k) − λC(k)

In the past, the question was:

Which model should I use?

The next more important question will be:

How much computation is this task worth for the model to complete?

That is what makes reasoning effort truly worth paying attention to.

It turns “thinking time” into a system variable that can be trained, controlled, and scheduled.