Open the model menu in almost any AI tool and there is a second menu beside it: effort settings are now in "pretty much any flagship model."[1] When OpenAI shipped GPT-5.6 in July 2026, it came with six reasoning-effort settings, from Light to Ultra, and the selector warns that the top one "consumes usage limits faster."[1] Kimi Code, Moonshot's coding tool for its K3 model, offers low, high and max, with max as the default.[1] It is easy to treat that menu as a quality dial and leave it where it was. It is a cost lever: each step up tells the model to spend more tokens thinking before it answers, and you pay for every one of them.
What the effort setting actually changes.
Reasoning effort is the setting that tells a reasoning model how many tokens it may spend thinking before it answers: higher effort means a longer trace, a bigger bill and, up to a point, better accuracy. The trace is the model's working (the "thinking"), written out before its final answer. In OpenAI's open-weight gpt-oss models, the one place OpenAI has shown the mechanism, the setting is a line in the system message ("Reasoning effort: low", "medium" or "high") placed in front of your prompt, sent to the same model.[1][3] Raschka's reading of the gpt-oss model card is that higher effort means longer responses and higher accuracy, and he presumes GPT-5 and GPT-5.6 work the same way.[1]
The weights stay the same when you move the slider. The token count goes up, and the wait and the bill follow it: the same request on a higher setting is longer, slower and more expensive. Whether the answer also gets better depends on the task.
Effort is trained in, not typed in.
Because the control is a line of text, it is tempting to think any model will obey it. Raschka is direct on this: pasting "Reasoning effort: low" into the system prompt of an arbitrary model does nothing reliable. The line selects a behavior that post-training put there.[1] He surveys the six open-weight flagships whose reports say how they did it (DeepSeek V4, Nemotron 3 Ultra, Kimi K2.5, GLM-5, Qwen3 and Inkling) and finds three shared ingredients.[1][2] If you only need the buying decision, skip to which setting for which job.
- The on/off switch comes from mixed training examples.
Qwen3 is the clean case: after its reasoning training, a fine-tuning stage mixes examples with a thinking trace and examples with an empty one followed by a short answer. At run time, "thinking off" just pre-fills the empty trace, and the model goes straight to the answer.
- The levels come from what thinking costs during training.
In reinforcement learning, the reward subtracts a penalty per token, and the penalty depends on the requested effort. Low effort sets a heavy penalty, so the model learns to be brief; high effort sets a light one. DeepSeek V4 goes further and trains a separate specialist per mode (Non-think, Think High, Think Max, the last with a longer context window, a smaller length penalty and its own system instruction), then distills them into one model.
- Hard budgets are trained separately.
Nemotron fine-tunes on traces cut off at random lengths so the model can still land an answer when its thinking is stopped early. Qwen3 picked up the same stop-and-answer behavior without being trained for it. Kimi alternates budgeted and unbudgeted training rounds (more on that below).
For an operator, two things follow. If you self-host an open model, use the control its documentation names (a chat-template flag, an API parameter, a budget setting), not a sentence you wrote yourself. And the same word means different things across vendors: "high" on one model and "high" on another were produced by different recipes and bought with different budgets. Compare settings by what they cost and what they deliver on your tasks, not by their names. Our note on Kimi K3's report shows one lab's ladder in detail: a token budget per problem, with any run that blows past it scored as a failure even when it solved the problem.
More effort, smaller gains.
The setting buys accuracy with tokens, and the exchange rate gets worse as you climb. Raschka shows it three ways. In the gpt-oss model card, higher effort means longer responses and higher scores.[1][3] In Thinking Machines' Inkling release, which exposes effort as a continuous number, raising it generally raises both tokens and scores, "with diminishing or uneven gains at higher effort."[1] And on the Artificial Analysis Coding Agent Index v1.1 (a composite of three coding-agent benchmarks), GPT-5.6 Sol's cost climbs with each setting while its score flattens near the top.[1][4] His summary: increasing reasoning budgets "can become uneconomical at some point."[1]
The top of the menu is where the money goes fastest. Ultra on GPT-5.6, per Raschka's caption, uses a similar effort level to Max but speeds the work up with four subagents. He expects its scores to land near Max's; benchmark numbers for it were not yet available.[1] If that holds, Ultra buys speed rather than score, and the selector itself warns that it consumes usage limits faster.
Two knobs: model size and effort.
Raschka's most useful frame for a buyer is that the model menu and the effort menu are two separate ways to spend money.[1] Picking Luna, Terra or Sol (GPT-5.6's three sizes) picks a different trained model, and a larger one generally costs more to run per token. Moving the effort setting keeps the model and changes how many tokens it spends. On the Artificial Analysis curves he plots, each model traces its own line as effort rises, and the lines overlap: a smaller model at a higher effort can sometimes reach the score of a larger model at a lower effort, at a different cost and speed.[1][4]
That makes the effort setting a routing decision. If a small model on high does the job as well as a large one on low, pick whichever is cheaper per finished task at the speed you need: a long trace on a cheap model is slower, while a short trace on an expensive model costs more per token. Raschka adds that the x-axis is API cost, which depends on the provider's pricing and the number of generated tokens.[1] In our reading, that means the answer shifts whenever a price list does.
A lot of the extra thinking was waste.
The clearest evidence that reasoning traces carry slack comes from Moonshot's Kimi K2.5 report.[2] It describes a training method called Toggle, which alternates two kinds of reinforcement-learning rounds. In budgeted rounds, a correct answer is pushed to fit a per-problem token budget, set from the lengths of earlier correct answers and switched on only once the model solves that problem reliably. In unbudgeted rounds, the full length is restored so the model keeps the ability to think long when it needs to. Tested on the earlier K2 Thinking model, the report says Toggle cut generated tokens by about 25 to 30% with little change in benchmark performance.[1][2]
For an operator, the size of the cut matters more than the lab. A quarter or more of the model's thinking tokens came out and the scores barely moved, so a lot of those tokens were not buying anything. That does not tell you where your own work sits on the effort menu, but it is a reason to test one step down before assuming the top setting is earning its cost.
Which setting for which job.
Raschka's closing bet is automatic effort selection: a cheap router that picks the setting from the request, the tool state and the remaining budget, with a manual override.[1] OpenAI tried this with GPT-5's Auto mode, and he notes it seems to have vanished from the interface. Until routers are good, the choice is yours. These are the starting points we use, and they are only that: our practice, not a vendor's guidance, and every one should be tested on your own tasks.
| the job | start at | why |
|---|---|---|
| sorting, tagging, pulling fields from a clean form | off or lowest | The answer is short and checkable; a long trace adds cost and delay, not accuracy. |
| drafting a reply from a template or known facts | low to medium | Some planning helps tone and order; the facts come from what you hand it, not from thinking longer. |
| multi-step work with a check at the end (code with tests, a reconciliation) | high, then try one lower | This is where effort pays. Because the result can be checked, you can see whether the setting below holds up. |
| long unattended agent runs | medium plus a hard budget | Cost compounds per step; on agent work a budget can count tool calls too, not only thinking. |
| the top setting (Max, Ultra) | by exception | Diminishing returns, and the most expensive tokens on the menu. Use it for the hard case you have already seen fail one level down. |
One check worth doing today: look at what each tool you pay for defaults to. If the default is the top setting, as it is in Kimi Code per its documentation, every routine request spends the most thinking tokens on the menu, and on a flat plan burns your usage limit fastest.[1]
Price it on your own work.
Benchmarks show the shape of the curve. Finding where your own work sits on it takes a test, and the test is cheap: an afternoon.
- Pick 20 real tasks with a known good outcome.
From your own queue: tickets you already resolved, invoices you already reconciled, code changes that already passed review.
- Run them at your current setting and one step below.
Add one step above for the tasks that failed. Same model, same prompt, same tools; change only the effort.
- Log tokens and a pass or fail for each run.
Pass means you would have used the output as is. Your provider's usage report or API response gives the token count per call; that is your cost.
→ the number to compare: cost per accepted output, not cost per call - Drop a step wherever the pass rate holds.
Then rerun the test when the vendor ships a new model or changes its prices, because both move the curve.
If you already trace cost per agent step, as in our per-step cost trace, the effort setting is one more column in it. For agents that loop, pair the setting with a hard stop; our planner that knows when to give up is the same idea one level up, applied across the steps of an agent rather than inside one answer.
What this does not claim.
Vendor numbers, relayed. The Toggle result, the gpt-oss scaling and the Inkling sweep are each lab's claims about its own model, read by Raschka. We cite them as reported and have not reproduced them.
OpenAI's method is a reconstruction. OpenAI has not published how GPT-5.6's settings are trained. Raschka labels his own diagram of it "a possible implementation, not a confirmed description," and the parts of this note about GPT-5.6 rest on its interface and on benchmark results, not on its training.
Benchmarks are not your work. The Artificial Analysis curves are coding-agent benchmarks, and Raschka notes their exact shape is benchmark-specific. The two-knob figure above is a schematic of that shape, with no data plotted.
The routing table is ours. It is a starting point from how we set our own tools, not a measurement. The point of the four-step test is to replace it with your own numbers.
Not sure what your AI tools are spending on thinking? Send us a month of usage exports (with customer data removed) through the contact form and we will tell you, in writing, which settings look worth testing one step lower. Cost tuning is part of our assistants and agents work.