fix(llm): route all DashScope models through native provider

[Alphaxiaoteng]

Summary

• Fixes [BUG] DashScope non-Qwen models bypass the native provider and ignore DASHSCOPE_BASE_URL #7233: _matches_provider_pattern only treated DashScope models as native when the name started with qwen, so dashscope/deepseek-v3 (and other supported families) fell through to LiteLLM and ignored DASHSCOPE_BASE_URL.
• Treat dashscope like other OpenAI-compatible providers (return True).
• Add a regression covering a non-Qwen DashScope model with a custom base URL.

Test plan

• Code + regression added next to existing DashScope factory test
• CI: test_openai_compatible.py DashScope cases

Made with Cursor

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 36fdecba-29d4-4b5a-9fe4-aff0ba85b531

📥 Commits

Reviewing files that changed from the base of the PR and between 3d72c70 and 2508348.

📒 Files selected for processing (2)

• lib/crewai/src/crewai/llm.py
• lib/crewai/tests/llms/openai_compatible/test_openai_compatible.py

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The DashScope provider matcher now accepts all DashScope model names. Non-Qwen models route to OpenAICompatibleCompletion and use DASHSCOPE_BASE_URL. A test verifies routing for dashscope/deepseek-v3.

Changes

DashScope routing

Layer / File(s)	Summary
Native DashScope provider routing lib/crewai/src/crewai/llm.py, lib/crewai/tests/llms/openai_compatible/test_openai_compatible.py	The DashScope provider matcher accepts all model names. The test verifies that dashscope/deepseek-v3 creates an OpenAICompatibleCompletion with provider dashscope and the configured base URL.

Suggested reviewers: lucasgomide

Merge Risk: ⚪ Minimal · up to 25083

DashScope models, including non-Qwen families, now consistently use the native OpenAI-compatible route and honor custom DashScope endpoints. The added regression coverage supports merge readiness.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the primary change: routing all DashScope models through the native provider.
Description check	✅ Passed	The description explains the bug, solution, linked issue, and regression test. It uses a Test plan heading instead of Verification and omits Additional context, but the required information is mostly …
Linked Issues check	✅ Passed	The change satisfies issue #7233 by removing the Qwen-only restriction for DashScope, preserving DASHSCOPE_BASE_URL handling for non-Qwen models, and adding regression coverage.
Out of Scope Changes check	✅ Passed	The changes are limited to DashScope provider routing and a focused regression test. No unrelated code changes are present.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.

Full details: Description check

Explanation

The description explains the bug, solution, linked issue, and regression test. It uses a Test plan heading instead of Verification and omits Additional context, but the required information is mostly complete.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[parthiban-sivakumar]

Hi @Alphaxiaoteng,

Thanks for picking this up so quickly! The change looks right to me and matches what I had in mind when I filed the issue.

Two small thoughts, both optional. The comment mentions DeepSeek/Kimi/GLM but the test only covers deepseek-v3 — parametrising over one more family would back up the comment. And it might be worth asserting llm.model == "deepseek-v3" too, just to confirm the model string is passed through correctly.

One thing I left out of the issue deliberately: the hardcoded default https://dashscope-intl.aliyuncs.com/compatible-mode/v1 may also be stale, since the current docs list dashscope-us.aliyuncs.com and workspace-scoped *.maas.aliyuncs.com URLs. Probably a separate issue rather than something for this PR.

Thanks!

[Vidit-Ostwal]

Looks correct for #7233. The factory only takes the native OpenAICompatibleCompletion path when _matches_provider_pattern returns true, so the qwen* gate was sending dashscope/deepseek-v3 (and the other compatible-mode families) to LiteLLM and dropping DASHSCOPE_BASE_URL. return True matches the other OpenAI-compatible providers and Alibaba's compatible-mode docs.

The new test hits the reported case (dashscope/deepseek-v3 + custom DASHSCOPE_BASE_URL). That's enough; the matcher is now unconditional, so parametrizing Kimi/GLM is optional. Asserting llm.model == "deepseek-v3" would be a cheap extra check that the prefix is stripped.

One leftover: the comment a few lines above still says (DeepSeek, Dashscope) restrict to their own model prefixes. After this change only DeepSeek does. Please update that so it doesn't contradict the new DashScope branch.

CodeRabbit is clean. Not behind main, so no rebase needed. Leave the default dashscope-intl URL alone — that's a separate follow-up.

[Vidit-Ostwal]

Leftover comment next to the DashScope matcher.

[Vidit-Ostwal]

The comment a few lines above still says (DeepSeek, Dashscope) restrict to their own model prefixes. After this change only DeepSeek does — please update that so it doesn't contradict this branch.