Repository navigation
feat(models): qwen3.8/3.7 regions for all endpoints - #3532
Merged
Merged
Conversation
qwen3.8-max had no regions array, so only the default Singapore endpoint was reachable, and qwen3.7-flash was limited to Singapore and Beijing. Live probes against all four Model Studio endpoints show both models serve every region. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
steebchen
enabled auto-merge (squash)
August 11, 2026 00:14
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe Alibaba metadata updates ChangesAlibaba Qwen region updates
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
steebchen
added a commit
that referenced
this pull request
Aug 11, 2026
Follow-up to #3532, which covered only the Qwen 3.7/3.8 line. This sweeps the rest of the Alibaba catalogue. ## What was found Every Alibaba-hosted model was probed against all four Model Studio endpoints with that region's real key. 22 model/region pairs serve traffic but were not declared, and two mappings turned out to be dead everywhere they claim to work. **Regions added** | model | added | | --- | --- | | `deepseek-v4-pro`, `deepseek-v4-flash` | `eu-frankfurt` | | `kimi-k2.5` | `eu-frankfurt`, `us-virginia` | | `qwen-plus`, `qwen3-coder-flash`, `qwen3-vl-plus`, `qwen3.6-flash` | `eu-frankfurt` | | `qwen-flash` | `eu-frankfurt`, `us-virginia` | | `qwen3.5-397b-a17b` | `us-virginia` | | `qwen3.6-plus` | `us-virginia`, `cn-beijing` | | `qwen3.6-35b-a3b`, `glm-5.2` | `eu-frankfurt`, `us-virginia`, `cn-beijing` | | `qwen-coder-plus` | `singapore` | | `qwen-omni-turbo` | `singapore`, `cn-beijing` (had no `regions` array at all) | **Mappings deactivated** — both are unreachable in every region they declare, so any request routed to them fails: - `qwen-max-latest` — 403 `access_denied` in Singapore, 404 `model_not_found` in Beijing. Plain `qwen-max` still serves in both, so this is the dated alias being retired, not an outage. - `qwen2.5-vl-32b-instruct` — 403 `access_denied` on both hosts that would serve it, 404 elsewhere. **One region deliberately not added.** `qwen3.5-397b-a17b` answers in Frankfurt, but takes ~120s for a single token and returns garbage content (`"assistant"`), while tool calls and JSON output never return at all. `qwen3.6-flash` on the same host replies in 2.1s, and the same model in Singapore/US Virginia replies in 2–3s, so it is that deployment, not the endpoint or the model. Verified against both the workspace host and the shared `trial.` host. A comment on the mapping records why, so nobody adds it back from a naive availability probe — my own first probe recorded it as "OK" precisely because it had no timeout. ## Pricing New region entries carry the mapping's global list price, as in #3532 and as every other unverified Alibaba region entry already does. Where the Singapore entry defines pricing *tiers* (`qwen-flash`, `qwen3-coder-flash`, `qwen3-vl-plus`), the new international entries replicate that tier structure verbatim rather than inheriting the flat base price — otherwise long-context requests would bill at the short-context rate. ## Verification `pnpm format`, `pnpm build`, and the models + `alibaba-pricing` specs (307 tests) pass. A catalogue/live cross-check reports zero mismatches in both directions: every declared region serves, and every serving region is declared. Real e2e, one pass per region with `LLM_ALIBABA_API_KEY` pointed at that region's key (the seeded BYOK key only ever reads that slot): | region | new-variant cases | | --- | --- | | `singapore` | 17 passed / 0 failed | | `eu-frankfurt` | 132 passed / 0 failed | | `us-virginia` | 97 passed / 0 failed | | `cn-beijing` | 62 passed / 0 failed | The Frankfurt run also produced 9 failures for `qwen3.5-397b-a17b:eu-frankfurt` — that is the deployment described above, and the entry has since been removed. Remaining red in every run is unrelated: six provider-key registration cases for providers with no local key (AtlasCloud, AWS Mantle, Azure, Azure AI Foundry, ElevenLabs, Sakana AI), plus in the non-Singapore runs the two Alibaba key-registration cases, which validate `LLM_ALIBABA_API_KEY` against the Singapore host while that variable holds another region's key. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Expanded regional availability and pricing for multiple Qwen models, including deployments in Frankfurt, Virginia, Singapore, and Beijing. * Added Frankfurt availability for DeepSeek V4 Pro and V4 Flash. * Expanded Kimi K2.5 availability to Frankfurt and Virginia. * Expanded GLM-5.2 availability to Frankfurt, Virginia, and Beijing. * **Model Availability** * Qwen Max Latest and Qwen2.5-VL-32B-Instruct are scheduled for deactivation on August 11, 2026. * Updated availability notices for selected model endpoints. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <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.
Problem
qwen3.8-maxhad noregionsarray at all, so the only reachable Alibaba endpoint for it was the default Singapore one — even though Model Studio serves it from every region, including Frankfurt (which #3525 just wired up).qwen3.7-flashwas likewise limited to Singapore and Beijing.Change
Both mappings now declare all four regions:
singapore,eu-frankfurt,us-virginia,cn-beijing.qwen3.7-maxandqwen3.7-plusalready had all four, so the Qwen 3.7/3.8 line is now uniform.Availability was established by probing every model in the Alibaba catalogue against all four regional endpoints with that region's real key, not from the docs — the OpenAI-compatible
/modelslisting is unreliable here (it omitsqwen3.8-maxin every region, including Singapore where it demonstrably works).Pricing
The new region entries inherit the mapping's global (Singapore) prices, matching how every other unverified Alibaba region entry in the catalogue is expressed (e.g.
qwen3.7-max:us-virginia,qwen3.7-plus:cn-beijing). Alibaba's regional list prices are never above the global one, so no entry can bill below cost; the effect is that cheapest-region routing simply won't prefer these regions over Singapore until real regional prices are filled in.Verification
pnpm format,pnpm build, and the models/pricing unit specs (304 tests) pass.Real e2e per region — the seeded BYOK provider key always takes its token from
LLM_ALIBABA_API_KEY, so one run can only exercise one region's credentials; the suite was run four times, each with that variable pointed at the corresponding regional key:singaporeeu-frankfurtus-virginiacn-beijingEach run covers
qwen3.7-max,qwen3.7-plus,qwen3.7-flashandqwen3.8-maxpinned to that region, across basic completion, streaming, reasoning (all seven efforts), reasoning + streaming, JSON output, and tool calls.The remaining red in those runs is unrelated to this change: six provider-key registration cases for providers with no local key (AtlasCloud, AWS Mantle, Azure, Azure AI Foundry, ElevenLabs, Sakana AI), plus — in the three non-Singapore runs — the two Alibaba key-registration cases, which validate
LLM_ALIBABA_API_KEYagainst the Singapore host and therefore fail while that variable holds another region's key.🤖 Generated with Claude Code
Summary by CodeRabbit
qwen3.7-flashmodel to include Singapore, Frankfurt, Virginia, and Beijing.qwen3.8-maxmodel.