[Bug]: get_supported_openai_params still reports 'temperature' as supported for Anthropic Claude Opus 4.7 — Anthropic rejects temperature on this model

[jehunt1548]

What happened?

Anthropic's Claude Opus 4.7 family rejects the temperature parameter at request time (invalid_request_error: temperature is deprecated for this model.). LiteLLM's AnthropicConfig.get_supported_openai_params() still lists temperature as a supported param for these models, so litellm.drop_params=True / drop_params=True is a no-op — LiteLLM has no reason to drop a param it believes is supported, and it forwards temperature to the Anthropic API, which 400s.

Users who want to keep temperature in their call sites for non-reasoning models currently have to work around this with additional_drop_params=[\"temperature\"], which is exactly what drop_params=True should be doing automatically.

Relevant log output / Anthropic response

litellm.exceptions.BadRequestError: litellm.BadRequestError:
AnthropicException - {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",
\"message\":\"`temperature` is deprecated for this model.\"},
\"request_id\":\"req_011CaNyc6Kpmz9bA66oSzTKo\"}

LiteLLM Version

1.83.13 (latest as of filing — also verified on 1.82.4).

Twitter / LinkedIn details

No response

Reproduction

import importlib.metadata as md, litellm

print(\"litellm\", md.version(\"litellm\"))  # 1.83.13
params = litellm.get_supported_openai_params(
    model=\"claude-opus-4-7\", custom_llm_provider=\"anthropic\"
)
print(\"temperature reported as supported?\", \"temperature\" in params)
# → True  (bug — Anthropic rejects it at request time)

# Consequently drop_params=True does nothing:
litellm.drop_params = True
litellm.completion(
    model=\"anthropic/claude-opus-4-7\",
    messages=[{\"role\": \"user\", \"content\": \"hi\"}],
    temperature=0.1,
)
# → BadRequestError: `temperature` is deprecated for this model.

# Workaround (forces the drop):
litellm.completion(
    model=\"anthropic/claude-opus-4-7\",
    messages=[{\"role\": \"user\", \"content\": \"hi\"}],
    temperature=0.1,
    additional_drop_params=[\"temperature\"],
)
# → OK

Root cause (one-line fix)

litellm/llms/anthropic/chat/transformation.py, AnthropicConfig.get_supported_openai_params() (currently around line 217):

def get_supported_openai_params(self, model: str):
    params = [
        \"stream\",
        \"stop\",
        \"temperature\",   # ← unconditionally added
        \"top_p\",
        ...
    ]

    if (
        \"claude-3-7-sonnet\" in model
        or AnthropicConfig._is_claude_4_6_model(model)
        or AnthropicConfig._is_claude_4_7_model(model)
        or supports_reasoning(...)
    ):
        params.append(\"thinking\")
        params.append(\"reasoning_effort\")

    return params

The same branch that already knows the model is Claude 4.6 / 4.7 / reasoning-capable should also remove temperature from params, since those are exactly the models Anthropic has deprecated temperature on.

Suggested fix:

def get_supported_openai_params(self, model: str):
    params = [
        \"stream\", \"stop\", \"top_p\", \"max_tokens\", \"max_completion_tokens\",
        \"tools\", \"tool_choice\", \"extra_headers\", \"parallel_tool_calls\",
        \"response_format\", \"user\", \"web_search_options\", \"speed\",
        \"context_management\", \"cache_control\",
    ]

    is_reasoning_family = (
        \"claude-3-7-sonnet\" in model
        or AnthropicConfig._is_claude_4_6_model(model)
        or AnthropicConfig._is_claude_4_7_model(model)
        or supports_reasoning(
            model=model, custom_llm_provider=self.custom_llm_provider,
        )
    )

    if is_reasoning_family:
        params.extend([\"thinking\", \"reasoning_effort\"])
    else:
        params.append(\"temperature\")

    return params

That restores the contract: drop_params=True correctly strips temperature for Opus 4.7 and any future reasoning-family model, and callers don't have to sprinkle additional_drop_params=[\"temperature\"] throughout their codebases.

Happy to open a PR if useful — wanted to file the bug first so the team can confirm the intended behavior.

[danielnc]

+1 — encountered this in production going through LiteLLM via Mastra's string-form OpenAICompatibleConfig (i.e. @ai-sdk/openai-compatible under the hood, NOT direct @ai-sdk/anthropic).

Stack: Mastra agent → OpenAICompatibleConfig{id: "anthropic/claude-opus-4-7", url: "<litellm>/v1"} → LiteLLM v1.83.10-stable → Anthropic. Live failure: agent dispatched with temperature: 0.3 from default model settings, returned the same 'temperature' is deprecated for this model 400 from Anthropic before the model emitted a token. litellm.drop_params=True did nothing — exactly because of the registry mismatch this issue describes (get_supported_openai_params() says temperature is supported, so LiteLLM has no reason to drop it).

Workaround we shipped (client-side): added a Mastra inputProcessor with a per-model capability matrix that strips temperature/topP/topK for claude-opus-4-7 (plus a few others). It's the only place in our stack that knows about the deprecation. Client-side works for our gateway use case but feels like duplicate maintenance with LiteLLM's own param-compatibility tables.

Why we couldn't use additional_drop_params=["temperature"] instead: we have agents on claude-opus-4-6 and other Anthropic models in the same fleet that do still accept temperature and where stripping it would be a regression. Per-model additional_drop_params works, but at that point we've reimplemented your registry ourselves, which is the same maintenance burden as the client-side processor.

One nuance for the fix scope — when this lands, please consider that the gpt-5.1 family has a value-conditional rule (temperature is allowed when reasoning_effort='none' or omitted, rejected when set to low/medium/high). The Anthropic 4.7 case is a pure "always reject" — easier to encode. But the registry shape (supports_response_schema: true|false, supports_*: bool) doesn't naturally express the conditional case; users who go through the gateway may still need a client-side layer for value-conditional rules.

For the immediate registry fix on opus-4-7, happy to test a candidate PR against our staging if helpful — we have an SSM tunnel to LiteLLM on a known-affected model and can curl + report.

[dgomez04]

Confirming the same bug also affects DatabricksConfig (Databricks model-serving / workspace endpoints) — relevant when Anthropic Claude models are served through Databricks (e.g. databricks/databricks-claude-opus-4-7, which routes to Anthropic's us.anthropic.claude-opus-4-7).

Reproduction (Databricks workspace endpoint)

import litellm

params = litellm.get_supported_openai_params(
    model="databricks-claude-opus-4-7", custom_llm_provider="databricks"
)
print("temperature reported as supported?", "temperature" in params) # → True

litellm.drop_params = True  # no-op for the same reason as the Anthropic case
litellm.completion(
    model="databricks/databricks-claude-opus-4-7",
    api_base="https://<workspace>.cloud.databricks.com/serving-endpoints",
    api_key="<token>",
    messages=[{"role": "user", "content": "hi"}],
    temperature=0.0,
)

The Databricks model-serving endpoint surfaces the same Anthropic deprecation, just wrapped in a Databricks error envelope:

​ litellm.BadRequestError: DatabricksException - {"error_code":"BAD_REQUEST", "message":"BAD_REQUEST: Model us.anthropic.claude-opus-4-7 does not support the temperature parameter."} ​

Root cause (same shape, different file)

litellm/llms/databricks/chat/transformation.py, DatabricksConfig.get_supported_openai_params() (currently around line 196 on main):

​python def get_supported_openai_params(self, model: Optional[str] = None) -> list: return [ "stream", "stop", "temperature", # ← unconditionally added, regardless of `model` "top_p", "max_tokens", "max_completion_tokens", "n", "response_format", "tools", "tool_choice", "reasoning_effort", "thinking", ] ​

Note the model: Optional[str] = None parameter is accepted but never used — so even though Databricks happily serves Claude Opus 4.7 / 4.6 (which deprecated temperature), liteLLM still tells the upstream _check_valid_arg flow that temperature is supported, and the drop_params=True branch in litellm/utils.py:3032 is bypassed for the same reason as the Anthropic case.

Suggested fix (mirrors the Anthropic fix from this issue)

DatabricksConfig already inherits from AnthropicConfig (it's the third base class). The cleanest path would be to gate temperature / top_p on the model name using the same _is_claude_4_6_model / _is_claude_4_7_model helpers that already live on AnthropicConfig:

​python def get_supported_openai_params(self, model: Optional[str] = None) -> list: params = [ "stream", "stop", "max_tokens", "max_completion_tokens", "n", "response_format", "tools", "tool_choice", "reasoning_effort", "thinking", ] model_str = model or "" is_anthropic_temperature_deprecated = ( AnthropicConfig._is_claude_4_6_model(model_str) or AnthropicConfig._is_claude_4_7_model(model_str) ) if not is_anthropic_temperature_deprecated: params.extend(["temperature", "top_p"]) return params ​

That way, fixing AnthropicConfig (per the suggested fix on this issue) and DatabricksConfig together restores drop_params=True to a single, predictable contract across both providers that surface Anthropic Opus 4.7 / 4.6: Anthropic-direct, Bedrock, Vertex (presumably same shape), and Databricks workspace endpoints.

[Kontinuation]

Bump this. We've also hit this problem. The suggested fix in the issue description worked pretty well. Hope to see the fix landing in the next release.