Repository navigation
Fix Claude models routing to Responses API causing not_found_error - #1477
dajiaohuang wants to merge 2 commits into
Conversation
…ixes usestrix#1369) resolve_api_type() was checking LiteLLM catalog for /v1/responses support but falling through to 'responses' for unknown/new models. Models routed through LiteLLM (non-OpenAI providers like anthropic/*) must always use chat_completions since /v1/responses is OpenAI-specific. Add an explicit routes_through_litellm() check before the catalog lookup.
|
| if routes_through_litellm(model_name): | ||
| return "chat_completions" |
There was a problem hiding this comment.
No test covers the new early return in resolve_api_type. Existing tests check provider detection and OpenAI defaults separately, so removing this guard would leave them passing.
Add a test for anthropic/claude-sonnet-4-6 with a catalog entry advertising /v1/responses and expect chat_completions. Also check that an explicit responses override still wins.
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/config/models.py
Line: 676-677
Comment:
**Routing fix lacks a test**
No test covers the new early return in `resolve_api_type`. Existing tests check provider detection and OpenAI defaults separately, so removing this guard would leave them passing.
Add a test for `anthropic/claude-sonnet-4-6` with a catalog entry advertising `/v1/responses` and expect `chat_completions`. Also check that an explicit `responses` override still wins.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Withdrawn: the claimed repair is not established on the supported routing path. The original explanation that an unknown catalog entry falls through to Responses was incorrect: an absent entry produces no supported endpoints, and resolve_api_type falls back to chat_completions.
StrixProvider routes anthropic/* through the SDK LiteLLM model provider independently of the SDK-native OpenAI API default set by configure_sdk_api_route. The early return in this patch and its monkeypatched catalog regression therefore do not demonstrate a correction of the Anthropic not_found_error reported in #1369. That report remains unresolved; this closure is not a claim that its error does not exist.
The previous targeted test/Ruff pass at f3a3639 is historical branch coverage, not real provider acceptance. No new tests, builds, runtime, installation, CI runs, or provider requests were performed during this reassessment. Branch and commits are retained.