PR #25958: fix(anthropic): allow effort="max" on Claude Opus 4.7

• Repository: BerriAI/litellm
• Author: shang309073819
• State: open | merged: False
• Link: https://github.com/BerriAI/litellm/pull/25958

Description (problem / solution / changelog)

Title

fix(anthropic): allow effort="max" on Claude Opus 4.7

Relevant issues

Fixes #25957

Pre-Submission Checklist (Click to expand)

• I have Read the Contributing Guide
• I have added a test for this PR
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible

Type

🐛 Bug Fix

Changes

AnthropicConfig._apply_output_config previously rejected effort="max" for any model that wasn't Claude Opus 4.6:

# litellm/llms/anthropic/chat/transformation.py (before)
# ``max`` is Claude Opus 4.6 only (not Sonnet 4.6, not Opus 4.5/4.7).
# Keep this hardcoded so the error message is specific and stable.
if effort == "max" and not self._is_opus_4_6_model(model):
    raise ValueError(
        f"effort='max' is only supported by Claude Opus 4.6. "
        f"Got model: {model}"
    )

This guard was added in #22234 (back when 4.6 was the only model accepting max) and was intentionally kept in the day-0 4.7 PR (#25867). However, Anthropic's Messages API accepts output_config.effort="max" on claude-opus-4-7-* as well — calling the API directly with model=claude-opus-4-7-*, output_config={"effort":"max"}, and thinking={"type":"adaptive"} returns a normal 200 completion.

So LiteLLM was the only thing in the chain rejecting a perfectly valid configuration, breaking flows like Claude Code via ANTHROPIC_BASE_URL and any direct SDK call against Opus 4.7 with reasoning_effort="max".

This PR allows effort="max" on both Opus 4.6 and Opus 4.7. _is_opus_4_7_model already exists on AnthropicConfig (added in #25867), so the diff is minimal:

if effort == "max" and not (
    self._is_opus_4_6_model(model) or self._is_opus_4_7_model(model)
):
    raise ValueError(
        f"effort='max' is only supported by Claude Opus 4.6 and 4.7. "
        f"Got model: {model}"
    )

I kept the substring-style check (rather than switching to a model-map supports_max_reasoning_effort lookup) so date-variant model names (e.g. claude-opus-4-7-20260408) keep working without requiring every dated entry to be present in the cost map. Switching to a data-driven lookup would be a reasonable follow-up but is out of scope for this fix.

Tests

• Updated test_max_effort_rejected_for_opus_45 and test_max_effort_rejected_for_sonnet_46 to match the new error message.
• Added test_max_effort_accepted_for_opus_47 (regression for #25957).
• Existing test_max_effort_accepted_for_opus_46 still passes unchanged.

$ pytest tests/test_litellm/llms/anthropic/chat/test_anthropic_chat_transformation.py -k "effort or output_config or opus"
......................                                                   [100%]
22 passed, 115 deselected in 0.32s

Changed files

• litellm/llms/anthropic/chat/transformation.py (modified, +8/-7)
• litellm/model_prices_and_context_window_backup.json (modified, +28/-9)
• litellm/types/utils.py (modified, +1/-0)
• litellm/utils.py (modified, +3/-0)
• model_prices_and_context_window.json (modified, +28/-9)
• tests/test_litellm/llms/anthropic/chat/test_anthropic_chat_transformation.py (modified, +54/-14)
• uv.lock (modified, +1/-1)