Thinking Budgets and Extended Reasoning Limits

TL;DR: A thinking budget caps how many tokens a reasoning model spends before it answers. Anthropic's legacy budget_tokens and OpenAI's reasoning_effort are not the same kind of control — one is a token count, the other a behavioral level — and Google's newest API dropped the numeric option entirely. Set the cap too tight on any of them and you can pay for reasoning and get nothing visible back.

What Does a Thinking Budget Actually Cap?

A reasoning model spends tokens thinking before it writes the answer you see. A thinking budget is whatever mechanism a vendor gives you to bound that spend. The confusion starts because "thinking budget" gets used loosely for two genuinely different controls, and every major vendor now leans toward one over the other.

The first is a literal budget: a token count you choose directly, like Anthropic's budget_tokens. The second is an effort level: a qualitative setting like low, medium or high that a model interprets on its own, without you ever naming a token count. OpenAI has only ever offered the second kind. Anthropic offered the first and is actively moving models to the second. Google's older API offers both at once, and its newest API offers only the second. That shift, away from a number you set toward a level the model interprets, is the throughline of this whole page.

Whichever kind you're setting, the tokens it produces are real and billed. That's the part every vendor agrees on, and it's why getting the budget wrong is a cost problem before it's ever a quality problem.

Why Can a Thinking Budget Set Too High Return an Empty Response?

This is the failure that makes a working integration look broken, and it happens on both OpenAI and Anthropic for the same underlying reason: thinking and the visible answer draw from the same pool.

OpenAI's own reasoning guide describes it directly: "If the generated tokens reach the context window limit or the max_output_tokens value you've set, you'll receive a response with a status of incomplete and incomplete_details with reason set to max_output_tokens. This might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response." Read that last clause again: you can pay for a request and receive no answer text at all, with a 200 response and no error to point at.

Anthropic's version of the same trap is structural rather than a documented edge case: budget_tokens must be set lower than max_tokens, precisely because "thinking tokens count toward the max_tokens limit for the turn, so the budget must leave room for the final response." Set a budget close to your max_tokens ceiling on a genuinely hard problem, and there's no room left for Claude to write the answer once it finishes reasoning.

Here's the handling OpenAI's own docs show for catching this in code:

const response = await openai.responses.create({
  model: "gpt-5.6",
  reasoning: { effort: "medium" },
  input: [{ role: "user", content: prompt }],
  max_output_tokens: 300,
});

if (
  response.status === "incomplete" &&
  response.incomplete_details.reason === "max_output_tokens"
) {
  console.log("Ran out of tokens");
  if (response.output_text?.length > 0) {
    console.log("Partial output:", response.output_text);
  } else {
    console.log("Ran out of tokens during reasoning");
  }
}

How Does Anthropic's budget_tokens Work, and Is It Still Current?

Manual mode sets a target with thinking: {type: "enabled", budget_tokens: N}. Two hard rules govern it: a minimum of 1,024 tokens ("The API rejects smaller values."), and it must stay below max_tokens, with one exception for interleaved thinking between tool calls, where the budget can span multiple thinking blocks in a single turn.

The number is a target, not a guarantee of spend. Anthropic states it plainly: "The budget is a target rather than a strict cap. Actual token usage varies with the task, and Claude may stop reasoning well before the budget is exhausted; max_tokens remains the hard ceiling on total output." Claude might use 400 tokens against a 10,000-token budget on an easy question, or push close to the limit on a hard one.

The bigger fact, and the one that changes how you should read the rest of this section: budget_tokens is on its way out. Anthropic's own docs say it plainly: extended thinking with budget_tokens "is deprecated on the Claude 4.6 models (requests using it still succeed). Claude 4.7 and later models do not support it and reject requests that use it, returning a 400 error." Current-generation Claude models steer thinking with effort instead, inside adaptive thinking mode. Only Claude Opus 4.5, Sonnet 4.5 and Haiku 4.5 are stuck on manual budget_tokens today, because it's the only mode those models have.

This post covers the budget mechanics common to all three vendors. If you want the full Claude-specific playbook — the per-model migration table, why current Claude models need less prompting toward thoroughness rather than more, and worked effort-level guidance for Opus 5 and Sonnet 5 specifically — our dedicated guide to prompting Claude's extended thinking owns that depth.

Is OpenAI's reasoning_effort a Thinking Budget?

No, and this is the most common category error in the space. OpenAI has never exposed a token count for thinking. What it exposes is reasoning_effort (Chat Completions) or reasoning.effort (Responses), a string enum. The published API specification lists it plainly: none, minimal, low, medium, high, xhigh, max, defaulting to medium. OpenAI's reasoning guide describes what moving along that scale does: "Lower effort favors speed and lower token usage, while at higher effort the model thinks more completely to provide higher quality responses." Not every model supports every level, and defaults vary by model too — gpt-5.5 defaults to medium.

There is no separate cap for reasoning tokens specifically. The only numeric lever is max_output_tokens on the Responses API (minimum 16) or max_completion_tokens on Chat Completions, and both cover the entire response. OpenAI's controlling-costs guidance is explicit that this single number governs "the total number of tokens the model generates, including reasoning tokens, visible output tokens, and non-visible formatting tokens." So on OpenAI, "size your thinking budget" really means "size your output cap generously enough that reasoning has somewhere to go," and OpenAI's own recommendation while you're finding that number is concrete: "reserving at least 25,000 tokens for reasoning and outputs when you start experimenting with these models."

