Techniques and Implementations for Controlling Reasoning Effort in Large Language Models

Techniques and Implementations for Controlling Reasoning Effort in Large Language Models Controlling reasoning effort in large language models bridges training and inference scaling, enabling models to adjust intermediate reasoning trace lengths to balance accuracy and compute costs across diverse tasks. Reasoning models generate intermediate thinking traces before answering, relying on verifiable rewards (RLVR) to develop behaviors like self-correction and backtracking. Controlling reasoning effort is not possible through arbitrary prompt engineering alone and requires targeted post-training adaptations, including length penalties and effort-conditioned fine-tuning. Open-weight models implement effort control via discrete modes, continuous numerical scales, token budget constraints, or empty delimiter prefill switches. Inference scaling allows smaller models operating at higher reasoning effort to match the accuracy benchmarks of larger models with lower reasoning effort. Mechanics of Reasoning Models and RLVR In LLM research, a reasoning model refers to an architecture that outputs an intermediate reasoning trace to work through tasks step-by-step rather than literally emulating human thought. Performance on reasoning tasks is guided by training scaling and inference-time scaling. Under reinforcement learning with verifiable rewards (RLVR), binary reward signals are provided on verifiable domains like math and code. DeepSeek-R1 demonstrated that training on final output rewards alone allowed models to develop intermediate explanations and self-correction without needing intermediate traces for model updates. Furthermore, delimiters such as <think> and </think> are cosmetic formatting markers enforced via formatting rewards to demarcate traces for user interfaces and pipelines, rather than drivers of reasoning ability. Inference Scaling and Hybrid Execution Modes Because reasoning models output more tokens during inference, they naturally scale inference compute. Techniques like self-consistency majority voting can push performance higher, but increasing reasoning budgets eventually encounters saturation where extra compute becomes uneconomical. Early models like DeepSeek-R1 lacked mechanisms to disable reasoning for simple prompts. Later models introduced hybrid toggles and effort modes, demonstrating that smaller models running high reasoning effort can match the benchmark performance of larger models at lower effort. Because models cannot modulate effort reliably through prompting alone, developers implement post-training modifications combining length penalties in RLVR, effort-conditioned supervised fine-tuning (SFT), or distillation. Discrete Modes and Distillation in DeepSeek and Nemotron DeepSeek V4 provides Non-think, Think High, and Think Max settings. Think Max utilizes training modifications, including a longer context window and smaller length penalties, with the final model created via on-policy distillation from reasoning and domain specialists trained with Group Relative Policy Optimization (GRPO). Nemotron 3 Ultra offers reasoning-off, regular, and medium-effort modes selected via chat templates, where disabling reasoning prefills an empty <think></think> block. Nemotron trains on medium-effort data generated by GPT-OSS-120B and applies length-based reward adjustments in RLVR. It also accommodates hard token limits by training on truncated reasoning traces with the closing delimiter masked from SFT loss. Budget Management and Continuous Conditioning in Kimi, GLM, Qwen, and Inkling Kimi K2.5 utilizes a Toggle method alternating between budgeted and unconstrained RL phases to prevent models from overfitting to short solutions, reducing tokens by 25 to 30 percent while maintaining benchmark performance. Kimi K3 relies on multi-teacher on-policy distillation across nine specialist models, imposing negative rewards on simple tasks that breach token budgets. GLM-5 supports interleaved, preserved, and turn-level thinking managed via template markers and sequential RL. Qwen3 integrates a Thinking Mode Fusion stage to toggle reasoning and inherently handles hard thinking budgets. Finally, Inkling employs continuous effort labels between 0.0 and 1.0, using asynchronous RL where per-token cost penalties scale inversely with the specified effort level.

