I asked a question that should have had a boring answer: what is the difference between “effort,” “reasoning,” and “thinking” in a model setting?
The short version was almost reassuring. Thinking is how much work I ask the model to do. Effort is often the provider’s name for the control sent over the wire. Reasoning can mean the same thing in some interfaces, or it can mean whether the resulting thought summary is visible.
Then I looked at the actual APIs, and the vocabulary fell down a flight of stairs.
Same intention, different knobs
The user intention is simple: spend less time on an easy task, or spend more time on a hard one.
OpenAI currently exposes that through reasoning.effort. The supported ladder depends on the model and can include none, minimal, low, medium, high, xhigh, and max. Higher settings generally trade more latency and tokens for more thorough work.
Google’s Gemini 3 models call the control thinkingLevel, with a smaller ladder such as minimal, low, medium, and high. Gemini 2.5 uses a numeric thinkingBudget instead. On models that support it, zero can disable thinking and minus one can ask the model to choose dynamically. Gemini 3 accepts some older syntax for compatibility, but Google recommends the level-based control.
Anthropic manages to contain both eras in one product family. Older extended-thinking models use thinking: { type: "enabled", budget_tokens: ... }. Newer models move toward adaptive thinking plus output_config.effort. Some configurations that work on one Claude generation return a 400 on another.
This is not one standard with different labels. It is several control systems that happen to express roughly the same human request.
The third dial hiding in the room
Visibility makes the naming even messier.
A model can reason internally without exposing its raw internal trace. A provider may return a summary of that work. A client can then hide, show, or stream the summary. That display choice is separate from how much reasoning the model performed, even when an interface labels both controls “reasoning.”
So there are really three layers:
- The intent: how much time and compute should this task receive?
- The provider control: a level, a token budget, adaptive mode, or a simple switch.
- The presentation: whether any thought summary reaches the screen.
Once those layers are separated, the concepts are not hard. The maddening part is that the same word can refer to different layers depending on which menu or documentation page I opened.
Why the providers have not standardized it
My first answer was branding. I still think branding deserves some of the blame. Every lab wants its reasoning system to look like a distinctive capability, not a beige interchangeable knob. Naming the feature is part of selling the feature.
But the technical excuse is real too.
A numeric token budget and an adaptive effort level are not identical. One asks for a target amount of internal work. The other asks the model to decide how much work the prompt deserves within a general quality band. Some models can turn reasoning fully off; others cannot. Some preserve thought blocks across tool calls; others summarize or discard them. Changing a setting can even affect prompt caching.
A universal field that pretends all of those behaviours are identical would be tidy and dishonest.
The feature is also still moving. Anthropic’s own documentation contains a migration from fixed budget_tokens to adaptive thinking. Google moved from numeric budgets in Gemini 2.5 to named levels in Gemini 3. OpenAI’s list of supported effort values is explicitly model-dependent. We are trying to standardize a control surface while the machinery underneath it is still being rebuilt.
Standards usually arrive after the experiments, not during them.
Middleware becomes the universal adapter
Since the labs do not agree, the translation job falls to clients and gateways.
A tool can expose one friendly “thinking” setting, then map it to the nearest control a provider supports. high might become OpenAI’s high effort, Gemini’s high thinking level, an Anthropic adaptive-effort setting, or merely “enabled” on a provider with a binary switch.
That works, but it is lossy. A seven-rung ladder mapped onto an on/off switch does not preserve seven meanings. The client must either collapse settings quietly or maintain a capability table for every model. When a provider changes an accepted field, the adapter has to learn the new dialect before users discover it through a mysterious 400.
I ran into the practical version of this while inspecting a Kimi integration. The provider deliberately treated thinking as enabled or disabled and left the actual depth choice to the model side. Sending an invented token budget would have looked more precise while being less correct.
Sometimes the honest translation is a shrug encoded as a boolean.
What a useful standard could actually standardize
The common layer does not need to erase provider-specific features. It needs a portable minimum and a way to advertise capabilities.
A small intent ladder such as off, automatic, low, medium, and high would cover most human choices. Each model could declare which values it supports and how they map. Fixed token budgets could remain an optional advanced field. Thought-summary visibility should live in a separate display setting so “reasoning” never has to mean both depth and disclosure.
That would not make every model behave identically. It would make the differences explicit, which is what standards are good at.
We already accept this pattern elsewhere. A browser exposes common web capabilities while still advertising optional features. A database driver negotiates what the server supports. The goal is not to force every engine to work the same way; it is to stop making every user memorize a new spelling for the same intention.
Until then, “thinking” and “effort” are basically the same dial only from ten metres away. Up close, one might be a seven-step selector, one a token counter, and one a switch connected to a black box.
The technology is new enough that some chaos is understandable. But if databases can negotiate capabilities and browsers can converge on APIs, can model providers really not agree on five words and a feature-discovery response?
