max_tokens

Thinking tokens for reasoning models are typically billed, and setting a token budget cap can prevent runaway costs from a single request.

The OpenAI API measures RPM and combined TPM by model series, and on each request checks whether the estimated prompt tokens plus the requested max_tokens fall within the remaining TPM pool.

In a test with max_tokens set to 16, Gemini 2.5 Flash-Lite reported 12 reasoning tokens, with an empty visible reply.

The reasoning tokens produced by reasoning models share the same max_tokens budget as the final output, and they are billed as usual even if the visible reply is an empty string.

max_tokens is the maximum number of tokens the model can generate in a single reply, and it affects both latency and cost

Claude Code's recovery limit for max_tokens errors is three attempts, with the constant named MAX_OUTPUT_TOKENS_RECOVERY_LIMIT = 3.

temperature, top_p, and max_tokens are common across most models, but some reasoning models do not accept temperature, or have special semantics for max_tokens.

The context window is the total token limit of input plus output that a model can accept in a single call, which is a model capability boundary; max_tokens is an output length limit actively imposed by the application and is a cost and latency control valve, and the two are often confused.

For models billed by token, a malformed prompt risks unexpectedly generating a large number of tokens; engineering safeguards can be implemented as three layers: a hard max_tokens cap, client-side prompt length validation, and an API call timeout guard.

A finish_reason value of length or MAX_TOKENS means the model was forcibly interrupted rather than concluding on its own.

When setting max_tokens, real headroom should be reserved and an alert triggered when approaching the limit, because slow growth is the typical path to hitting the wall.

When output is truncated by max_tokens, the constrained decoding layer halts along with it, leaving a structurally incomplete response.