OpenAI, Claude, Gemini Reasoning Control Parameters Compared — Design Philosophy of reasoning_effort / budget_tokens / thinkingLevel

Introduction

There are many situations where you want to control how much an LLM "thinks." For simple questions, you want quick answers; for complex reasoning, you want it to think carefully.

While using reasoning_effort with OpenAI's o-series, a question suddenly came to mind: "How do I do the same thing with Claude or Gemini? What are the parameter names? What's the granularity?"

After looking into it, I found that each of the three companies has implemented reasoning volume control with different design philosophies.

Reasoning Volume Control Parameters from Three Companies

OpenAI o-series: reasoning_effort

{
  "model": "o4-mini",
  "reasoning_effort": "high"
}

• Values: 3 levels — low / medium / high
• Simple with little room for confusion
• Internal token count is left to the model

Claude (extended thinking): budget_tokens

{
  "model": "claude-opus-4-6",
  "thinking": {
    "type": "enabled",
    "budget_tokens": 8192
  }
}

• Values: number of tokens (minimum 1024)
• Upper limit is within max_tokens
• Allows developers to precisely manage reasoning costs

Gemini 3.0+: thinkingLevel

{
  "model": "gemini-3.0-pro",
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "high"
    }
  }
}

• Values: levels such as none / low / medium / high
• Migrated from the Gemini 2.5 era's thinkingBudget (token count specification) to level specification
• The model internally converts to an appropriate token count

Comparison Table

Spectrum of Design Philosophies

Arranging the three companies by "granularity of control" reveals a clear spectrum.

OpenAI: The "Developers shouldn't have to think about it" camp

Just three levels. No room for hesitation. A design that trusts the model and leaves "how much to think" up to the model.

Suitable for: Prototyping, cases where strict management of reasoning costs is unnecessary

Gemini: The "Levels are enough" camp

Similar to OpenAI, but it sits slightly in the middle of the spectrum because it includes none (thinking completely OFF). What's interesting is that Gemini once implemented token count specification (thinkingBudget) in version 2.5, but reverted to level specification in 3.0. This suggests they tried fine-grained control and concluded that "levels are enough."

Suitable for: Cases where you want to toggle thinking ON/OFF, cases where level-based control is sufficient

Claude: The "Developers manage precisely" camp

Specified directly by token count. Developers can control the upper limit of tokens used for reasoning, making cost prediction the most accurate.

Suitable for: Cost management in production environments, cases where you want to finely tune the trade-off between reasoning volume and latency

How to Use Each in Practice

Summary

• All three companies offer "reasoning volume control," but their design approaches differ
• Want to manage costs precisely → Claude's budget_tokens is the best fit
• Want to keep it simple → OpenAI's reasoning_effort or Gemini's thinkingLevel
• Want to turn off thinking entirely → Gemini's none is explicit about it

When building multi-model applications, designing a wrapper that abstracts away the differences between these three parameters makes switching between models much easier.