Home → Help

400 unsupported parameter on a reasoning model

Reasoning models fix their own sampling. Sending temperature, top_p or the penalty parameters is rejected outright rather than ignored, so a shared request builder that always sets them breaks the moment you point it at one.

What you are seeing

Why it happens

The reasoning chain is produced under settings the provider controls. Allowing a caller to alter them would change the behaviour the model was tuned for, so the API refuses instead of silently overriding.

Most libraries set temperature by default. The parameter is in the request even when you never wrote it, which is why the error appears for code that 'does not use temperature'.

The set of rejected parameters differs between model families and changes over releases. Hard-coding a list of exceptions ages badly.

How to fix it

  1. Omit sampling parameters instead of setting defaultsBuild the request without temperature and top_p unless a caller explicitly asked for them. Sending temperature=1 'to be safe' is still sending it.
  2. Branch on the model, not on the errorKeep one small map of which models take sampling parameters and strip them before the call. Catching the 400 and retrying works but doubles latency on every request.
  3. Use the reasoning-effort control where one existsWhere a model exposes an effort or thinking-budget setting, that is the knob meant for you. It is also what drives the cost difference between runs.
Reasoning output is billed as output tokens on APICLAN, so effort settings move the bill directly. Each model page lists the rate, and your usage log breaks every call into input, output, cache read and cache write.

Related

Unexpected token '<' when calling an OpenAI-compatible API401 invalid API key — when the key looks right but still fails

Last checked 2026-10-01. Written from problems diagnosed on a live OpenAI-compatible gateway, not collected from other sites.