When to use high reasoning effort

One question that decides it

Does the answer depend on connecting several things correctly, or on saying one thing well?

Connecting several things is what reasoning buys. Saying one thing well is something capable models already do in a single pass, and no amount of extra thinking improves it.

A second useful check: could a knowledgeable person answer this immediately, or would they need to sit and work through it? If they would need to work through it, so does the model.

Where it earns its cost

• Debugging from evidence. Logs, a stack trace and code, where the cause is an interaction rather than a line. *Identify the most likely race condition and explain the sequence that causes it.*
• Design review. Failure modes that only appear when components interact. *Review this design and identify failure modes involving concurrent writes.*
• Contradiction hunting. Requirements or documents that conflict in ways nobody noticed. *Which of these requirements cannot all be true at once?*
• Hidden assumptions. *Compare these two strategies and identify the assumptions each depends on that are not stated.*
• Multi-document comparison. Two contracts, two specifications, where differences that matter hide among differences that do not.
• Non-obvious tradeoffs. *What would break first if we scaled this ten times, and why that rather than the database?*

The common shape: several facts, an answer that depends on their interaction, and a plausible-sounding wrong answer readily available. That last part is why depth matters. On these problems a fast pass produces generic advice that sounds right.

Where it buys nothing

• Rewriting and tone changes. There is no chain of inference in *make this sound more formal*.
• Summarizing straightforward text. Extraction and compression, not reasoning.
• Translation of ordinary prose.
• Generating variants. Ten headline options need breadth, not depth.
• Formatting and restructuring. Turning notes into a table is mechanical.
• Simple factual lookups within the model's knowledge.
• Syntax questions. *What is the regex for this* does not need deliberation.

Three things people get wrong

Low reasoning does not mean low quality

On a task with no hidden structure, a low-effort answer is the same answer, sooner. Quality comes from the model's capability and from your prompt, not from the dial.

High reasoning does not fix a bad prompt

If the answer missed because your question omitted a constraint, more reasoning produces a more thoroughly reasoned answer to the wrong question. Fix the prompt first, every time. See writing better prompts.

It is not always supported

reasoning_effort is an optional field. A provider or model that does not implement it may ignore your setting or reject the request outright. Provider default omits the field, which is why it is the safe default.

How to actually work this way

Do not adjust the setting per message; you will not keep it up. Keep two profiles instead: an everyday one on a fast model at Provider default, and a deep one on a capable model with effort raised. Switch from the composer picker when a problem turns out to be hard.

A useful pattern is escalation. Ask on the fast profile first. Many problems that look hard are not, and you find out in three seconds. When the fast answer is visibly shallow, switch profiles and ask again. You pay for depth only on the problems that turned out to need it.