Cline: "temperature is deprecated for this model" no Bedrock, como resolver

Você seleciona um modelo Claude no Cline, manda a primeira mensagem e em vez da resposta vem: 'temperature' is deprecated for this model. O mesmo modelo responde normalmente em outro cliente, e nada mudou do lado da sua conta AWS. A causa não está no acesso nem no modelo. Está em um campo que o Cline coloca na requisição e que o Bedrock recusa antes de acionar o modelo.

Abaixo está onde esse campo entra, como provar em dois comandos que é ele o culpado, e o que dá para fazer hoje, enquanto a issue segue aberta.

O que significa "temperature is deprecated for this model"?

Significa que o Bedrock recusou a chamada por causa de um parâmetro de inferência, não por credencial, cota ou região. O erro vem de ValidationException, que o Bedrock devolve antes de executar o modelo. Nenhum token é gerado, nenhuma cobrança de inferência acontece, e a task no Cline para na hora.

O trecho que mais confunde é o modelId que vem junto: normalmente um ARN de application inference profile. Isso leva muita gente a achar que o problema é o perfil de inferência. Não é. O perfil apenas encaminha a requisição para o modelo, e o modelo é quem recusa o campo.

Por que só acontece com alguns modelos?

Porque os modelos mais recentes deixaram de aceitar temperature como parâmetro de inferência. Modelos antigos aceitavam e continuam aceitando. Quando você aponta o Cline para um dos novos via Bedrock, o cliente continua mandando o campo do mesmo jeito que mandava antes, e aí a validação do Bedrock barra.

É o mesmo sintoma que aparece em três issues abertas no repositório do Cline:

Issue	Modelo	Caminho	Aberta desde
#12252	modelo Claude recente	Bedrock com application inference profile	13/07/2026
#10573	Opus 4.7	Bedrock	06/05/2026
#15441	Opus 4.7, Sonnet e Sonnet 4.5	provedor Anthropic dentro do Cline	30/10/2026

A #15441 é a mais útil das três: mostra que o erro não é exclusivo do Bedrock. Ele aparece sempre que o cliente envia temperature para um modelo que não aceita mais o campo.

Como confirmar em dois comandos?

Chame o modelo direto pelo Bedrock, uma vez com o campo e outra sem ele. Se a primeira falhar e a segunda responder, a causa está fechada. Use a mesma credencial e o mesmo modelId que o Cline usa.

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

Se o erro aparecer, repita sem temperature:

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

De onde o Cline tira esse campo?

Do metadado do modelo, e ele não é condicional. No código do Cline, a função que monta as opções de chamada passa o campo adiante sem checar se o provedor ou o modelo aceitam:

// 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 } : {}),
  }
}

Repare que maxTokens tem guarda, e temperature não. O valor chega ali a partir do metadado do modelo ou de um override seu, e o SDK do Bedrock o converte em inferenceConfig.temperature. É exatamente esse campo que a validação recusa.

Isso explica um detalhe do relato: o erro some quando você troca de modelo, mesmo sem mexer em nada. O campo continua sendo enviado, mas o modelo novo aceita.

Dá para tirar o campo só pela configuração?

Depende de onde o valor está definido, e é aqui que a maioria das receitas na internet erra.

O Cline permite sobrescrever a temperatura por modelo nas configurações do provedor. Se o valor foi você que definiu, limpar esse override resolve: sem valor, o campo deixa de ser enviado. Se o valor vem do catálogo do próprio Cline, limpar o override não muda nada, porque o metadado do catálogo entra no lugar.

Para saber em qual dos dois casos você está, olhe a configuração do modelo no Cline e verifique se existe um valor de temperatura preenchido. Se não existir e o erro continuar, o campo vem do catálogo e a correção tem que vir do Cline.

O que fazer enquanto a issue não fecha?

Três caminhos, do menos ao mais invasivo:

1. Trocar de modelo para um que aceite o campo. Resolve na hora e não exige nada além de mudar a seleção. É o caminho certo se você só precisa voltar a trabalhar.
2. Apontar o Cline para outro provedor que aceite o mesmo modelo. Se a sua organização permite acessar o modelo por outro caminho, o Cline tem provedores além do Bedrock. Vale confirmar antes se o provedor alternativo também envia o campo, porque o problema é do cliente, não do Bedrock.
3. Aplicar um patch local. É uma linha, e resolve o caso do Bedrock de vez:

// antes
temperature: request.temperature,

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

O patch precisa ser reaplicado a cada atualização da extensão, porque a instalação sobrescreve o arquivo compilado. Use como paliativo, não como solução.

Isso já foi corrigido?

Não. As três issues seguem abertas, a mais antiga desde maio de 2026. A #15441 é a mais recente, aberta em 30 de outubro, e cobre os modelos Claude mais usados. Enquanto não houver correção, o comportamento é o mesmo: o campo vai na requisição e o modelo novo recusa.

Se você cair nisso, vale comentar na issue com o modelId, a versão do Cline e o resultado do teste direto acima. É o tipo de evidência que separa "não funciona" de "o campo X é recusado pelo modelo Y", e acelera qualquer correção.