Setting reasoning_effort to low on a local model through LM Studio produced 4,096 tokens of reasoning. Setting it to high produced 1,556. Same model, same board, same instruction, same 8,192 token cap, on a studio test machine.
That is the opposite of what the parameter name promises. The LM Studio reasoning effort setting is the first of several results in this piece that say the same thing: the knobs on a local reasoning model do not do what their labels say, and the only way to know what one does is to measure it on your own stack.
Does LM Studio reasoning effort change how much a model thinks
The test board was one frame of an ARC-AGI-3 game, downsampled to 16 by 16 and sent as hex rows, 343 input tokens, with four legal actions and an instruction to pick one. Every run below used gemma-4-31b-qat through LM Studio’s OpenAI compatible endpoint with a cap of 8,192 output tokens, high enough that nothing was truncated. Every run answered ACTION1.
reasoning_effort | Reasoning tokens | Time |
|---|---|---|
| not set | 2,136 | 191.9s |
low | 4,096 | 361.7s |
medium | 2,774 | 244.6s |
high | 1,556 | 135.5s |
Reasoning tokens per setting, one run each. Black: low effort, the outlier. Yellow: the JSON schema, the only setting clearly outside the noise in the useful direction.
Two things stand out. The order is inverted: low thought the most and high the least. And low came out at exactly 4,096, a power of two, which looks less like a model choosing to stop and more like a budget being applied somewhere between the parameter and the weights. That is a guess, and it is flagged as one. LM Studio’s page on its OpenAI compatible endpoints does not mention reasoning_effort at all, so whatever the server does with the field is undocumented, and this is one model on one build.
What is not a guess is the practical result. The parameter was accepted without error and it changed the run, so it is doing something. It is not doing the thing its name says.
Does temperature change the reasoning length
Same board, same cap, reasoning_effort left unset:
temperature | Reasoning tokens | Time |
|---|---|---|
| 0.0 | 2,241 | 197.2s |
| 0.2 | 2,136 | 191.9s |
| 0.7 | 1,484 | 131.5s |
| 1.0 | 1,948 | 171.0s |
No monotonic trend, and every setting picked the same action. Then two more runs at 0.2 with a byte identical prompt, made later in the same session to test caching, gave the real noise floor: the first thought for 1,762 tokens and answered ACTION1 in 161 seconds; the second thought for 8,076 tokens, answered ACTION2, and took 721 seconds. Same bytes in, and a spread of four and a half times in both thinking and time, with a different move at the end of it. Every row in the temperature table sits inside that spread. Temperature changes which reasoning path the model takes; on this evidence nothing about the length of the path is predictable from one run.
The lesson is about method as much as about temperature. A single run per setting cannot separate a setting from chance when chance alone spans 1,762 to 8,076 tokens, and most of the differences people report between sampling settings on local models are single runs. That caveat applies to every table in this piece, including the ones that follow.
What a JSON schema does to the reasoning phase
This is the setting that produced the largest drop. With response_format set to a JSON schema whose only legal output is an object with an action field drawn from the four action names, the model thought for 1,078 tokens, answered {"action": "ACTION1"}, and finished in 94.7 seconds. That is half the unconstrained run and the lowest count in the session. It is also one run, and identical prompts varied by more than that, so it is a lead to test rather than a result to bank.
It also failed to help at all in an earlier test, and the two results together are the useful finding. When the cap was 4,096 and the board was the full 64 by 64 frame, the schema run was truncated at 4,093 reasoning tokens with an empty answer, exactly like the unconstrained run. The schema constrains the visible answer, and the visible answer is produced after the reasoning. If the reasoning hits the cap, there is nothing for the schema to constrain.
So a schema is worth setting, for two reasons that are separate. It guarantees a parseable answer when an answer arrives, which LM Studio’s structured output documents as the purpose. And, on this model and this task, it also shortened the thinking, which the documentation does not promise and which is worth checking on yours.
What tool calling does to the reasoning phase
The last variant replaced the free text answer with a tool. One function, press, taking an action parameter with the same four allowed values, and tool_choice set to required. The model thought for 1,497 tokens, returned no content, and made one call: press({"action": "ACTION1"}), with finish_reason reported as tool_calls.
That sits between the schema and the plain run, and inside the noise band of the plain run, so no claim about tool calling shortening the thinking survives. What it does change is the shape of the response. The answer arrives in message.tool_calls[0].function.arguments as a JSON string, message.content is empty, and a client that reads content and sees nothing will conclude the model failed. The same empty content field means something entirely different when the finish reason is length, and a harness has to read the finish reason before it decides which case it is in.
The input also grew: 404 prompt tokens against 343, the tool definition’s cost. For one tool that is nothing. For an agent shipping 28 tool definitions it is most of the request.
Which LM Studio knob to reach for first
In order of what the measurements support.
Set a JSON schema whenever the answer has a fixed shape. It produced the shortest run of the session and it makes the answer parseable at no cost; whether it shortens the thinking reliably needs more than the one run here.
Set the cap from measurement, not from the parameter names. reasoning_effort did not behave as a budget in any direction that could be trusted, so raise max_tokens well above what the task needs, read the reasoning count when a run terminates, and set the real cap above that. On this board the honest number was about 2,200 for the unconstrained case and 4,096 for low.
Leave temperature where the model card suggests. On this evidence it did not change the length of thinking beyond noise, and it did not change the answer.
Use tool calling for its interface, not for speed. It returns the answer in a different field, which is a reason to use it when the harness already speaks tools and a reason to avoid it when a content check is the only thing between your loop and a false failure.
And run each setting more than once before believing a difference. Three identical calls here spanned 1,762 to 8,076 tokens of thinking and did not agree on the move. Every number above is a single draw. The only findings that survive that spread are the ones that were not single draws: the board size effect, measured across five sizes, and the truncation mechanics, which do not depend on how long the model happened to think.