All three big model APIs now expose one dial for how hard the model thinks, and none of them agree on its name, its levels or its default. OpenAI calls it reasoning.effort, Anthropic output_config.effort, Google thinking_level. Set reasoning effort on every call, per task rather than per app, and cap output tokens, because defaults differ by model and every thinking token is billed as output on all three APIs. What follows covers the three parameters side by side, the requests that now return a 400, how effort interacts with output limits and the prompt cache, and where we start each kind of task.
Three vendors ship the same knob under three names
Reasoning effort is a soft instruction to a reasoning model about how many tokens to spend thinking before it answers. It is how an API exposes test-time compute. More thinking usually buys better answers on hard problems, and you pay for it in latency and output tokens. The three implementations as documented today:
| OpenAI | Anthropic | ||
|---|---|---|---|
| Parameter | reasoning.effort |
output_config.effort |
thinking_level |
| Levels | none to max, model-dependent |
low, medium, high, xhigh, max |
minimal, low, medium, high, model-dependent |
| What it governs | Reasoning tokens | Every output token, thinking and tool calls included | Thinking tokens |
| Default | medium on GPT-5.5, GPT-5.6 and GPT-6.1 Sol |
high, but medium on Opus 5.5 and Haiku 5.5 |
Per model, from minimal to high |
| Thinking billed as | Output tokens | Output tokens | Output tokens |
The third row surprises people. OpenAI’s reasoning guide scopes effort to how much the model thinks. Anthropic’s effort documentation says the parameter affects all tokens in the response, so on Claude a lower level also means “fewer and terser tool calls”. Turn Claude down to low inside an agent loop and it also makes fewer, shorter tool calls. When a turn fans out to many reads, programmatic tool calling on Claude removes the round trips themselves. Google’s thinking guide describes Gemini as thinking dynamically by default, with thinking_level as the control.
The defaults differ by model, even inside one vendor
If your code omits effort, you get whatever the model’s default is, and that default is a property of the model, not of the API. On Anthropic, most models default to high, while Claude Opus 5.5 and Claude Haiku 5.5 default to medium. A request that ran at high on Opus 5 runs one level lower on Opus 5.5 with no code change. Our Haiku 5.5 migration notes flag the same medium default for anyone moving to Haiku 5.5.
OpenAI’s guide is just as model-specific. GPT-6 Astra does not support none, and sending it returns HTTP 400; its model page lists low through max. GPT-6.1 Sol supports neither none nor minimal and defaults to medium. On Google, gemini-4-argon defaults to medium and supports only low, medium and high, while gemini-3.5-flash-lite defaults to minimal and gemini-3.1-pro-preview to high. We covered what else Argon accepts in our Gemini 4 Argon notes.
So a model swap is also an effort change, and a shared config that passes one level everywhere will fail somewhere: Claude has no minimal at all, GPT-6.1 Sol does not support it, and GPT-6 Astra returns a 400 on none. We pin the level on every call:
# OpenAI Responses API
openai_client.responses.create(model="gpt-6-astra",
reasoning={"effort": "medium"},
max_output_tokens=25000, ...)
# Anthropic Messages API
claude_client.messages.create(model="claude-opus-5-5",
output_config={"effort": "medium"},
max_tokens=16000, ...)
# Google Interactions API
gemini_client.interactions.create(model="gemini-4-argon",
generation_config={"thinking_level": "medium"}, ...)Writing medium where it is already the default is deliberate. Anthropic documents that setting effort to the model’s default is equivalent to omitting it, so pinning costs nothing and survives the next default change. If you use model routing, make the effort level part of the route, validated against the target model’s supported levels.
Effort is soft guidance, and the output cap is the hard limit
None of the three treats effort as a token budget. Anthropic says it directly: “Effort is a behavioral signal, not a strict token budget.” The hard ceiling is the output token limit, and on all three APIs that limit counts thinking and visible text together. What happens when thinking hits it is the expensive part:
- OpenAI returns a response with status
incompleteand reasonmax_output_tokens, which can happen before any visible text exists, so “you could incur costs for input and reasoning tokens without receiving a visible response”. The guide recommends reserving at least 25,000 tokens for reasoning and outputs when you start. - Anthropic counts thinking toward
max_tokenseven when the thinking text is not returned, and its steering thinking page gives two remedies for amax_tokensstop: raise the limit, or lower the effort. - Google stops with status
incompleteand truncated or empty output, still billing the thinking tokens, and advises loweringthinking_levelrather than setting a smallmax_output_tokens.
We learned this one first-hand. The judge in our PR review gate runs an open-weights reasoning model behind an OpenAI-compatible API, where reasoning_effort accepts low, medium or xhigh, with xhigh the default. On the default, it spent 16,000 tokens thinking about a 72 KB diff and never produced an answer. At medium it used about 4,500 reasoning tokens, answered in 44 seconds, and wrote the best-argued summary of the three settings we tried, ahead of both low and xhigh. The gate now pins medium with a 10,000 token output cap, which leaves room for the answer after the thinking.
The trap: with a small output cap, a high-effort call can fail after you have already paid for the thinking. Lower the effort to save money, and size the cap so the answer always fits.
Changing effort mid-conversation can cost you the prompt cache
Agents want different effort on different turns. The naive way, changing the top-level parameter between requests, can break the prompt cache on OpenAI and does break it on Claude. Anthropic’s thinking page explains why: the thinking configuration and the resolved effort level are rendered into the prompt itself, so changing them starts a new cache prefix. OpenAI’s prompt caching guide warns that changing top-level effort can rewrite the hidden system instructions.
Both now ship a per-turn override that keeps the prefix intact. On OpenAI’s GPT-6 models you append a configuration_update item before the next user message. On Claude Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Haiku 5.5, you add an empty system message carrying the new level, behind the beta header mid-conversation-output-config-2026-07-01:
# OpenAI: effort until the next update
{"type": "configuration_update",
"reasoning": {"effort": "high"}}
# Anthropic (beta): effort from the next user turn
{"role": "system", "content": [],
"output_config": {"effort": "low"}}Two details matter in practice. OpenAI’s response object keeps reporting the request-level effort, not the one the update selected, so your logs will show the wrong level unless you log the update yourself. And Anthropic’s per-message effort is still beta, while the top-level parameter is stable. Google documents no mid-conversation effort change and nothing on how thinking_level interacts with its cache, so on Gemini we hold the level constant for a conversation. If caching is new to you, our prompt caching in production post covers the prefix rules that make this matter.
Thinking tokens are output tokens, at output prices
Every one of the three bills thinking at the output rate, including thinking you never see. Anthropic bills the full internal thinking even when display is "omitted" and the thinking field comes back empty. Google’s pricing page labels the output row of its text models “Output price (including thinking tokens)”. OpenAI’s guide says reasoning tokens are invisible through the API but still occupy the context window and are billed as output.
That makes effort the biggest lever on cost per task after model choice. A worked example with list prices: GPT-6 Astra charges $50 per million output tokens, so a call that thinks for 20,000 tokens costs $1.00 in reasoning alone before any visible answer. The same 20,000 thinking tokens on Gemini 4 Argon cost $0.20 at its $10 output rate through November 30, 2026, and $0.40 from December 1, when the rate doubles to $20. A step from medium to high that triples thinking on a route that runs 50,000 times a day is a line item your AI FinOps review will find first, unless you do.
Each API reports the number per call in its usage details, and it belongs in your traces: reasoning_tokens on OpenAI, thinking_tokens on Anthropic, total_thought_tokens on Gemini. Claude’s billed output count will not match the visible tokens, and Anthropic says so explicitly. If you already break spend down by request type, the way our post on Claude Code agent summaries measures one call’s share, add effort as a dimension.
Where we start each kind of task
The vendor guidance converges more than the parameter names do. OpenAI’s table recommends none or low for classification, retrieval and chat, medium as the default for agentic coding and research, and high for hard debugging and deep planning. On xhigh it is blunt: “Only use when your evals show a clear benefit that justifies the extra latency and cost.” Anthropic recommends low for simple tasks such as subagents, medium as the starting point on Haiku 5.5 including agentic coding, and warns that at low in long agent prompts Haiku is more likely to skip a search, stop early, or skip a check. Google’s best practices map simple, moderate and complex tasks to minimal, default and maximum thinking.
Our own numbers sit in the same places. Code review runs at high. We trialed xhigh for reviews and reverted it because it was too slow for how often we review, since a high review of a real diff already takes 15 to 30 minutes or more. The cheap end has a failure mode of its own. A low-effort model does less interpretive repair and will invent a plausible default rather than read one out of a schema, so its prompts get literal values for API versions, enum values and IDs. A low-effort model guesses more, so give it the answers it would otherwise have to work out.
When you go higher, measure it. OpenAI’s guide puts it well: “Treat reasoning.effort as a tuning knob, not the primary way to recover quality.” If a task fails at medium, check the prompt, the tools and the context before buying more thinking, and use your LLM-as-a-judge evals to show the gain before you pay for it on every call.
Verify the effort that actually ran
Effort is easy to get silently wrong. The clearest case we hit was in OpenAI’s Codex CLI: passing model_reasoning_effort=high through a -c override parsed high as invalid TOML, dropped it without a warning, and the run went out at medium. The quoted form, 'model_reasoning_effort="high"', works. Never report an effort level from the flags you passed. Read it from what the run recorded, and pair it with the thinking token count from the usage fields above.
In an agent harness, that means three checks in the trace for every model call: the effort level actually applied, the thinking tokens it produced, and the stop reason. A stop on the output limit with zero visible tokens is the signature of an effort and cap mismatch, and it is cheap to alert on. It also gives your latency budget a cause when a route slows down.
The takeaway
Reasoning effort is the same idea on OpenAI, Claude and Gemini with different names, levels, defaults and side effects, and the side effects are what cost money: defaults that move with the model, values that 400 on some models, thinking billed as output on all three, and caches that break when you change the level the naive way. Pin the level on every call, choose it per route, size the output cap so the answer fits after the thinking, use the per-turn overrides where caching matters, and log the thinking tokens. Start at medium for agent work and let your evals, not a hunch, move it. Our ranking of the most used LLM eval and tracing tools is a starting point for the tracing that evidence comes from.