fix(llm): add opus-5 to the Anthropic effort-based family list#703
Open
odafeng wants to merge 1 commit into
Open
fix(llm): add opus-5 to the Anthropic effort-based family list#703odafeng wants to merge 1 commit into
odafeng wants to merge 1 commit into
Conversation
`claude-opus-5` was missing from `_EFFORT_BASED_FAMILIES`, so the
substring check at `_build_kwargs` resolved `effort_based` to False and
the request carried `temperature`. Opus 5 rejects it outright, making
every turn on that model fail:
invalid_request_error: `temperature` is deprecated for this model.
The same flag also selects how thinking is expressed, so the miss meant
Opus 5 would have been sent `thinking: {"type": "enabled", ...}` — the
other form that generation rejects — once an effort level was set.
The existing regression tests cover exactly this behaviour but had not
been extended with the new model, which is why the gap went unnoticed;
adding `claude-opus-5` to both model tuples makes them fail without the
one-line fix and pass with it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #701.
Problem
Every turn on
claude-opus-5through theanthropicprovider fails with HTTP 400:_EFFORT_BASED_FAMILIES(anthropic_provider.py:28) is matched by substring:No listed family is a substring of
claude-opus-5, soeffort_basedisFalseand the caller'stemperatureis attached to the request. Opus 5 shipped after the list was last extended — the neighbouring comment already anticipates this ("Extend as new families ship").The same flag also selects how thinking is expressed, so the miss is not limited to
temperature: with an effort level configured, Opus 5 would have been sentthinking: {"type": "enabled", "budget_tokens": N}, the other form that generation rejects. One entry fixes both paths.Change
deeptutor/services/llm/provider_core/anthropic_provider.py— add"opus-5"to_EFFORT_BASED_FAMILIES.tests/services/llm/test_anthropic_provider_fixes.py— addclaude-opus-5to the two model tuples that already assert this behaviour.The tests were the reason this went unnoticed:
test_temperature_omitted_for_effort_based_modelsandtest_effort_based_families_map_real_effort_to_adaptive_thinkingcover exactly this contract, but were never extended with the new model. Withclaude-opus-5added they fail ondevand pass with the fix, so the regression is genuinely covered rather than just described.Verification
Without the provider fix (test change only):
With both changes:
Also exercised end-to-end against the live Anthropic API on a real workspace —
deeptutor run chatand the Web UI turn path both return normal replies onclaude-opus-5where they previously returned the 400.Note on the underlying mechanism
Not part of this PR, but worth flagging: a hardcoded substring list needs an edit for every new model family and fails closed-with-a-400 when it misses one, with no signal until a user hits it in production. The file's own comment names the better fix ("a capability lookup is the longer-term fix"), and this class of bug has recurred on the OpenAI-compatible side too (#141, #54). Happy to look at a capability-driven approach separately if that's a direction you'd want.
Targeting
devper CONTRIBUTING.md.