Parameters by Upstream

Some request fields do not mean the same thing everywhere. This page states what the gateway does with each one on the way to each provider - passed through, translated into the provider's own equivalent, or dropped.

This is not a list of every accepted field; each endpoint page documents its own request body. Listed here are the fields where supported is not a yes or no, because the answer changes with the provider your model runs on.

reasoning_effort

Full guide, with values and cost impact →

You call Upstream Behaviour Description
/v1/chat/completions OpenAI-compatible (GPT, GLM, DeepSeek, Qwen, Kimi…) passed through Forwarded to the provider as sent, with one exception: when a model's catalog entry lists the effort levels it accepts, a value below the lowest is raised to it and one above the highest steps down (GPT-6.1 Sol cannot turn reasoning off, so none and minimal run at low). Otherwise the gateway neither validates the value nor guarantees the provider honours it. Commonly minimal, low, medium and high, but the accepted set is the provider's: OpenAI also takes none on most models, GLM takes up to max. Check the provider's own reference for its range.
/v1/chat/completions Google Vertex - Gemini 4 mapped Becomes Gemini's thinkingLevel, kept inside the three levels Gemini 4 Argon accepts: none and minimal run at low (the model cannot turn thinking off), low/medium/high map straight across, xhigh and max run at high. An explicit google.thinking_config in the request wins over this mapping.
/v1/chat/completions Google Vertex - Gemini 3.x mapped Becomes Gemini's thinkingLevel: none and minimal both map to minimal, low/medium/high map straight across. An explicit google.thinking_config in the request wins over this mapping.
/v1/chat/completions Google Vertex - Gemini 2.5 dropped Gemini 2.5 only understands thinkingBudget and rejects thinkingLevel outright, so the gateway sends neither and leaves the model at its default thinking behaviour. Use google.thinking_config with thinking_budget to control 2.5.
/v1/chat/completions Anthropic (Claude) mapped Becomes Anthropic thinking, in the form the model accepts. On Claude models that only take adaptive thinking (Claude Opus 4.7 and later, Sonnet 5 and later, Haiku 5.5), low/medium/high/xhigh/max become thinking:{"type":"adaptive"} with output_config.effort at the same level, and minimal runs at low. none switches thinking off in the model's own form: {"type":"disabled"} on most, {"type":"between_tools"} on Sonnet 5.5, and adaptive at low on Opus 5.5, which cannot turn thinking off. Any other value is not forwarded. On earlier Claude models it becomes a budget instead: none and minimal turn thinking off ({"type":"disabled"}); low/medium/high/xhigh/max become a budget of 2,048 / 8,192 / 16,384 / 32,768 tokens - the inverse of the bucket mapping used in the other direction. A derived budget is clamped to stay below max_tokens, and is skipped entirely when max_tokens cannot fit Anthropic's 1,024-token minimum, so asking for effort never turns a working request into an upstream 400.
/v1/messages OpenAI-compatible (GPT, GLM, DeepSeek, Qwen, Kimi…) mapped Derived from thinking.budget_tokens by bucket, when extended thinking is enabled and the budget is above zero: up to 2,048 tokens becomes low, up to 8,192 becomes medium, above that becomes high. A zero or absent budget sends nothing. For a model whose catalog entry lists the effort levels it accepts (GPT-6.1 Sol), the request's intent is followed instead: thinking disabled or between_tools runs at the lowest level (low), even when output_config.effort is also set; otherwise output_config.effort is sent as the effort.
/v1/responses OpenAI-compatible (GPT, GLM, DeepSeek, Qwen, Kimi…) mapped Read out of the Responses-API reasoning.effort object and sent as the flat reasoning_effort field.

thinking / thinking_budget / enable_thinking

You call Upstream Behaviour Description
/v1/chat/completions Anthropic (Claude) mapped These are other vendors' names for the same dial, and the gateway normalises them. thinking:{"type":"disabled"}, enable_thinking:false and thinking_budget:0 all turn thinking off, the same way reasoning_effort none does on that model. On earlier Claude models, thinking_budget:N and thinking:{"type":"enabled","budget_tokens":N} pass the budget through unchanged - an out-of-range value is rejected by the upstream rather than silently adjusted. On models that only take adaptive thinking a budget is never sent: it becomes output_config.effort (up to 2,048 low, up to 8,192 medium, under 32,768 high, 32,768 and above xhigh; never max). thinking:{"type":"adaptive"} on its own sends no thinking setting, so the model runs at its default.
/v1/chat/completions Google Vertex - Gemini 4 mapped Normalised into thinkingConfig.thinkingLevel, because Gemini 4 Argon rejects thinkingBudget: turning thinking off runs at low, and an explicit budget is folded into a level (up to 2,048 tokens low, up to 8,192 medium, above that high). An explicit google.thinking_config in the request still wins.
/v1/chat/completions Google Vertex - Gemini 3.x mapped Normalised into thinkingConfig: turning thinking off becomes thinkingLevel:"minimal", and an explicit budget becomes thinkingBudget. An explicit google.thinking_config in the request still wins over all of it.
/v1/chat/completions Google Vertex - Gemini 2.5 mapped Normalised into thinkingConfig.thinkingBudget - turning thinking off sends a budget of 0, and an explicit budget passes through. thinkingLevel is not used here because 2.5 rejects it. An explicit google.thinking_config in the request still wins.

Every row is transcribed from the converter that implements it and pinned by a Go test, so this table cannot drift from the running gateway without a build failing.