Follow-up to #28113. Same root cause — Anthropic's Messages API
rejects `temperature` for Claude Opus 4.7, accepting only `top_p` —
applied to the Databricks adapter. Reported by @Kontinuation in the
original issue thread (#26444), with a detailed reproduction by
@dgomez04 in the same thread.
Mirrors the #28113 pattern:
- `DatabricksConfig.get_supported_openai_params` filters out
`temperature` / `top_p` when the model id matches the
`claude-opus-4-7` family
- `map_openai_params` adds the same defense-in-depth guard so a raw
kwargs leak is caught at the second layer too
- `supports_temperature: false` / `supports_top_p: false` set on the
new `databricks/databricks-claude-opus-4-7` entry in both
`model_prices_and_context_window.json` and the backup file to
satisfy `ci_cd/check_files_match.py`
Helper is kept self-contained on `DatabricksConfig` (rather than
reaching into the helper added by #28113 on `AnthropicConfig`) so this
PR can land independently of #28113. Happy to deduplicate in a
follow-up once both land.
Tests:
- new unit: temperature filtered out for databricks-claude-opus-4-7,
the dated variant, and the vendor-prefixed form
- new unit: unreleased dated 4.7 snapshots fall back to the
`_is_claude_4_7_model` family check
- regression: Sonnet 4.5 / Haiku 4.5 / Opus 4.5 / Opus 4.1 / 3.7-sonnet
on Databricks still expose temperature
- defense-in-depth: `map_openai_params(drop_params=False)` strips
temperature for Opus 4.7 and preserves it for Opus 4.5
- end-to-end shape: top-level `litellm.get_supported_openai_params`
for `databricks-claude-opus-4-7` no longer reports temperature
(the exact contract `drop_params=True` keys off)
Closes the Databricks gap from #26444.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
b9a180cde9