fix(anthropic): accept dict format for reasoning_effort parameter #17441
+146
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Title
fix(anthropic): accept dict format for reasoning_effort parameter
Pre-Submission checklist
tests/litellm/directorymake test-unitType
🐛 Bug Fix
Changes
SDKs like
openai-agents-pythonpassreasoning_effortas a dict containing botheffortandsummaryfields:The OpenAI Responses API handler already supports this dict format, but the Anthropic provider only accepted string format, causing the parameter to be silently ignored.
What was changed
File:
litellm/llms/anthropic/chat/transformation.pyUpdated the
reasoning_efforthandling to accept both formats:"medium"→ works as before{"effort": "medium", "summary": "auto"}→ extractseffort, ignoressummary(Anthropic doesn't support configurable summary)Tests added
6 new unit tests in
tests/test_litellm/llms/anthropic/chat/test_anthropic_chat_transformation.py:test_reasoning_effort_string_format_opus_45test_reasoning_effort_dict_format_opus_45test_reasoning_effort_dict_format_other_modelstest_reasoning_effort_string_format_other_modelstest_reasoning_effort_dict_without_effort_keytest_reasoning_effort_dict_with_none_effortBackward compatibility
This is fully backward compatible - existing string format behavior is unchanged.