What changes when you increase a language model's reasoning effort?

What the setting changes during inference

A model has already been trained when an application receives a reasoning-effort setting. Training is the long process that adjusts a model's parameters from data and feedback. Inference is the shorter process of using those fixed parameters to answer one request. Increasing effort changes the latter. It can allow a reasoning model to spend more of its request on intermediate reasoning before it returns user-visible text.

The public behavior is more specific than the popular phrase "think harder." For GPT-5.2, OpenAI says that reasoning.effort controls how many reasoning tokens are generated before the response. The documented levels include none, low, medium, high, and xhigh, but support and defaults vary by model and release (GPT-5.2 guidance). Current model pages also show a different supported set for GPT-6 Astra, which has low through max and does not support none (GPT-6 Astra model page). Do not assume that one provider's level name, default, or effect transfers to another provider or model family.

Providers do not generally disclose a complete, inspectable account of their proprietary reasoning process. A reasoning-token count is useful operational information, but it is not a public, verbatim transcript of the model's hidden reasoning and it does not establish that every intermediate step was correct. In the OpenAI Responses API, a response can include encrypted reasoning content for state handling, while the API separately reports token-usage details (Responses API reference). That supports multi-turn operation; it should not be read as a window into proprietary internals.

Why latency, token use, and quality can move differently

More internal reasoning normally means more model work before the first visible token appears. That tends to raise time to first answer and can raise end-to-end latency. The exact increase depends on hardware, service queueing, input size, cache state, output length, streaming, and any tool calls in the workflow. A high setting is therefore a poor fit for an interaction that needs an immediate short response, even when it improves a benchmark elsewhere.

Token limits can also change the result in a less obvious way. In the Responses API, max_output_tokens is an upper bound for both visible output tokens and reasoning tokens (Responses API reference). If an application sets a tight cap, extra reasoning can leave fewer tokens for the visible answer or make a response incomplete. Inspect usage.output_tokens_details.reasoning_tokens alongside the visible output and completion status when you diagnose this behavior. A provider's billing policy is the authority for a specific charge, but more inference work creates the reason that higher effort can cost more.

Quality gains depend on the task. OpenAI's GPT-5 developer guidance says higher effort does not benefit all tasks equally: in the cited examples, effort above low added little to simple long-context retrieval but helped a visual-reasoning benchmark (Introducing GPT-5 for developers). Current GPT-5.5 guidance gives the same practical caution. It recommends increasing effort only after evaluation shows a measurable gain and notes that higher effort can lead to overthinking, unnecessary searching, or quality regressions when instructions conflict or stopping conditions are weak (GPT-5.5 model guidance).

A hypothetical example

Imagine one fixed model and prompt that must either extract an invoice number from a supplied page or reconcile a three-step set of contractual conditions before selecting a permitted action. The extraction task has a short, explicit target. Test a low-effort setting first because extra deliberation may not change whether the number is copied correctly. The second task has dependencies, exceptions, and a requirement to explain why an action is allowed. It is a better candidate for testing a higher effort setting, provided the system also verifies the final selection against its rules.

Neither result should be assumed in advance. Measure exact-match extraction, rule-valid selections, latency, error rate, and token usage on held-out examples. If the higher setting only lengthens the explanation while the verified decision stays the same, it has not earned its added resource use.

Reasoning effort, temperature, verbosity, and training differ

These controls can all affect what a user sees, which makes them easy to confuse. They act at different points in the system.

Temperature is a sampling control. In OpenAI's API reference, a higher temperature makes output more random and a lower one more focused and deterministic (Responses API reference). It does not give a model a larger reasoning budget. Conversely, a high reasoning-effort request can still be configured to return a concise answer if the model and API support a separate verbosity or output-length control.

Compatibility can matter more than the conceptual distinction. OpenAI's GPT-5.2 guidance says temperature, top_p, and logprobs are supported only when reasoning effort is none for that model, and requests using higher effort with those parameters raise an error (GPT-5.2 guidance). Check the documentation for the exact model and endpoint rather than copying a parameter combination from an older tutorial.

Training differs at the deepest level. It changes the model that later performs inference. Raising effort asks the deployed model to spend more computation on one request. OpenAI's research distinguishes gains from reinforcement learning during training from gains from time spent thinking at test time (Learning to reason with LLMs). A model that lacks needed knowledge or was given ambiguous evidence may still fail at high effort; extra inference computation is not a substitute for accurate context, tools, training data, or verification.

Choose an effort setting with an evaluation

Use the smallest setting that satisfies the product requirement. Start by defining the requirement in observable terms. For a support assistant, that could be a correct, cited resolution and a time-to-first-token target. For a coding agent, it could be tests passing, a correct diff, and an end-to-end completion time. For a data extractor, it could be field-level precision and recall. A vague target such as "seems smarter" cannot tell you whether added effort helped.

1. Hold the model version, prompt, tools, context, output schema, and service tier fixed. Change only reasoning effort in the first comparison.
2. Assemble representative examples, including simple cases, multi-step cases, common edge cases, and examples where the correct behavior is to ask for clarification or decline an unsupported action.
3. Run at least two adjacent effort levels. Record task-quality measures, reasoning-token count when available, visible-output tokens, time to first token, end-to-end latency, completion status, tool calls, and price from the provider's current billing record.
4. Review failures by task type. A higher average score can hide a regression in an important low-latency or safety-sensitive workflow.
5. Promote the higher setting only for the class of tasks where it improves the agreed measure enough to cover the latency and cost. Route simpler tasks to a lower setting if your system can reliably classify them.

This is also the way to distinguish an effort effect from a prompt or infrastructure change. If a model release, a new retrieval source, a longer prompt, an altered tool policy, and a new effort level are all changed together, no result can identify the cause. OpenAI's migration guidance similarly recommends pinning effort, running a baseline evaluation, and then making small changes followed by another evaluation (GPT-5.2 guidance).