大语言模型推理工作量控制的技术机制与主流开源实践 大语言模型（LLM）的推理能力主要依赖训练扩展与推理期计算扩展，但过度冗长的思维链会导致计算成本激增。为了在准确率与开销之间取得平衡，主流模型正在通过可验证奖励强化学习（RLVR）、长度惩罚及提示词调节等后训练改造，实现对推理工作量（Reasoning Effort）的灵活控制。 推理模型通过输出中间推理轨迹来提升表现，其工作量控制依赖后训练阶段的特定修改而非单纯的提示词工程。 分界符（如 <think></think>）本质上是界面与训练流程的分隔标记，配合 tokenizer 开关或空标记预填可实现推理模式的硬切换。 推理缩放与模型规模缩放存在性能重叠，较小模型在高推理工作量下可匹敌低工作量的大模型，但计算效益在超高预算下会趋于饱和。 主流开源模型（包括 DeepSeek V4、Nemotron 3 Ultra、Kimi、GLM-5、Qwen3 及 Inkling）探索了离散档位、硬性截断、动态交替训练与连续数值调节等多元化控制方案。 推理模型机制与推理期扩展 推理模型并不等同于人类思维，而是指能够生成中间推理轨迹以逐步解题的模型。以 DeepSeek-R1 为代表的模型表明，基于可验证奖励的强化学习（RLVR）仅依赖最终输出的正确与否作为奖励信号（0 或 1），无需中间轨迹监督，即可促使模型自发学会解释、回溯与自我纠错。RLVR 带来了固有的推理期扩展，模型在生成更多 Token 的同时消耗更多计算资源。<think> 和 </think> 分界符仅具备外观和流程分割作用，通过格式奖励强制施加，其本身不赋予模型推理能力。 推理工作量与算力效益权衡 推理工作量与 Token 消耗量直接相关，进而影响准确率。根据测试数据，固定模型的推理扩展曲线与不同尺寸模型的训练计算扩展曲线存在重叠，意味着小型模型在高推理工作量下的测试得分可与低工作量的大型模型相当。然而，当推理预算进一步提高时，性能收益会出现饱和甚至失去经济效益。要让模型响应推理工作量指令，仅凭提示词无效，必须结合带有长度惩罚的 RLVR 或基于工作量标签的监督微调（SFT）等后训练改造。 开关切换与离散推理档位的实现路径 不同开源模型采用了各具特色的工作量控制设计。Qwen3 引入“思考模式融合”阶段，支持通过标记器开关直接预填空的 <think></think> 来关闭推理，且在未显式训练的情况下涌现出了硬性截断预算能力。DeepSeek V4 设立非思考、高思考与极度思考（Think Max）三档，后者享有更长的上下文窗口和更小的长度惩罚，并通过推理与领域专家的在线蒸馏形成最终模型。Nemotron 3 Ultra 兼具常规、中等与关闭模式，在训练中引入随机截断轨迹并遮蔽结束标记损失，从而支持客户端在 Token 耗尽时强制结束思考并直接作答。 预算交替、连续调节与多专家蒸馏 为了避免固定预算导致模型过拟合于简短解法并丧失扩展能力，Kimi K2.5 提出了 Toggle 方法，在有预算约束与无约束两个 RL 阶段交替更新同一策略，使生成 Token 减少 25% 至 30% 且基准表现不降。其后续版本 Kimi K3 则训练了跨领域的 9 个专家模型，通过自然语言指令统一蒸馏。GLM-5 涵盖交错思考、跨轮保留思考及轮次级开关。Thinking Machine Labs 的 Inkling 则采用了连续数值调节方案，在系统消息中设定 0.0 到 1.0 的连续工作量参数，并通过大规模异步 RL 按请求工作量动态调整每个 Token 的惩罚成本。

