Cline: "temperature is deprecated for this model" on Bedrock, how to fix

You pick a Claude model in Cline, send the first message, and instead of an answer you get: 'temperature' is deprecated for this model. The same model answers fine in another client, and nothing changed on your AWS account. The cause is neither your access nor the model. It is a field Cline puts into the request and Bedrock rejects before it ever reaches the model.

Below is where that field enters, how to prove in two commands that it is the culprit, and what you can do today while the issue stays open.

What does "temperature is deprecated for this model" mean?

It means Bedrock rejected the call because of an inference parameter, not because of credentials, quota or region. The error comes from ValidationException, which Bedrock returns before running the model. No tokens are generated, no inference is billed, and the task in Cline stops immediately.

The part that confuses most people is the modelId that comes attached: usually an application inference profile ARN. That leads many to think the inference profile is the problem. It is not. The profile only forwards the request to the model, and the model is the one rejecting the field.

Why does it only happen with some models?

Because newer models stopped accepting temperature as an inference parameter. Older models accepted it and still do. When you point Cline at one of the new ones through Bedrock, the client keeps sending the field exactly as it always did, and Bedrock validation blocks it.

It is the same symptom reported in three open issues in the Cline repository:

Issue	Model	Path	Open since
#12252	recent Claude model	Bedrock with application inference profile	Jul 13, 2026
#10573	Opus 4.7	Bedrock	May 6, 2026
#15441	Opus 4.7, Sonnet and Sonnet 4.5	Anthropic provider inside Cline	Oct 30, 2026

#15441 is the most useful of the three: it shows the error is not exclusive to Bedrock. It shows up whenever the client sends temperature to a model that no longer accepts the field.

How do you confirm it in two commands?

Call the model straight on Bedrock, once with the field and once without it. If the first fails and the second answers, the cause is settled. Use the same credential and the same modelId Cline uses.

aws bedrock-runtime converse \
  --model-id arn:aws:bedrock:us-west-2:YOUR_ACCOUNT:application-inference-profile/YOUR_ID \
  --messages '[{"role":"user","content":[{"text":"say ok"}]}]' \
  --inference-config '{"temperature":0.2,"maxTokens":16}'

If the error appears, run it again without temperature:

aws bedrock-runtime converse \
  --model-id arn:aws:bedrock:us-west-2:YOUR_ACCOUNT:application-inference-profile/YOUR_ID \
  --messages '[{"role":"user","content":[{"text":"say ok"}]}]' \
  --inference-config '{"maxTokens":16}'

Where does Cline get that field from?

From the model metadata, and it is not conditional. In the Cline source, the function that builds the call options passes the field along without checking whether the provider or the model accept it:

// sdk/packages/llms/src/providers/ai-sdk.ts
export function buildAiSdkStreamConfig(request, context) {
  const reasoning = resolvePortableReasoning(request, { context })
  return {
    ...(request.maxTokens !== undefined
      ? { maxOutputTokens: request.maxTokens }
      : {}),
    temperature: request.temperature,
    ...(reasoning ? { reasoning } : {}),
  }
}

Notice that maxTokens is guarded and temperature is not. The value arrives from the model metadata or from an override you set, and the Bedrock SDK turns it into inferenceConfig.temperature. That is exactly the field validation rejects.

This explains a detail from the reports: the error disappears when you switch models, even though you changed nothing. The field is still being sent, the new model just accepts it.

Can you drop the field through configuration alone?

It depends on where the value is defined, and this is where most recipes on the internet get it wrong.

Cline lets you override temperature per model in the provider settings. If you are the one who set the value, clearing that override fixes it: with no value, the field stops being sent. If the value comes from Cline's own catalog, clearing the override changes nothing, because the catalog metadata takes its place.

To know which case you are in, open the model settings in Cline and check whether a temperature value is filled in. If none is set and the error persists, the field comes from the catalog and the fix has to come from Cline.

What can you do while the issue stays open?

Three paths, from least to most invasive:

1. Switch to a model that accepts the field. It works right away and needs nothing beyond a different selection. This is the right path if all you need is to get back to work.
2. Point Cline at another provider that accepts the same model. If your organization allows reaching the model through another route, Cline supports providers beyond Bedrock. Confirm first whether the alternative provider also sends the field, because the problem belongs to the client, not to Bedrock.
3. Apply a local patch. It is one line, and it settles the Bedrock case for good:

// before
temperature: request.temperature,

// after
...(context.provider.id !== "bedrock" && request.temperature !== undefined
  ? { temperature: request.temperature }
  : {}),

The patch has to be reapplied on every extension update, because the installation overwrites the compiled file. Treat it as a stopgap, not a solution.

Has this been fixed?

No. All three issues remain open, the oldest since May 2026. #15441 is the most recent, opened on October 30, and covers the most used Claude models. Until there is a fix, the behavior is the same: the field goes out in the request and the new model rejects it.

If you hit this, it is worth commenting on the issue with the modelId, the Cline version and the result of the direct test above. That kind of evidence is what separates "it does not work" from "field X is rejected by model Y", and it speeds up any fix.