{"slug": "controlling-reasoning-effort-in-llms", "title": "Controlling Reasoning Effort in LLMs", "summary": "OpenAI released GPT-5.6 with multiple reasoning-effort settings, following the trend of reasoning models popularized by OpenAI's o1 and DeepSeek-R1. Sebastian Raschka explains how LLMs learn low-, medium-, and high-effort reasoning modes, covering training via reinforcement learning with verifiable rewards and inference scaling.", "body_md": "# Controlling Reasoning Effort in LLMs\n\n### How LLMs Learn Low-, Medium-, and High-Effort Reasoning Modes\n\nIt 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.\n\nLast week, OpenAI released the GPT-5.6 model family. It comes in three sizes, each with roughly five or six reasoning-effort settings.\n\nSo yes, reasoning models are here to stay. They have become a standard part of modern model releases.\n\nIn 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).\n\nThese 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.\n\nNo worries, this article can be read as a standalone article. However, the aforementioned resources may be interesting and useful.\n\n# 1. A brief definition of reasoning models\n\nWhen 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.\n\nSimilarly, 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.\n\nIt’s probably easiest to explain this by showing an example.\n\n# 2. A brief overview of training and inference scaling reasoning models\n\nThere are essentially two ways to improve (reasoning) task performance: training scaling and inference scaling.\n\nLet’s briefly talk about training first.\n\n## 2.1 Training reasoning models\n\nIn 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`\n\nand `1=correct`\n\n) 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.\n\nNotably, 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.)\n\n## 2.2 “Aha” moments\n\nAnyway, 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.\n\nBy 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).\n\nOne 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).\n\nFor 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.\n\nWhile 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.\n\nBy 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.\n\n## 2.3 Inference scaling in a nutshell\n\nNext 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.\n\nThis is a whole topic by itself, and you could read through my The State of LLM Reasoning Model Inference for a more detailed rundown:\n\nI will try to summarize what’s most essential to mention as background info below.\n\nFirst, 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.\n\nSecond, we can further adjust this output length via reasoning effort levels, but more on that later.\n\nThird, 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.\n\nThis 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.\n\nBut again, I will refer to my other article, The State of LLM Reasoning Model Inference for an overview of other techniques:\n\n# 3. Think tokens\n\nYou may have seen the `<think></think>`\n\ntokens in the earlier “Aha moments” figure. I also included the corresponding figure below so you don’t have to scroll all the way up.\n\nThese `<think>`\n\nand `</think>`\n\ntags 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.\n\nThe purpose of these `<think>`\n\ntags 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.)\n\nThe point here is that the `<think>`\n\ntokens are not giving the model the ability to “think” or reason or reason better. One could train the same models without such `<think>`\n\ntokens and reach similar benchmark performance.\n\nThere is also nothing special about the literal strings `<think>`\n\nand `</think>`\n\n. Another pair of delimiters could serve the same purpose.\n\nBy 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.\n\nIn DeepSeek-R1, for example, the overall reward was calculated as\n\n`R_total = R_accuracy + R_format`\n\nwhere the format reward was a simple rule-based check that encouraged the model to place its reasoning inside:\n\n`<think>`\n\nreasoning trace\n\n`</think>`\n\n.\n\n# 4. Reasoning mode on and off switches\n\nThe 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.\n\nNo 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.\n\nLater 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.\n\nNote: Some model developers call this “thinking mode,” while others call it “reasoning mode.” Both terms refer to the same behavior.\n\nIn Qwen3, this is handled via the tokenizer using `enable_thinking=True`\n\nor `enable_thinking=False`\n\n. Under the hood, setting `enable_thinking=False`\n\nessentially adds an empty `<think></think>`\n\nsection to the beginning of the assistant response to turn off Qwen3’s reasoning (”thinking”) mode.\n\nHow is this implemented during training, such that the model supports this toggle during inference time, as shown in the figure above?\n\nIn 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.\n\nFor 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:\n\n`/think: <think>{reasoning}</think>{answer}`\n\n`/no_think: <think></think>{answer}`\n\nThinking is the default behavior, so /think can also be omitted. The subsequent general RL stage further reinforces this mode and format following.\n\nThese `/think`\n\nand `/no_think`\n\nflags are a “soft” switch. However, the `enable_thinking=False`\n\nsetting mentioned earlier, which force-adds the empty `<think></think>`\n\nin the False case, acts then as a “hard” switch.\n\nIn other words, the tokenizer does not add `/no_think`\n\nto the query. It directly fills in the empty `<think></think>`\n\nsection at the beginning of the assistant response. The model only sees the resulting tokens and continues directly with the answer.\n\nAnyway, 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.\n\n# 5. How “reasoning effort” settings work\n\nIn 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.\n\nConcretely, 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.\n\nThe 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.\n\n## 5.1 Reasoning effort and response length and quality\n\nUnfortunately, 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.\n\nFor 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.\n\nAs expected, the reasoning effort directly affects the response length and accuracy, as shown below.\n\nPresumably, their GPT 5 models, including the recent GPT 5.6 models, use a similar approach.\n\nBy 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.\n\nAnother 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.\n\nAs 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.\n\n## 5.2 Possible effort level implementations\n\nWhile 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.\n\nThere are typically two ways to implement this.\n\nFirst, 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”.\n\nSecond, we can fine-tune the model after RLVR to follow different effort instructions via supervised fine-tuning (SFT).\n\nFor 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.)\n\nDuring 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).\n\n## 5.3 Inkling case study\n\nThe just-released Inkling technical report gives a small but somewhat concrete example of effort-level training.\n\nDuring large-scale RL, they did two things for each sample:\n\nSpecified the desired effort level in the system message.\n\nAdjusted the cost assigned to each generated token.\n\nConceptually, the reward likely looked something like this:\n\nHere, *e* is the requested effort level and λ(e) controls the token penalty.\n\nLow effort uses a larger per-token cost, encouraging shorter reasoning traces.\n\nHigh effort uses a smaller per-token cost, allowing the model to spend more tokens.\n\nThen, 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.\n\nThis places Inkling’s effort-level conditioning primarily in the Reasoning RL stage, not only in the later SFT stage.\n\nThey do not disclose the exact reward formula, token-cost coefficients, or whether effort conditioning was also included in SFT, though.\n\n## 5.4 A short note about inference scaling versus training scaling\n\nBefore 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.\n\nEarlier, 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.\n\nOn 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.\n\nOn 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.\n\nOne 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.\n\nThe Artificial Analysis results below show how these two axes interact in practice.\n\nEach 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.\n\nAs 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.\n\nBy 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.\n\nSo, 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.\n\nSo 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!\n\n# 6. Bonus: Different ways to implement reasoning efforts (in flagship open-weight LLMs)\n\n**[This section is fine to skip unless you are interested in some additional details]**\n\nSection 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.\n\nSo, 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.\n\nThis 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.)\n\n## 6.1 DeepSeek V4 trains separate effort specialists\n\nLet’s start with the[ ](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=1784335866750173&usg=AOvVaw1sM7dNkExL5WhfZEIXpAvQ)[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:\n\n**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.)\n\nThe additional system prompt instruction for Think Max starts with “Reasoning Effort: Absolute maximum with no shortcuts permitted.”\n\nAt 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.\n\nSo, 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.\n\nUnfortunately, 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.\n\nHowever, the report states that the final model, which supports different reasoning effort levels, was created via on-policy distillation from said teachers.\n\nTo 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.\n\nThen, including domain specialists, the different reasoning mode specialists are distilled into a single checkpoint that supports all three effort modes.\n\n## 6.2 Nemotron 3 Ultra combines learned modes with hard budgets\n\nThe[ ](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=1784335866753450&usg=AOvVaw3oh5C8PW7Ulb5MwqZtlQEi)[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).\n\n### 6.2.1 Using Nemotron reasoning budgets during inference\n\nAt inference time, all three modes are selected through the[ ](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=1784335866754470&usg=AOvVaw0XFGRKmz0hfXdjFRWgkMrr)[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).\n\n1) Regular is the default and uses `enable_thinking=True`\n\n, which starts the assistant response with an opening `<think>`\n\ntag.\n\n2) Medium-effort uses `enable_thinking=True`\n\ntogether with `medium_effort=True`\n\nwhere the latter setting also appends {reasoning effort: efficient} to the latest user message.\n\nBy 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>`\n\n, 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.\n\n3) Reasoning-off uses `enable_thinking=False`\n\n, which prefills an empty `<think></think>`\n\nblock (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.\n\n### 6.2.2 Reasoning budget-aware training in Nemotron\n\nThe 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.\n\nTo 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>`\n\ntoken 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.\n\nMedium-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.\n\n## 6.3 Kimi K2.5 alternates budgeted and unconstrained RL\n\nThe[ 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.)\n\n### 6.3.1 Kimi’s Toggle method\n\nThe 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.\n\nKimi K2.5’s method, called Toggle, alternates between two RL phases every fixed number of training iterations:\n\n1. In the budgeted phase, correct solutions are encouraged to stay within a problem-specific token budget.\n\n2. In the unconstrained phase, the usual maximum generation length is restored so that the model can still learn from longer solutions.\n\nFor 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.\n\nThe 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.\n\nToggle supplies a concrete flagship-model recipe for training a more token-efficient reasoning policy while preserving its ability to scale at test time.\n\n### 6.3.2 What Toggle changes at inference\n\nToggle 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.\n\nInterestingly, 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”}`\n\nin the official API or `chat_template_kwargs={”thinking”: False} `\n\nwhen serving the model through vLLM or SGLang. However, these settings are separate from Toggle.\n\nAlso, 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>`\n\nblock for instant mode. But again, unfortunately, the report does not disclose the exact data mixture or whether additional mode-specific RL was used.\n\nThe newer Kimi K3 provides a more direct inference-time effort interface. The[ ](https://www.google.com/url?q=https://www.kimi.com/code/docs/en/kimi-code/models.html&sa=D&source=editors&ust=1784335866762156&usg=AOvVaw0EewNuRaZ6NqrvFr4tilqU)[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`\n\nparameter. However, Moonshot has not yet explained how the three effort levels were created during training. Its[ ](https://www.google.com/url?q=https://www.kimi.com/blog/kimi-k3&sa=D&source=editors&ust=1784335866762887&usg=AOvVaw246dne6tuhstEqEaYkFxxd)[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.\n\n## 6.4 GLM-5 introduces turn-level and interleaved thinking through SFT\n\nThe[ ](https://www.google.com/url?q=https://arxiv.org/abs/2602.15763&sa=D&source=editors&ust=1784335866763244&usg=AOvVaw0AfAPDCBRwHIqgVtzEIlWl)[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):\n\n**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.\n\nAt inference time, turn-level thinking is the actual on-off switch. In the[ ](https://www.google.com/url?q=https://docs.z.ai/guides/capabilities/thinking-mode&sa=D&source=editors&ust=1784335866764165&usg=AOvVaw28rIdSlyX2unhGK8sZfyY_)[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”}`\n\n. The hosted implementation is not disclosed but the open[ ](https://www.google.com/url?q=https://huggingface.co/zai-org/GLM-5/blob/main/chat_template.jinja&sa=D&source=editors&ust=1784335866764489&usg=AOvVaw3TIxTeBC2mkhy4UZ8sb1gs)[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.\n\nIt starts the assistant response with `<|assistant|><think>`\n\nwhen thinking is enabled and `<|assistant|></think>`\n\nwhen it is disabled. The latter closes the reasoning block immediately, so generation proceeds directly to the final answer.\n\nThe report says that these behaviors are introduced during multi-task SFT together with an updated chat template.\n\nAfter 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.\n\n# 6.5 Qwen3 uses mode fusion and inference-time truncation\n\nQwen3 was already covered in Section 4, so I will only summarize the parts that matter for this comparison. According to the[ ](https://www.google.com/url?q=https://arxiv.org/abs/2505.09388&sa=D&source=editors&ust=1784335866765677&usg=AOvVaw2w7tIIoTJq1rjhrQwKsUnn)[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.\n\nThinking 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`\n\nexamples begin with an empty `<think></think>`\n\nblock that is accompanied by a short answer. The following general RL stage reinforces instruction and format following for both behaviors.\n\nQwen3 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.\n\nThis gives Qwen3 a learned on-off switch plus an inference-time budget. It is similar but simpler than the DeepSeek V4 and Nemotron recipes.\n\n# 6.6 Inkling conditions RL on a continuous effort value\n\nInkling was already discussed in Section 5.3. The short version is that its[ ](https://www.google.com/url?q=https://thinkingmachines.ai/news/introducing-inkling/&sa=D&source=editors&ust=1784335866767248&usg=AOvVaw1KRrhm4wZYltLd7hgHdIBQ)[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.\n\nAfter 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.\n\n# 6.7 Overview of the known recipes\n\nThe table below summarizes what is actually documented in the six technical reports.\n\nSo, 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.\n\nThe 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.\n\nA 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.\n\n# 7. Conclusion\n\nThe 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.\n\nIt 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.)\n\nThe 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).\n\nI 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.\n\nI 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!\n\n# Further resources\n\nIf 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.\n\nThis 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.\n\nThe print edition has now started shipping\n\nIf 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.\n\nAnd 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.", "url": "https://wpnews.pro/news/controlling-reasoning-effort-in-llms", "canonical_source": "https://magazine.sebastianraschka.com/p/controlling-reasoning-effort-in-llms", "published_at": "2026-07-18 11:16:09+00:00", "updated_at": "2026-07-18 11:32:57.358005+00:00", "lang": "en", "topics": ["large-language-models", "artificial-intelligence", "ai-research", "ai-products"], "entities": ["OpenAI", "DeepSeek", "GPT-5.6", "DeepSeek-R1", "Sebastian Raschka"], "alternates": {"html": "https://wpnews.pro/news/controlling-reasoning-effort-in-llms", "markdown": "https://wpnews.pro/news/controlling-reasoning-effort-in-llms.md", "text": "https://wpnews.pro/news/controlling-reasoning-effort-in-llms.txt", "jsonld": "https://wpnews.pro/news/controlling-reasoning-effort-in-llms.jsonld"}}