`temperature` and `top_p` cannot both be specified for this model. Please use only one.
The message
`temperature` and `top_p` cannot both be specified for this model. Please use only one.What it means
The request set both sampling controls, and this Claude model only takes one of them. The API refuses rather than picking one for you.
What to do
Remove top_p and keep temperature (or the other way round). In an app, clear one of the two sliders; on Claude 4.7 and later, leave both at their defaults.
The error in full, as the Claude API returns it:
`temperature` and `top_p` cannot both be specified for this model. Please use only one.This body is from a VS Code bug report in February 2026, reaching Claude through Google's Vertex AI:
{"type":"error","error":{"type":"invalid_request_error","message":"`temperature` and `top_p` cannot both be specified for this model. Please use only one."},"request_id":"req_vrtx_..."}What the two settings are
Both change how adventurous the model's word choices are. Temperature reshapes the odds. Top_p cuts the list of candidates short. OpenAI's API reference has long said "We generally recommend altering this or top_p but not both." On some recent Claude models, Anthropic's API turns that advice into a hard rule.
The reports we read name Sonnet 4.5, Haiku 4.5, Opus 4.1 and Opus 4.5 on Bedrock. It doesn't matter whether the values are sensible. One September 2026 report sent temperature=1 and topP=0.95 to Haiku 4.5 and got this 400.
Why you didn't set both, and got it anyway
Many of the 139 GitHub issues with this line (our count, September 26, 2026) come from tools that fill in both fields on their own. agno's LiteLLM wrapper is a clear case: a bug filed on September 25 shows it defaulting to temperature=0.7 and top_p=1.0 and sending both on every request, so a bare Claude Sonnet 4.5 agent with no sampling settings at all failed. LiteLLM itself passes the pair straight through; on one report a LiteLLM maintainer replied "We can't modify the request in passthrough."
Copilot's bring-your-own-key mode, chat front ends like NextChat and several agent frameworks show up in the same search. In each of them the fix is to find where the second value comes from and leave it empty.
The fix, by model generation
For Sonnet 4.5, Haiku 4.5 and the other models that give this exact error, drop one value. Dropping top_p is the usual choice (the Psycheros patch does exactly that when both are present).
Newer Claude models are stricter still. Anthropic's thinking guide lists Claude Opus 4.7, Opus 4.8, Opus 5, Opus 5.5, Sonnet 5 and the Fable and Mythos models, and says that on them "non-default temperature, top_p, or top_k values return a 400 error on every request, regardless of whether thinking is used." The API reference marks top_p deprecated for "models released after Claude Opus 4.6", accepting only values of 0.99 and up for old code's sake. So on those models the fix is to send neither.
One more case catches people on older models: with extended thinking on, the same guide says temperature is incompatible with thinking and top_p must sit between 0.95 and 1.
Other lines the same feature prints
Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.
`temperature` and `top_p` cannot both be specified for this model.HTTP 400: `temperature` and `top_p` cannot both be specified for this model.temperature and top_p cannot both be specified