It has been almost two years since OpenAI released o1, a model that popularized the idea of LLM-based reasoning models. DeepSeek-R1 followed about four months later, together with details of a reinforcement learning with verifiable rewards (RLVR) recipe to train such reasoning models. Last week, OpenAI released the GPT-5.6 model family. It comes in three sizes, each with roughly five or six reasoning-effort settings. So yes, reasoning models are here to stay. They have become a standard part of modern model releases. In the past, I covered the methodology of reasoning models ([Understanding Reasoning LLMs](https://www.google.com/url?q=https://magazine.sebastianraschka.com/p/understanding-reasoning-llms&sa=D&source=editors&ust=1784335866721316&usg=AOvVaw3KNY841B7H7EqshVnEJp8D)) as well as relevant research papers ([The State of Reinforcement Learning for LLM Reasoning](https://www.google.com/url?q=https://magazine.sebastianraschka.com/p/the-state-of-llm-reasoning-model-training&sa=D&source=editors&ust=1784335866721667&usg=AOvVaw1WaEOS_3zXEmP9JnLDSoZK) and [The State of LLM Reasoning Model Inference](https://www.google.com/url?q=https://magazine.sebastianraschka.com/p/state-of-llm-reasoning-and-inference-scaling&sa=D&source=editors&ust=1784335866721813&usg=AOvVaw2nWsugtg_XcMLKTUGcnk7B)). And I even wrote a whole new 440-page book on how to develop reasoning models, [Build A Reasoning Model (From Scratch)](https://www.google.com/url?q=https://sebastianraschka.com/books/%23build-a-reasoning-model-from-scratch&sa=D&source=editors&ust=1784335866721991&usg=AOvVaw1JZMrDei_qWFsW_OMMNnyL). These resources have focused on turning a conventional LLM into a reasoning model. Now, in this article, I want to focus on and explain how to develop a reasoning model that has multiple effort modes, similar to what’s shown in the figure at the beginning of this article. No worries, this article can be read as a standalone article. However, the aforementioned resources may be interesting and useful. When talking about pretty much any machine learning or AI technique or subfield, the one lesson is that we usually shouldn’t take technical terms “literally”. For example, an (artificial) neural network in machine learning and AI doesn’t literally work like a biological neural network like the human brain. Similarly, when talking about “reasoning models”, we shouldn’t expect that these models literally reason like us humans. In the context of AI and LLM research, “reasoning model” means a model that outputs an intermediate reasoning trace, which is like an intermediate response that works through a question or task step by step. It’s probably easiest to explain this by showing an example. There are essentially two ways to improve (reasoning) task performance: training scaling and inference scaling. Let’s briefly talk about training first. In a nutshell, [DeepSeek-R1](https://arxiv.org/abs/2501.12948) proposed training an LLM using reinforcement learning with verifiable rewards (RLVR) to turn it into a reasoning model. RLVR is a technique to provide a reward signal (`0=incorrect` and `1=correct`) for verifiable data domains. These verifiable data domains here are math (we can use a symbolic math checker like SymPy or WolframAlpha to check results) and code (we can use a compiler or unit tests, or integrated platforms like LeetCode) to check for correctness. Notably, the reasoning trace itself was not used for training or updating the model. Although they tried to use this intermediate response information for training, the DeepSeek-R1 paper reported that it wasn’t helpful for the model training, so it was ultimately not used. (Whether and how to incorporate intermediate reasoning traces in the training signal via process reward models is an active area of research.) Anyway, just training on the output rewards alone, as Figure 7 shows, turned out to be sufficient for the model to learn how to reason through a problem, meaning that it would learn to write intermediate explanations, backtrack, and self-correct itself. These moments when the model realizes that it made a mistake and self-corrects itself are called “Aha” moments. By the way, while DeepSeek-R1 is inarguably the more popular paper, and the paper that created excitement around reinforcement learning with verifiable rewards and the development of reasoning models, there is another paper, [Kimi K1.5](https://arxiv.org/abs/2501.12599), published on exactly the same day on arXiv (22 Jan 2025). Also, the term RLVR was already coined two months earlier in [Tülu 3: Pushing Frontiers in Open Language Model Post-Training](https://arxiv.org/abs/2411.15124). One reason why the DeepSeek R1 is ultimately the more popular paper is that it demonstrated that reasoning behavior can be achieved with pure reinforcement learning (RL). For instance, Tülu 3 and Kimi K1.5 applied reinforcement learning on top of a supervised fine-tuned (SFT) model. The DeepSeek-R1 model was also trained from an SFT checkpoint of the DeepSeek-V3 base model, and it included a DeepSeek-R1-Zero variant trained with pure RLVR. R1 Zero is a weaker model than R1, but it showed that RLVR is sufficient for teaching the model to generate and use reasoning traces. While R1-Zero was more of a proof-of-concept model, note that the full DeepSeek-R1 reasoning model training pipeline is usually multi-stage and a bit more complicated, as mentioned above. By the way, most of today’s LLMs are effectively reasoning models, meaning they have been trained in a similar fashion to DeepSeek-R1 using a form of RLVR. Next to improving reasoning behavior through training, another lever for improving model performance is inference compute scaling. In short, this means that we are spending more compute after training the model, during usage, to get better answers. This is a whole topic by itself, and you could read through my The State of LLM Reasoning Model Inference for a more detailed rundown: I will try to summarize what’s most essential to mention as background info below. First, training a model with RLVR is already implicitly leading to a form of inference scaling, since reasoning models usually output more tokens during inference compared to conventional LLMs, and that means we are spending more compute during inference. Second, we can further adjust this output length via reasoning effort levels, but more on that later. Third, there are many additional inference scaling techniques. A popular one is self-consistency, which is often implemented as a form of majority voting where the model is queried multiple times, and the final answer is selected via majority vote. This can be applied to conventional LLMs as well as reasoning models. Also, this method can be used on demand and in addition to reasoning training. A good example of that is DeepSeekMath-V2, where the researchers applied extreme inference-scaling on top of a reasoning model (specialized for math) to achieve state-of-the-art performance on challenging math olympiad-type problems. But again, I will refer to my other article, The State of LLM Reasoning Model Inference for an overview of other techniques: You may have seen the `<think></think>` tokens in the earlier “Aha moments” figure. I also included the corresponding figure below so you don’t have to scroll all the way up. These `<think>` and `</think>` tags are cosmetic with respect to reasoning ability. They do not make the model reason, and they are not required to achieve good reasoning performance. One could train the same model without these delimiters and likely reach similar benchmark performance. The purpose of these `<think>` tags or tokens is mainly to mark where the reasoning trace begins and ends so that the training pipeline or user interface can separate it from the final answer and optionally hide it from the user. (UIs like ChatGPT or Codex usually do this.) The point here is that the `<think>` tokens are not giving the model the ability to “think” or reason or reason better. One could train the same models without such `<think>` tokens and reach similar benchmark performance. There is also nothing special about the literal strings `<think>` and `</think>`. Another pair of delimiters could serve the same purpose. By the way, the way this is implemented is typically by adding a formatting reward during the RLVR stage. So instead of just rewarding the model based on answer correctness, one would provide additional reward for the use of \<think> tokens, which in turn encourages the model to use those. In DeepSeek-R1, for example, the overall reward was calculated as `R_total = R_accuracy + R_format` where the format reward was a simple rule-based check that encouraged the model to place its reasoning inside: `<think>` reasoning trace `</think>`. The first generation of reasoning models was dedicated reasoning models. With that, I mean that there was a DeepSeek-V3 base model and a separate DeepSeek-R1 reasoning model. No matter what the prompt is, R1 generally outputs very verbose responses using lots of tokens, even for simple prompts. It also lacks a built-in option to turn off the reasoning mode. Later models, like Qwen3 and others, experimented with hybrid approaches, where the same model can behave like a regular instruction fine-tuned model or a reasoning model on demand. Note: Some model developers call this “thinking mode,” while others call it “reasoning mode.” Both terms refer to the same behavior. In Qwen3, this is handled via the tokenizer using `enable_thinking=True` or `enable_thinking=False`. Under the hood, setting `enable_thinking=False` essentially adds an empty `<think></think>` section to the beginning of the assistant response to turn off Qwen3’s reasoning (”thinking”) mode. How is this implemented during training, such that the model supports this toggle during inference time, as shown in the figure above? In short, as explained in the [Qwen3 technical report](https://arxiv.org/abs/2505.09388), this on/off behavior is introduced primarily through supervised fine-tuning (SFT) and then reinforced during general RL in their largest flagship models. For instance, after the initial reasoning model is trained via long-chain-of-thought SFT and reasoning RL, they add a “Thinking Mode Fusion” stage. During this additional SFT stage, the model sees both thinking and non-thinking examples: `/think: <think>{reasoning}</think>{answer}` `/no_think: <think></think>{answer}` Thinking is the default behavior, so /think can also be omitted. The subsequent general RL stage further reinforces this mode and format following. These `/think` and `/no_think` flags are a “soft” switch. However, the `enable_thinking=False` setting mentioned earlier, which force-adds the empty `<think></think>` in the False case, acts then as a “hard” switch. In other words, the tokenizer does not add `/no_think` to the query. It directly fills in the empty `<think></think>` section at the beginning of the assistant response. The model only sees the resulting tokens and continues directly with the answer. Anyway, this on-and-off toggle is essentially a simplified version of the reasoning effort levels in GPT-5.6 and others, which I cover in the next section. In this section, I want to provide a brief overview of how the different reasoning effort toggles may be implemented, which have been introduced in models like GPT 5 and are present in pretty much any flagship model today. Concretely, at the beginning of this article, I showed a figure from the Codex GPT 5.6 interface that lets users select multiple reasoning “effort” settings. The following subsection will illustrate how these settings may be implemented. Then, in the next section, I will go over some of the more interesting research papers related to this topic. Unfortunately, the implementation details of their effort settings are not shared by OpenAI, but there is some evidence out there that can be used for educated guesses. For instance, via their open-source gpt-oss models from last year (I wrote about them in [From GPT-2 to gpt-oss: Analyzing the Architectural Advances](https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the)), we know that OpenAI allows us to toggle the reasoning effort setting via the system prompt (”Reasoning effort: low/medium/high”) that is prepended to each prompt. As expected, the reasoning effort directly affects the response length and accuracy, as shown below. Presumably, their GPT 5 models, including the recent GPT 5.6 models, use a similar approach. By the way, note how different effort settings scale the response length in the figure above. The effort level seems directly correlated to token usage, which in turn seems correlated to accuracy. It might be possible to come up with effort settings beyond the “high” one, but I assume performance would saturate at some point. This saturation can be seen more clearly for the GPT 5.6 Sol model, which also shows that increasing reasoning budgets can become uneconomical at some point. Another good, very recent data point that shows the relationship between reasoning effort, token usage, and benchmark performance is this week’s new [open-weight Inkling release](https://sebastianraschka.com/blog/2026/inkling-architecture-benchmark-notes.html) by Thinking Machine Labs. As discussed in this section, during inference, the reasoning effort level can simply be controlled via a system prompt. (The ChatGPT UI presumably simply maps the menu choice to a system prompt.) However, this would not work for an arbitrary model and requires certain modifications to the training pipeline, which will be discussed next. While the training details are not public, neither for GPT 5.6 nor the open-source gpt-oss models, typically, the reasoning effort label is included in prompts during post-training. There are typically two ways to implement this. First, we can implement it as part of the RLVR process and apply a different length penalty when different system prompts are used. For example, a high length penalty when “Reasoning effort: low” and a mild or no penalty when “Reasoning effort: high”. Second, we can fine-tune the model after RLVR to follow different effort instructions via supervised fine-tuning (SFT). For instance, after the core RLVR stage and during SFT, the prompts in the training dataset are paired with target responses that exhibit the desired amount of reasoning. (The targets may be written by humans, generated by another model, or generated and then filtered.) During this SFT stage, the model learns the association between the effort label and the target reasoning length directly from the training examples. An RL-based implementation would instead place the effort labels and budget-aware reward inside the RLVR stage. The two approaches could also be combined, which I suspect was done for both gpt-oss and GPT 5.6 (note that effort settings in GPT 5.6 are likely just changing the system prompt for a given user query). The just-released Inkling technical report gives a small but somewhat concrete example of effort-level training. During large-scale RL, they did two things for each sample: Specified the desired effort level in the system message. Adjusted the cost assigned to each generated token. Conceptually, the reward likely looked something like this: Here, *e* is the requested effort level and λ(e) controls the token penalty. Low effort uses a larger per-token cost, encouraging shorter reasoning traces. High effort uses a smaller per-token cost, allowing the model to spend more tokens. Then, at inference time, Inkling receives a system message such as Thinking effort level: 0.8, and adjusts its token usage accordingly. The difference between Inkling and models such as gpt-oss and GPT-5.6 is that the effort label is a continuous number between 0 and 1 instead of ordinal labels such as low, medium, and high. This places Inkling’s effort-level conditioning primarily in the Reasoning RL stage, not only in the later SFT stage. They do not disclose the exact reward formula, token-cost coefficients, or whether effort conditioning was also included in SFT, though. Before moving on to the reasoning effort papers, I want to briefly connect this section back to the earlier “2.3 Inference scaling in a nutshell” section. Earlier, I separated scaling into training compute scaling and inference-time scaling. The GPT-5.6 interface provides a nice way to illustrate the difference, as shown below. On the left, selecting Luna, Terra, or Sol changes the model itself. As a rough analogy, this corresponds to training compute scaling. These are separate trained models. At a fixed training recipe and dataset size, a larger model requires more training compute. It also generally requires more compute per generated token. On the right, we keep the model fixed and only change the reasoning effort. This is inference-time scaling. The model weights stay the same, but the model is allowed to spend fewer or more tokens working on the answer. One small terminology caveat is that selecting a different model from the menu is not training scaling at that moment. The training has already happened. It is better to think of the model menu as selecting among models that were produced at different training scales. The Artificial Analysis results below show how these two axes interact in practice. Each blue curve corresponds to one model, Luna, Terra, or Sol. Moving along a curve by increasing the reasoning effort is inference scaling. Moving from one model curve to another corresponds to model scaling, which I use here as a practical proxy for training scaling. As expected, both approaches can improve the benchmark score, but they also increase the cost. More interestingly, the curves overlap. For instance, a smaller model at a higher reasoning effort can sometimes reach a similar score as a larger model at a lower reasoning effort. By the way, the x-axis in this figure shows API cost rather than raw compute. The API cost is a useful practical measure, but it also depends on the provider’s pricing and the number of generated tokens. Also, the exact shape of these curves is benchmark-specific. So, the model size and reasoning effort form two separate knobs. We can use a larger model, increase the reasoning effort, or combine both. Which combination is best depends on the desired accuracy, cost, and latency. So far, the article should give you a pretty solid understanding of how reasoning effort modes work and how they are implemented. This is a fine point to wrap the article if you are short on time. Otherwise, if you want to look into some of the nitty-gritty details of some of the recent open-weight models, please read on! **\[This section is fine to skip unless you are interested in some additional details\]** Section 5 described two possible ways to train reasoning-effort controls, namely effort-conditioned supervised fine-tuning and reinforcement learning with different token costs. Originally, I wanted to cover research articles on alternative ways to implement reasoning budgets. However, reading through most of these articles, they seemed more like proofs-of-concept that may or may not work well in practice. So, instead of covering those, I decided to pivot a bit and cover those recipes used by state-of-the-art and notable open-weight (flagship) LLMs. For these models, there is at least evidence that the methods work in practice. This leaves six examples. DeepSeek V4, Nemotron 3 Ultra, Kimi K2.5, GLM-5, Qwen3, and Inkling. They have different levels of detail in their reporting, but each contributes a useful variation. (I exclude models whose reports only show an effort setting in the user interface without explaining how that behavior was trained.) Let’s start with the [DeepSeek V4 technical report](https://www.google.com/url?q=https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/resolve/main/DeepSeek_V4.pdf?download%3Dtrue&sa=D&source=editors&ust=1784335866750314&usg=AOvVaw2n1GwYNTZHYZE3wfXDbrZJ), which describes the use of three modes: **Non-think** produces a direct response without a reasoning trace. **Think High** is the classic approach where the model places the reasoning trace between \<think> and \</think> tags. This is similar to what was discussed in the DeepSeek R1 section (section 2) at the beginning of this article. **Think Max** is the same as above but adds a special system instruction. (More on that below.) The additional system prompt instruction for Think Max starts with “Reasoning Effort: Absolute maximum with no shortcuts permitted.” At first, this sounds like a simple prompt engineering trick, but this prompt is actually backed by a different training setup. That is, each mode uses its own context window and length penalty (unfortunately, the exact length penalty implementation is not detailed in this report). Think Max receives a longer context window and a smaller length penalty than Think High, which gives it more room to continue reasoning. So, the system instruction selects a behavior that was created during post-training. Adding the same instruction to an arbitrary model would not have the same effect. Unfortunately, the public, and otherwise very detailed DeepSeek V4 report does not connect the descriptions of the reasoning mode and domain specialists in enough detail to reconstruct the exact teacher assignment. However, the report states that the final model, which supports different reasoning effort levels, was created via on-policy distillation from said teachers. To summarize, DeepSeek V4 develops the three reasoning specialists during post-training. Starting from the base model, it applies supervised fine-tuning followed by RLVR via GRPO. The RL configuration differs for each mode. In particular, each specialist uses its own context window and length penalty, while Think Max additionally receives a special system instruction. Then, including domain specialists, the different reasoning mode specialists are distilled into a single checkpoint that supports all three effort modes. The [Nemotron 3 Ultra technical report](https://www.google.com/url?q=https://research.nvidia.com/labs/nemotron/files/NVIDIA-Nemotron-3-Ultra-Technical-Report.pdf&sa=D&source=editors&ust=1784335866753580&usg=AOvVaw2ekgj61BJagCXY9Lb5Ho9k) describes three settings called reasoning-off, regular, and medium-effort, analogous to DeepSeek V4 in the previous section. Medium-effort is the cheaper reasoning mode compared with regular. NVIDIA introduces this mode during SFT using examples generated by GPT-OSS-120B in its medium-effort mode, and then further optimizes it during RLVR. About 2.5% of the RLVR prompts use medium-effort (this corresponds to length-based adjustments applied to their rewards). At inference time, all three modes are selected through the [chat template](https://www.google.com/url?q=https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B-NVFP4/blob/main/chat_template.jinja&sa=D&source=editors&ust=1784335866754576&usg=AOvVaw0MHEpfuuYzvMuv4pqOfPsL). 1\) Regular is the default and uses `enable_thinking=True`, which starts the assistant response with an opening `<think>` tag. 2\) Medium-effort uses `enable_thinking=True` together with `medium_effort=True` where the latter setting also appends {reasoning effort: efficient} to the latest user message. By the way, to further complicate things, the regular and medium-effort modes can also be combined with a separate inference-time reasoning budget. This budget acts as an external stopping mechanism. In the released implementation, the chat client asks the model to end the reasoning trace near the chosen token limit. If the model has not emitted `</think>`, the client closes the reasoning block and continues generation to produce the final answer. The learned effort mode determines how the model uses its reasoning tokens, while the budget constrains how long the reasoning trace can continue. This makes it possible to pair either mode with a tighter or looser budget depending on the desired cost and accuracy. 3\) Reasoning-off uses `enable_thinking=False`, which prefills an empty `<think></think>` block (similar to Qwen3 discussed in section 4) so that the model proceeds directly to the final response. Thus, these are chat-template controls rather than system prompts. The inference controls described above are backed by two related SFT components. The first introduces medium-effort behavior using GPT-OSS-120B traces, as discussed earlier. The second prepares the model for hard reasoning budgets. To construct this training data, the authors take regular reasoning traces, truncate them at randomly selected token budgets, and keep the original final answers. The inserted `</think>` token is masked from the SFT loss. As a result, the model sees examples where it has to move from an incomplete reasoning trace to the answer after the reasoning block has been closed externally. Medium-effort training then continues during RLVR. About 2.5% of the RL prompts use the medium-effort setting across math, STEM, and coding tasks. The report notes that the mode can be calibrated through reward hyperparameters where length-based reward adjustments provide additional control over the cost-quality trade-off. The [Kimi K2.5 technical report](https://www.google.com/url?q=https://arxiv.org/abs/2602.02276&sa=D&source=editors&ust=1784335866757827&usg=AOvVaw1ZQ2g58qlTcuh8v5EJoJo6) discusses a training method called Token Efficient RL for lower reasoning effort. (While there was a K3 announcement this week, the reasoning-effort methodology of K3 is not publicly disclosed, but it could be similar or related to K2.5.) The report mentions that a fixed token budget can make a reasoning model overfit to short solutions. That means the model becomes more concise (i.e., faster and cheaper), but it may lose the ability to benefit from additional inference-time compute and can thus perform poorly. Kimi K2.5’s method, called Toggle, alternates between two RL phases every fixed number of training iterations: 1\. In the budgeted phase, correct solutions are encouraged to stay within a problem-specific token budget. 2\. In the unconstrained phase, the usual maximum generation length is restored so that the model can still learn from longer solutions. For each problem, the budget is estimated from a selected percentile of response lengths among correct rollouts in RLVR. The budget constraint is then only activated once the mean accuracy on that problem exceeds a threshold. This avoids forcing the model to shorten its reasoning before it can solve the problem reliably. The report evaluates Toggle on K2 Thinking and finds that it reduces generated tokens by about 25 to 30% with little change in benchmark performance. The same behavior also transfers from math and coding RL tasks to GPQA and MMLU-Pro. Toggle supplies a concrete flagship-model recipe for training a more token-efficient reasoning policy while preserving its ability to scale at test time. Toggle operates entirely during RL training. Both alternating phases update the same policy (i.e., LLM), and the final (unified) checkpoint has no budgeted-versus-unconstrained selector. At inference, the resulting model then runs in thinking mode by default. Interestingly, though, Kimi K2.5 itself exposes a separate binary choice between thinking and instant modes in some APIs I checked (like vLLM or SGLang). Thinking mode is enabled by default. Instant mode disables the reasoning trace through thinking: `{”type”: “disabled”}` in the official API or `chat_template_kwargs={”thinking”: False}` when serving the model through vLLM or SGLang. However, these settings are separate from Toggle. Also, the official Kimi report does not provide a separate training recipe for instant mode. However, K2.5’s SFT data were generated using both the earlier K2 model, which produces direct responses without long reasoning, and K2 Thinking, which produces extended reasoning traces. This likely exposes the unified checkpoint to both response formats similar to what’s done in Nemotron 3 above. At inference time, the chat template selects between them by prefilling either an open \<think> tag for thinking mode or an empty `<think></think>` block for instant mode. But again, unfortunately, the report does not disclose the exact data mixture or whether additional mode-specific RL was used. The newer Kimi K3 provides a more direct inference-time effort interface. The [current Kimi Code documentation](https://www.google.com/url?q=https://www.kimi.com/code/docs/en/kimi-code/models.html&sa=D&source=editors&ust=1784335866762281&usg=AOvVaw0CXvoqLeEwnu6kmnN71eNY) lists three settings called low, high, and max, with max as the default. These are passed through the `reasoning_effort` parameter. However, Moonshot has not yet explained how the three effort levels were created during training. Its [launch post](https://www.google.com/url?q=https://www.kimi.com/blog/kimi-k3&sa=D&source=editors&ust=1784335866762950&usg=AOvVaw1kAEhIZfnu-LTk8yd5xgal) says that these details will appear in a future K3 technical report, so I’ll stay tuned for that. Based on the new [Kimi K3 technical report](https://pdfs.assets.alphaxiv.org/2607.kimi-k3-reportv1.pdf) (released after I published this article), Kimi K3 has three reasoning modes: low-, high-, and max-effort. For each training problem, the researchers first estimate an initial token budget. On a simple verifiable task, a correct response would normally receive a reward of +1 and an incorrect response 0. But here, if the response exceeds the selected token budget, its reward is instead set to -1. This gives the model a strong incentive to stay within the budget. (The exact reward setup is different for non-verifiable and agentic tasks, and Kimi also uses learned reward models and pairwise comparisons.) To have Kimi K3 support the three reasoning effort modes, the training looked as follows. First, the researchers start by training a max-effort version (“specialist”) with a relatively generous budget. They then lower the budget to train high- and low-effort versions. This process is repeated for three domains: general tasks, general agents, and coding agents. And each domain gets one specialist for each effort level. So, for example, one specialist learns low-effort coding behavior, while another learns max-effort agent behavior. This gives nine specialist models in total. The behaviors of these nine specialist models are then combined into a single Kimi K3 model using multi-teacher on-policy distillation. At inference time, a natural-language `thinking-effort` instruction in the prompt can then be used to tell the model which effort level to use. The [GLM-5 technical report](https://www.google.com/url?q=https://arxiv.org/abs/2602.15763&sa=D&source=editors&ust=1784335866763311&usg=AOvVaw2B0_xQjtDj2xC_zTXgUmxa) extends the binary on/off thinking switch introduced with GLM-4.5 to multi-turn and tool-using scenarios. It describes three related behaviors (rather than three effort levels): **Interleaved thinking:** this inserts a reasoning block before each response and tool call. **Preserved thinking:** here, the chat retains earlier reasoning blocks across turns so that the model can reuse them later. **Turn-level thinking:** this enables or disables reasoning separately for each request in a conversation. At inference time, turn-level thinking is the actual on-off switch. In the [Z.ai API](https://www.google.com/url?q=https://docs.z.ai/guides/capabilities/thinking-mode&sa=D&source=editors&ust=1784335866764242&usg=AOvVaw1l0q9ZQ6McPYsOnvRmKeNL), thinking is enabled by default and can be disabled for an individual request with thinking: `{”type”: “disabled”}`. The hosted implementation is not disclosed but the open [GLM-5 chat template](https://www.google.com/url?q=https://huggingface.co/zai-org/GLM-5/blob/main/chat_template.jinja&sa=D&source=editors&ust=1784335866764572&usg=AOvVaw3Be1R4iJTIh-fDCVr1CbF6) shows the equivalent mechanism when self-hosting with Transformers, vLLM, or SGLang. It starts the assistant response with `<|assistant|><think>` when thinking is enabled and `<|assistant|></think>` when it is disabled. The latter closes the reasoning block immediately, so generation proceeds directly to the final answer. The report says that these behaviors are introduced during multi-task SFT together with an updated chat template. After SFT, GLM-5 goes through reasoning RL, agentic RL, and general RL. And a final on-policy distillation step uses checkpoints from the preceding stages as teachers. This helps the final model recover capabilities that may have weakened during the sequential RL stages. Qwen3 was already covered in Section 4, so I will only summarize the parts that matter for this comparison. According to the [Qwen3 technical report](https://www.google.com/url?q=https://arxiv.org/abs/2505.09388&sa=D&source=editors&ust=1784335866765752&usg=AOvVaw3VLUySiiox-X0Vw2QPL80b), its post-training pipeline has four stages. These are long-chain-of-thought SFT, reasoning RL, Thinking Mode Fusion, and general RL. Thinking Mode Fusion is the key stage for the effort on-off switch. Here the model is trained via SFT on a mixture of thinking and non-thinking examples. The /think examples contain a reasoning trace, while `/no_think` examples begin with an empty `<think></think>` block that is accompanied by a short answer. The following general RL stage reinforces instruction and format following for both behaviors. Qwen3 also supports a hard thinking budget. At the requested threshold, the reasoning span is stopped and a stop-thinking instruction is inserted before the model continues with its final answer. The report says that this partial-reasoning behavior was not trained explicitly. It emerged after Thinking Mode Fusion. This gives Qwen3 a learned on-off switch plus an inference-time budget. It is similar but simpler than the DeepSeek V4 and Nemotron recipes. Inkling was already discussed in Section 5.3. The short version is that its [technical report](https://www.google.com/url?q=https://thinkingmachines.ai/news/introducing-inkling/&sa=D&source=editors&ust=1784335866767327&usg=AOvVaw2Eich3Nl1VH0sM1fJhcs-7) mentions that they use continuous effort conditioning (values between 0.0 and 1.0) rather than fixed effort labels. After a relatively small initial SFT stage, most of Inkling’s post-training comes from asynchronous RL with more than 30 million rollouts. The desired effort is included in the system message, and the token length penalty is adjusted according to that value during RL. As previously discussed, a higher token cost encourages a shorter response. A lower token cost gives the model more room to reason. The table below summarizes what is actually documented in the six technical reports. So, looking at the six different open-weight models, they have a shared framework. First, they introduce effort mode control through SFT and the chat template. Qwen3 explicitly mixes thinking and non-thinking examples, while GLM-5 adds interleaved, preserved, and turn-level thinking patterns. The second shared component is a mode-conditioned RL stage, where context windows and length penalties change with the requested effort. DeepSeek V4, Nemotron 3 Ultra, and Inkling use this approach. A third ingredient improves robustness under explicit budgets. Nemotron trains on randomly truncated traces, Qwen3 can continue from a forcibly stopped reasoning span, and Kimi alternates budgeted with unconstrained RL. These methods help preserve answer quality when the available reasoning length changes and is even cut short. The open-weight examples in this article implement reasoning effort through several different mechanisms. Similar labels can be backed by separate specialists, mixed SFT data, mode-conditioned rewards, hard token budgets, or combinations of these methods. It is difficult to say which approach is best. The models differ in their base checkpoints, training data, post-training compute, benchmarks, and serving goals. Their reports also omit many details needed for a controlled comparison. (Also, there may not be a one-size-fits-all, and a method that works well for an interactive assistant may be a poor fit for a long-running coding agent.) The holy grail is of course automatic effort selection. We saw this a while back with GPT 5’s Auto mode. It’s a tricky problem to solve, and in the end, the implementation was probably more miss than hit, which is why it got removed from the UI (at least, I can’t find it anymore). **In the near future, I think reasoning effort will remain an explicit model input, which will most often be delivered through the system prompt. However agent wrapper/harness around the LLM, or an internal router may increasingly infer the appropriate mode and budget from the task state and available resources automatically (while of course still allowing a user override).** I still hope that effort selection will become more automatic. Similar to GPT 5’s auto mode, a cheap model or router could choose the mode from the request, tool state, and remaining time or token budget while still allowing a user override. The override is useful if you want to optimize for latency or cost, or maximum performance. I realize that this was a long article, and it was perhaps not the flashiest topic. But I thought that given all the talk about LLMs, reasoning models, and agents, a look at reasoning models was something not covered before, and I hope it was a unique and somewhat useful overview! If you want a hands-on implementation of the core training methods behind reasoning models, my [Build a Reasoning Model (From Scratch)](https://sebastianraschka.com/books/#build-a-reasoning-model-from-scratch) book walks through reinforcement learning with verifiable rewards and inference-time scaling step by step, with code. This article focused on how a trained reasoning model can support different effort modes. The book takes a step back and shows how to turn a conventional LLM into a reasoning model in the first place. It is a sequel to [Build a Large Language Model (From Scratch)](https://sebastianraschka.com/books/#build-a-large-language-model-from-scratch) and starts where that book leaves off. The print edition has now started shipping If you liked my previous [Build a Large Language Model (From Scratch)](https://amzn.to/4fqvn0D) book, this is essentially a sequel implementing inference-time scaling techniques and reinforcement learning algorithms from scratch. And if you want to support future long-form articles like this one, consider [becoming a paid subscriber](https://magazine.sebastianraschka.com/subscribe). It helps me keep writing these independent deep dives and sharing the accompanying code, figures, and experiments.