SideNote ProReasoning effort explained: when depth is worth the wait
Reasoning effort is a dial for how much thinking a model does before it answers. Turning it up is not free, and turning it up on the wrong task buys you a slower, more expensive version of the same answer.
What reasoning effort is
Some models can work through a problem internally before producing a visible answer. That internal work costs generated tokens and takes time. Reasoning effort is how you tell the model roughly how much of it to do.
The request field and the SideNote Pro setting both use the name reasoning effort. reasoning_effort is a field on an OpenAI-compatible chat request: a string the client sends, which the model on the other end may honour, ignore or reject. Reasoning effort in SideNote Pro decides what goes into that field, or whether it is sent at all.
POST https://api.openai.com/v1/chat/completions
{
"model": "gpt-6-luna",
"reasoning_effort": "none",
"stream": true,
"messages": [ ... ]
}On Provider default, that one line is simply absent from the body. Nothing else about the request changes. SideNote Pro, a Windows assistant that talks to whichever provider you configure, exposes the choice as one dropdown per provider profile in Settings, AI providers.
Settings › AI providers
| Setting | Sent as |
|---|---|
| Provider default | The field is omitted entirely |
| None | none |
| Minimal | minimal |
| Low | low |
| Medium | medium |
| High | high |
| Extra high | xhigh |
| Maximum | max |
Provider default omits the field, which is why it is the default and the safest choice. A model that does not recognise reasoning_effort may ignore your value or reject the request. Note what it does not mean: it is not None. None asks for no reasoning; Provider default asks for nothing and leaves the model on its own default, which on a reasoning model may be substantial. Set a level only when you know the model supports one.
The tradeoff, without invented numbers
Raising reasoning effort generally means: more time before the first visible token, more generated tokens billed, and better performance on problems whose answer depends on connecting several things correctly.
There is no single figure for that: the actual latency and cost difference depends on the model, the provider, the prompt, how long the answer is, and network conditions. A percentage measured on someone else's workload may not fit yours.
Higher effort generally takes longer and uses more generated tokens. Whether it improves the answer depends on the task.
Four worked examples
Rewrite this to sound more concise and professional
Low effort. There is nothing to work out. The model needs to recognise register and produce fluent text, both of which it does in one pass. Deep reasoning here produces the same sentence, more slowly. If the output disappoints, the fix is a better instruction (cut it to two sentences, keep the deadline), not more reasoning.
Summarize this meeting note and identify the three decisions
Low to medium. Mostly extraction: the decisions are stated in the text, and the task is finding and compressing them. Reach for medium if the notes are long and contradictory, where working out which of two statements superseded the other is genuine inference rather than extraction.
Review this system design and identify failure modes involving concurrent writes
High. This is exactly what the dial is for. The answer requires holding several components in mind at once and simulating interleavings that the design document never spells out. A fast pass tends to produce plausible generic advice about locking; a deeper pass is more likely to find the specific interleaving that breaks this design.
Compare these two contracts and identify materially different obligations
Medium to high, depending on document complexity. Two documents, cross-referenced clauses, and differences that matter hiding among differences that do not. Worth the depth.
On that last one: an AI comparison of contracts is a way to find things worth looking at, not legal advice, and no reasoning level makes it one. Verify anything with legal or financial consequence with someone qualified.
A rule that holds up
Pay for reasoning when the answer depends on connecting several things correctly. Do not pay for it when the answer depends on saying one thing well.
Two corollaries worth internalising. High is not automatically better: on a fluency task it is slower with no gain. And low does not mean poor quality: on a task with no hidden structure it produces the same answer sooner.
Making it practical
Because the setting lives on the provider profile, the workable pattern is two profiles rather than constant adjustment: one everyday profile, left on Provider default unless its model documents none, and one deep profile on a capable model with effort raised. Switch from the composer picker when a problem turns out to be hard.
A worked example of the fast half: gpt-6-luna documents none, and OpenAI lists medium as its default, so the everyday profile in the low-cost GPT-6 Luna setup sets reasoning effort to None on purpose rather than leaving it on Provider default. That recommendation belongs to that model. Another provider's model may reject the value, ignore it, or have no reasoning to switch off in the first place, which is why the general advice stays Provider default until you have checked. Choosing an AI model is the other half of the same decision.
One thing to watch: context compaction calls your configured model to summarize older messages. In a long thread on a high-effort profile, that summarisation also runs at high effort. It is another reason not to leave a heavyweight profile selected for casual conversation.
Settings › AI providers › Model pricing