Does Google Have a Thinking Budget, and Which API Are You On?

Google is the vendor where the numeric-vs-level distinction is currently mid-transition, and the answer depends entirely on which API you're calling.

On the legacy generateContent API, which Google's own docs still describe as "fully supported," a GenerationConfig object carries a genuine numeric field: thinkingBudget, described as "The number of thoughts tokens that the model should generate." Alongside it sits thinkingLevel, an enum. Usage comes back through thoughtsTokenCount, "Output only. Number of tokens of thoughts for thinking models" — a field kept entirely separate from the visible-output token count, rolled together only in a totalTokenCount. That's the one place among these three vendors where reasoning-token accounting gets its own dedicated field rather than being folded into a details object.

On Google's newer Interactions API — generally available since June 2026, and now the vendor's own recommended default for new projects — the numeric field is simply gone. The formal GenerationConfig reference for that API lists exactly six fields: max_output_tokens, seed, speech_config, stop_sequences, thinking_level, and thinking_summaries. There is no thinking_budget field anywhere in that schema. thinking_level takes four values: minimal, low, medium, high.

One thing Google's docs do not state, in either API: whether maxOutputTokens (or the Interactions API's max_output_tokens) can be exhausted by thinking alone before any visible text appears, the way OpenAI's incomplete status and Anthropic's stop_reason: "max_tokens" both explicitly document. Don't assume Google behaves the same way here without testing your own case — the reference simply doesn't say.

Budget vs. Effort, Side by Side

Read across that table and the pattern is hard to miss: only Anthropic's older mode and Google's legacy API still offer a raw number. Everything shipped more recently, on every vendor, replaced the number with a level.

How Should You Actually Size a Budget or an Effort Level?

Treat this as a cost decision first, a quality decision second — because on every vendor here, thinking tokens are billed. OpenAI states it directly: reasoning tokens "are not visible via the API" but "still occupy space in the model's context window and are billed as output tokens." Anthropic's cost documentation says the same in different words: thinking tokens count as output tokens against the same rate card as visible text. Google's own guidance on its thinking-enabled models is equally direct: "When thinking is turned on, response pricing is the sum of output tokens and thinking tokens."

A few concrete starting points, drawn from what each vendor actually recommends rather than a general rule of thumb:

• Simple tasks: a straightforward extraction, a short classification, a routine rewrite. Anthropic suggests starting "near the 1,024-token minimum" for manual budgets; the equivalent on effort-based systems is low or minimal.
• Moderate tasks: comparing a few options, a multi-step but bounded task. medium effort is the default on most current models for a reason: it's the balance point vendors tune for.
• Genuinely hard tasks: multi-step coding, agentic tool loops, deep analysis. Anthropic recommends "a larger budget of 16,000 tokens or more" on manual mode, or high/xhigh effort on adaptive models. OpenAI's blanket advice while you're still calibrating a workload is to reserve "at least 25,000 tokens for reasoning and outputs."
• Very long reasoning passes: above roughly 32,000 thinking tokens on Anthropic's manual mode, switch to batch processing. Anthropic warns that pushing past that threshold "produces long-running requests that can hit system timeouts and open-connection limits."

Whatever number or level you land on, leave real headroom in your output cap. A budget that's merely generous but paired with a tight max_tokens still produces the same empty-response failure covered above — the cap, not the budget, is what actually decides whether the answer gets written.

A Copy-Paste Comparison Across All Three Vendors

Same underlying decision — a bounded but non-trivial reasoning task — configured the way each vendor currently wants it.

# Anthropic — current models: adaptive thinking + effort, not a manual budget.
curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 16000,
    "thinking": { "type": "adaptive" },
    "output_config": { "effort": "high" },
    "messages": [{ "role": "user", "content": "Diagnose this failing test suite." }]
  }'

# OpenAI — no budget field exists; size the whole output cap generously instead.
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "input": "Diagnose this failing test suite.",
    "reasoning": { "effort": "high" },
    "max_output_tokens": 25000
  }'

# Google — legacy generateContent still has a numeric field; the Interactions API does not.
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{ "parts": [{ "text": "Diagnose this failing test suite." }] }],
    "generationConfig": {
      "thinkingConfig": { "thinkingBudget": 16000 },
      "maxOutputTokens": 4096
    }
  }'

Model names and specific token counts will drift; the shape of each field, and which vendor still gives you a raw number, is the part worth remembering.

Sources and Access Dates

Every claim above traces to a primary document, fetched directly in early September 2026:

• Anthropic: Extended thinking and Effort, fetched as raw markdown.
• OpenAI: the Reasoning models guide, fetched as raw markdown, and the published OpenAI OpenAPI specification.
• Google: the Gemini thinking guide, the Interactions API overview and its formal REST reference, the migration guide, and the generateContent API reference.

For the full cross-vendor value table covering every generation parameter, not just thinking, see our LLM parameter cheat sheet. If your problem is a rate limit rather than a thinking cap, that's a different mechanism entirely.