feat(auth): add Singapore Token Plan region - #7280
Conversation
wenshao
left a comment
wenshao
left a comment
There was a problem hiding this comment.
Reviewed. Suggestions are inline. Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
— qwen3.8-max-preview via Qwen Code /review
| expect( | ||
| tokenPlanProvider.ownsModel?.({ | ||
| id: 'custom-model', | ||
| baseUrl: 'https://custom.example.com/v1', | ||
| envKey: TOKEN_PLAN_ENV_KEY, | ||
| }), | ||
| ).toBe(false); |
There was a problem hiding this comment.
[Suggestion] The ownsModel negative case only exercises the baseUrl mismatch branch; the envKey guard is never independently tested. — Concrete cost: if a future edit removes model.envKey === TOKEN_PLAN_ENV_KEY && from ownsModel, all three existing tests still pass (both positives use the correct envKey; the sole negative fails on baseUrl). A model registered under a different provider's API key but sharing a Token Plan base URL would be incorrectly claimed by the token-plan provider.
| expect( | |
| tokenPlanProvider.ownsModel?.({ | |
| id: 'custom-model', | |
| baseUrl: 'https://custom.example.com/v1', | |
| envKey: TOKEN_PLAN_ENV_KEY, | |
| }), | |
| ).toBe(false); | |
| expect( | |
| tokenPlanProvider.ownsModel?.({ | |
| id: 'custom-model', | |
| baseUrl: 'https://custom.example.com/v1', | |
| envKey: TOKEN_PLAN_ENV_KEY, | |
| }), | |
| ).toBe(false); | |
| expect( | |
| tokenPlanProvider.ownsModel?.({ | |
| id: 'token-model', | |
| baseUrl: TOKEN_PLAN_CHINA_BASE_URL, | |
| envKey: 'SOME_OTHER_API_KEY', | |
| }), | |
| ).toBe(false); |
— qwen3.8-max-preview via Qwen Code /review
|
Thanks, good catch. I added a separate negative case for a valid Token Plan base URL with a non-Token Plan env key, and the focused test passes. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
— qwen3.7-max via Qwen Code /review
Local verification report (Linux) — PR #7280I built and ran this branch locally on Linux (the PR is marked "Windows only"), including a real Verdict: the feature itself is correct and cleanly implemented — but it breaks 3 existing CLI auth tests that CI cannot see. One of those 3 is a genuine behaviour regression, not just a navigation update. I'd hold the merge until those are resolved; everything else checks out. Environment / what "BASE" means here
✅ What works1. The Region step is real and correctly wired. Live
Same path on the merge-base goes straight to API Key — the differential is clean:
2. Selecting Singapore genuinely routes to
I also confirmed both endpoints are live from Linux, matching your Windows check: 3. Existing China users are not disturbed — verified, not assumed. This was my main upgrade risk:
4. Runtime provider detection needs no change — your "out of scope" note is correct. 5. 42/42 compiled-build differential checks pass (region step, base-URL resolution incl. trailing-slash and unknown-URL fallback, per-region prefixes, install plan, ownership, credential matching, no collision with Coding Plan, DashScope routing):
6. Suites and static checks green: core providers 145/145, vscode-ide-companion services 118/118, 🔴 Finding 1 (blocking): 3
|
BASE (102c6921) |
PR (6e21220f) |
|
|---|---|---|
AuthDialog.test.tsx |
1 failed | 24 passed | 4 failed | 21 passed |
The 1 shared failure (drives API key provider steps from endpoint options metadata) is pre-existing and fails on the merge-base too — not yours. The 3 new ones are all Token Plan.
Why CI is green: AuthDialog.test.tsx:238-239
const isUnreliableTuiInputEnvironment =
process.platform === 'win32' || process.env['CI'] === 'true';
const itWhenTuiInputReliable = isUnreliableTuiInputEnvironment ? it.skip : it;The CI log for this PR confirms it: ✓ src/ui/auth/AuthDialog.test.tsx (25 tests | 18 skipped). All three broken tests are in the skipped set. Worth knowing generally: any Token Plan / Coding Plan wizard-flow regression is invisible to CI, so this PR's green tick is not evidence these flows still work.
1a — navigation (2 tests, expected consequence of the feature)
should submit Token Plan through the shared subscription handler and should return from Token Plan API key input to Token Plan selection assert Step 1/2 · API Key; Token Plan is now a 3-step wizard. These just need to walk the new step, mirroring the Coding Plan idiom already at line ~889:
await pressEnterAndWaitFor(stdin, lastFrame, 'Alibaba ModelStudio · Step 1/3 · Region');
// Keep the default China (Beijing) region.
await pressEnterAndWaitFor(stdin, lastFrame, 'Alibaba ModelStudio · Step 2/3 · API Key');
await typeText(stdin, 'sk-token-plan');
await pressEnterAndWaitFor(stdin, lastFrame, 'Alibaba ModelStudio · Step 3/3 · Model IDs');For the back-navigation test, note Esc now returns API Key → Region, and a second Esc returns to the Token Plan selection. I applied this and both tests pass.
1b — ownership semantics changed (1 test — this one is a real regression)
should pre-fill the Model IDs step with previously saved custom model IDs fails fast (403 ms, reaches Step 3/3 and finds the input empty), so it is not a navigation problem. Its fixture is:
{
id: 'my-custom-token-model',
name: '[ModelStudio Token Plan] my-custom-token-model',
baseUrl: 'https://dashscope.aliyuncs.com/compatible-mode/v1', // <- not a Token Plan preset URL
envKey: 'BAILIAN_TOKEN_PLAN_API_KEY',
}Moving modelNamePrefix to a function forced an explicit ownsModel, which switched the match from name prefix to a base-URL allow-list. A saved model whose baseUrl isn't one of the two preset endpoints is therefore no longer owned. Two consequences for such users:
- the
/authwizard no longer pre-fills their saved custom model IDs (what the test catches); and prepend-and-remove-ownedno longer removes those entries on reinstall, so they linger as stale duplicates alongside freshly installed ones.
I confirmed the root cause by widening ownsModel to also accept the legacy name prefix — all 25 AuthDialog tests and all 145 core provider tests pass, including this PR's own ownsModel assertions (the custom-model case has no name, so it still correctly returns false):
ownsModel: (model) =>
model.envKey === TOKEN_PLAN_ENV_KEY &&
((typeof model.baseUrl === 'string' &&
(model.baseUrl === TOKEN_PLAN_CHINA_BASE_URL ||
model.baseUrl === TOKEN_PLAN_GLOBAL_BASE_URL)) ||
(typeof model.name === 'string' &&
model.name.startsWith('[ModelStudio Token Plan]'))),Your call which way to go — coding-plan already uses the baseUrl-only form, so deliberately accepting the narrower semantics and updating the fixture is defensible. But it should be a conscious decision recorded in the PR, not a silent side effect, since it changes behaviour for already-installed users.
🟡 Non-blocking
2. The Singapore URL value has no test coverage in core. Mutation check: I changed TOKEN_PLAN_GLOBAL_BASE_URL to the China host and all 68 core provider tests still passed — they reference the constant symbolically throughout. The literal is only asserted in the vscode-ide-companion test, which has its own separate copy of the string, so the two copies could silently drift apart. One literal assertion in the core test would close this. (For contrast, 5 of my 7 mutations — dropping the Global/Intl prefix branch, removing the SG option, dropping ownsModel, and both vscode mutations — were caught.)
3. baseUrlStepTitle: 'Region' is untested. Removing it leaves every test green, yet it's the user-visible step title the PR description highlights.
4. The PR description overstates the VS Code half. It says the change "mirrors the same region support in the VS Code companion subscription-plan definitions so both auth paths generate Token Plan model configs for the selected region." In practice getSubscriptionPlanConfig('token', …) has zero production callers — the only one is settingsWriter.ts:320, hardcoded to 'coding', and read-back is hard-gated to coding at settingsWriter.ts:633. The VS Code interactive auth QuickPick is driven by core's ALL_PROVIDERS (AuthMessageHandler.ts:167-283, reading uiLabels.baseUrlStepTitle at :273), so the Region step there comes from your core preset change, not from subscriptionPlanDefinitions.ts. The regions array is still worth keeping — it makes findSubscriptionPlanByConfig recognise the Singapore endpoint consistently with China — but the "both auth paths" wording should be corrected so future readers don't assume a second flow exists.
Summary
The core design is right, mirrors alibaba-coding-plan.ts closely, and the backward-compatibility story holds up under a real upgrade test. Please fix the three AuthDialog tests — and decide explicitly on the ownsModel semantics in 1b — and I'm happy to approve.
中文版本
本地验证报告（Linux）— PR #7280
我在 Linux 上完整构建并运行了这个分支（PR 标注为仅在 Windows 测试过），包括真实的 /auth 全流程走查、与 merge-base 的编译产物对比，以及针对存量 Token Plan 用户的升级模拟。
结论：功能本身实现正确、也很干净，但它破坏了 3 个现有的 CLI auth 测试，而 CI 在结构上无法发现这一点。其中 1 个是真实的行为回归，不只是导航步骤需要更新。 建议先解决这几点再合并；其余部分都没有问题。
环境说明： PR head 6e21220f，merge-base 102c6921，Linux x86_64，Node 22，完整 npm run build + bundle。这里的 BASE 指 merge-base 的编译产物 —— 我核对过它的 tokenPlanProvider 代码块和模型列表与 102c6921 源码完全一致，因此下面所有 A/B 对比都只隔离了本次改动。所有测试都跑在干净的 PR 工作树上（git status 在 6e21220f 上是干净的）。
✅ 验证通过的部分
-
Region 步骤真实可用且接线正确。 实际
/auth→ Alibaba ModelStudio → Token Plan 会出现区域选择；在 merge-base 上同样路径直接进入 API Key，差分对比很干净（见上方前两张截图）。 -
选择新加坡确实路由到
ap-southeast-1。 完成向导后settings.json里 15 个模型全部指向新加坡 endpoint 并带Global/Intl前缀，providerMetadata.token-plan.baseUrl也是新加坡 URL。用假 key 发起真实请求返回的 401，其帮助链接是国际站域名（www.alibabacloud.com而非help.aliyun.com）—— 这证明请求真的打到了新加坡节点，而不是回退到北京。我也从 Linux 侧确认两个 endpoint 都在线，与你在 Windows 上的检查一致。 -
存量中国区用户不受影响 —— 这点我实测过，不是推断。 这是我最关注的升级风险：
useProviderUpdates比对的是模板哈希，中国区模板只要有任何扰动，所有存量 Token Plan 用户都会看到一次莫名其妙的"配置有更新"提示。结果是不会：中国区模型配置在 BASE 与 PR 之间深度相等，版本哈希完全一致。实测层面，我用 merge-base 的编译代码生成了一份"PR 之前"的中国区安装状态，再用 PR 构建打开它 —— 没有更新提示、不需要重新认证、前缀保持不变，事后settings.json中所有 Token Plan 字段逐字节一致（只有$version/ui这类杂项变化）。 -
运行时 provider 检测确实不需要改 —— 你"不在范围内"的判断是对的。
isDashScopeProvider已经通用匹配token-plan.<region>.maas.aliyuncs.com，我确认新加坡主机能被识别，而token-plan.evil.com仍然不会被误判。 -
42/42 编译产物差分检查全部通过（region 步骤、base URL 解析含尾部斜杠与未知 URL 回退、各区域前缀、install plan、归属判定、凭据匹配、与 Coding Plan 不冲突、DashScope 路由）。
-
测试套件与静态检查全绿： core providers 145/145，vscode-ide-companion services 118/118，
npm run lint干净，tsc --noEmit干净，Prettier 干净。
🔴 发现 1（阻塞）：3 个 AuthDialog 测试被破坏，且 CI 在结构上无法发现
packages/cli/src/ui/auth/AuthDialog.test.tsx 未被本 PR 修改，两侧文件完全相同，所以这是一次干净的 A/B：BASE 是 1 失败 / 24 通过，PR 是 4 失败 / 21 通过。那 1 个共同失败（drives API key provider steps from endpoint options metadata）在 merge-base 上同样失败，属于既有问题，与你无关。新增的 3 个全部是 Token Plan 相关。
CI 为什么是绿的： AuthDialog.test.tsx:238-239 中，itWhenTuiInputReliable 在 CI=true 时等于 it.skip。本 PR 的 CI 日志印证了这一点：✓ src/ui/auth/AuthDialog.test.tsx (25 tests | 18 skipped)，三个被破坏的测试都在跳过集合里。这里有个更普遍的提醒：任何 Token Plan / Coding Plan 向导流程的回归对 CI 都是不可见的，所以本 PR 的绿勾并不能证明这些流程仍然正常。
1a — 导航（2 个测试，属于功能的预期后果）： should submit Token Plan through the shared subscription handler 和 should return from Token Plan API key input to Token Plan selection 断言的是 Step 1/2 · API Key，而 Token Plan 现在是 3 步向导。按第 889 行附近 Coding Plan 已有的写法补上新步骤即可（注意返回逻辑：Esc 现在是 API Key → Region，再按一次 Esc 才回到 Token Plan 选择）。我本地改完后这两个测试都通过。
1b — 归属语义变化（1 个测试，这个是真实回归）： should pre-fill the Model IDs step with previously saved custom model IDs 是快速失败（403 毫秒，已经走到 Step 3/3，只是输入框是空的），因此不是导航问题。它的 fixture 里保存的模型 baseUrl 是 https://dashscope.aliyuncs.com/compatible-mode/v1，并不是 Token Plan 的预设 endpoint。
把 modelNamePrefix 改成函数后必须显式提供 ownsModel，这就把匹配方式从名称前缀换成了 base URL 白名单。于是 baseUrl 不在两个预设 endpoint 之列的已保存模型不再被认作本 provider 所有。对这类用户有两个后果：一是 /auth 向导不再预填他们保存的自定义模型 ID（即该测试捕获的现象）；二是 prepend-and-remove-owned 不再清理这些条目，重装后它们会作为陈旧重复项与新装模型并存。
我通过把 ownsModel 放宽到同时接受旧的名称前缀，验证了这就是根因 —— 25 个 AuthDialog 测试和 145 个 core provider 测试全部通过，包括本 PR 自己的 ownsModel 断言（custom-model 那条没有 name，仍然正确返回 false）。具体写法见英文版代码块。
怎么选由你们定：coding-plan 本来就是只按 baseUrl 匹配的写法，所以有意识地接受这个更窄的语义、同时更新 fixture 也完全说得通。但这应该是一个明确记录在 PR 里的决定，而不是一个静默的副作用，因为它改变了已安装用户的行为。
🟡 非阻塞
-
新加坡 URL 的取值在 core 侧没有测试覆盖。 变异测试：我把
TOKEN_PLAN_GLOBAL_BASE_URL改成中国区主机，68 个 core provider 测试依然全过 —— 因为测试全程是符号化引用该常量的。这个字面量只在 vscode-ide-companion 的测试里被断言，而那边有一份独立的字符串副本，两份副本可能悄悄不一致。在 core 测试里加一条字面量断言就能补上。（作为对照，我 7 个变异里有 5 个被抓到：去掉 Global/Intl 前缀分支、移除 SG 选项、删掉ownsModel，以及两个 vscode 变异。） -
baseUrlStepTitle: 'Region'没有测试。 把它删掉所有测试依然全绿，但它正是 PR 描述里强调的、用户可见的步骤标题。 -
PR 描述夸大了 VS Code 那一半的作用。 描述称该改动"在 VS Code companion 的 subscription-plan 定义中同步加入同样的区域支持，确保两个认证路径都会根据所选区域生成 Token Plan model config"。实际上
getSubscriptionPlanConfig('token', …)没有任何生产调用方 —— 唯一的调用点是settingsWriter.ts:320，写死为'coding'，而读回路径在settingsWriter.ts:633也硬性限定为 coding。VS Code 交互式认证的 QuickPick 由 core 的ALL_PROVIDERS驱动（AuthMessageHandler.ts:167-283，在 :273 读取uiLabels.baseUrlStepTitle），所以那里的 Region 步骤来自你的 core preset 改动，而不是subscriptionPlanDefinitions.ts。regions数组仍然值得保留 —— 它让findSubscriptionPlanByConfig能像识别中国区一样识别新加坡 endpoint —— 但"两个认证路径"的措辞建议修正，以免后来的读者误以为存在第二条流程。
小结
核心设计是对的，与 alibaba-coding-plan.ts 保持了高度一致，向后兼容性在真实升级测试下也站得住。麻烦修复这三个 AuthDialog 测试，并就 1b 的 ownsModel 语义做一个明确决定，之后我很乐意 approve。
|
Thanks for the thorough Linux verification. I agree with preserving the legacy Token Plan ownership semantics rather than narrowing this PR to baseUrl-only ownership. I updated I also adjusted the PR description to avoid overstating the VS Code companion path. Locally verified with:
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
— qwen3.7-max via Qwen Code /review
|
@qwen-code /review |
| _Qwen Code review request accepted. Review is queued in [workflow run](https://github.com/QwenLM/qwen-code/actions/runs/29797459529)._ |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed. Not reviewed: coverage — could not read the agents' transcripts (no subagent transcripts at /home/github-runner/actions-runner-2/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-2--work-qwen-code-qwen-code/subagents/12707871-0a9b-4ce4-b5a1-0ca3a71c73c9 (ENOENT: no such file or directory, scandir '/home/github-runner/actions-runner-2/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-2--work-qwen-code-qwen-code/subagents/12707871-0a9b-4ce4-b5a1-0ca3a71c73c9'). The harness writes one per agent; if there are none, either no agents ran or the harness could not write them.), so this run cannot show that any of the diff was read. Not reviewed: verification — could not check that Step 4 and Step 5 ran (no subagent transcripts at /home/github-runner/actions-runner-2/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-2--work-qwen-code-qwen-code/subagents/12707871-0a9b-4ce4-b5a1-0ca3a71c73c9 (ENOENT: no such file or directory, scandir '/home/github-runner/actions-runner-2/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-2--work-qwen-code-qwen-code/subagents/12707871-0a9b-4ce4-b5a1-0ca3a71c73c9'). The harness writes one per agent; if there are none, either no agents ran or the harness could not write them.).
— qwen3.7-max via Qwen Code /review
|
Hi @wenshao we need your review :-) |
|
@qwen-code /review |
Code Review —
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
— qwen3.7-max via Qwen Code /review
| modelNamePrefix: 'ModelStudio Token Plan for Global/Intl', | ||
| }, | ||
| ], | ||
| usageDocumentationUrl: TOKEN_PLAN_CHINA_DOC_URL, |
There was a problem hiding this comment.
[Suggestion] usageDocumentationUrl is hardcoded to the China Aliyun console URL at the plan level, so Global/International users receive the Chinese documentation link instead of the international one.
Failure scenario: A Singapore/International user configures Token Plan via VS Code. getSubscriptionPlanConfig('token', CodingPlanRegion.GLOBAL) correctly returns TOKEN_PLAN_GLOBAL_DOC_URL for documentationUrl and apiKeyUrl (both per-region), but returns TOKEN_PLAN_CHINA_DOC_URL for usageDocumentationUrl because it reads the plan-level field directly. The user clicks "usage documentation" and lands on bailian.console.aliyun.com/cn-beijing instead of the international console.
Note: the SubscriptionPlanRegionConfig interface lacks a usageDocumentationUrl field, so per-region resolution isn't structurally available yet. Consider adding it (mirroring how documentationUrl and apiKeyUrl are per-region) or falling back to the region's documentationUrl in getSubscriptionPlanConfig.
— qwen3.7-max via Qwen Code /review
|
@qwen-code /triage |
|
Thanks for the PR! Template looks good ✓ Problem: observed bug with solid evidence. #7334 documents a concrete reproduction (background subagent completes after the parent turn ends → the model's final Direction: aligned. Delivering a background agent's final reply back to the originating Channel chat is squarely within the daemon/channels feature area, which is under active development. It correctly preserves the #7223 isolation (the internal Size: cross-package ( Approach: the scope feels right and the design is the obvious one — it mirrors the existing Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测到的 bug，证据充分。#7334 给出了具体复现（后台 subagent 在父请求结束后才完成 → 模型最终的 方向：对齐。把后台 agent 的最终回复投递回发起会话的 Channel，完全属于 daemon/channels 功能领域，且该领域正在活跃开发。它正确保留了 #7223 的隔离（内部 规模：跨包（ 方案：范围合理，设计也是最自然的一种——完全复刻现有 进入代码审查 🔍 — Qwen Code · qwen3.7-max Reviewed at |
Code ReviewIndependent proposal: to add Singapore region to Token Plan, I would change Comparison with the diff: the PR does exactly this. The implementation is a near-mirror of the Coding Plan provider's region support — same No critical blockers found. No AGENTS.md violations. The code is straightforward and follows established conventions. Tests: all pass —
Real-Scenario Testing (tmux)Built the PR branch ( Token Plan → Region step (new): Selecting Singapore → API Key step: Esc from API Key → back to Region: Esc from Region → back to Access Method: China default path also verified: selecting Token Plan → China (Beijing) is the default highlight → Enter → Step 2/3 API Key. Existing China users see no disruption. 中文说明代码审查独立方案： 要为 Token Plan 添加新加坡区域，我会将 与 diff 对比： PR 完全这样做了。实现几乎是 Coding Plan provider 区域支持的镜像。唯一超出 Coding Plan 模式的是 未发现关键阻塞问题。未发现 AGENTS.md 违规。代码简洁，遵循既有惯例。 测试： 全部通过。 真实场景测试 (tmux)构建了 PR 分支并在 tmux 中驱动 — Qwen Code · qwen3.7-max Reviewed at |
|
Confidence: 4/5 — clean implementation that mirrors the established Coding Plan region pattern; the only reservation is that the AuthDialog wizard-flow tests remain CI-invisible (pre-existing gap, not this PR's fault). This is a textbook "extend the existing pattern" PR. My independent proposal and the actual diff are essentially the same thing — change The tmux run confirms the feature works end-to-end: Region step appears, both regions route correctly, Esc back-navigation walks the full chain (API Key → Region → Access Method), and China remains the default. The previous review's three broken AuthDialog tests are fixed in this head — navigation updated for the 3-step wizard, and the ownership negative case (valid Token Plan URL + wrong env key → One non-blocking note: the 18 skipped AuthDialog tests (TUI-input-reliable set) mean wizard-flow regressions are structurally invisible to CI. That's a pre-existing gap worth tracking separately, not a reason to hold this PR. LGTM, shipping it. ✅ 中文说明置信度：4/5 — 干净的实现，完全镜像了既有的 Coding Plan 区域模式；唯一的保留是 AuthDialog 向导流程测试在 CI 中不可见（已有缺口，非本 PR 造成）。 这是一个教科书式的"扩展现有模式"PR。我的独立方案和实际 diff 基本一致。作者还处理了我担心的向后兼容边界情况：现有 Token Plan 用户保存的配置使用旧的名称前缀所有权模型，新的 tmux 运行确认功能端到端可用：Region 步骤正确显示，两个区域路由正确，Esc 回退走完整链路，中国区保持默认。之前审查中三个失败的 AuthDialog 测试已在此 head 中修复。 非阻塞备注：18 个跳过的 AuthDialog 测试意味着向导流程回归在 CI 中结构性不可见。这是值得单独跟踪的已有缺口，不是扣留本 PR 的理由。 — Qwen Code · qwen3.7-max Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
|
Released in v0.20.1. |
4 participants
What this PR does
Adds China and Singapore (International) region choices to the Alibaba ModelStudio Token Plan provider used by
/auth, while keeping the existing China endpoint as the backward-compatible default. It also updates the VS Code companion subscription-plan definitions so Token Plan metadata and config lookup recognize the Singapore endpoint consistently.Why it's needed
Fixes #7252. Token Plan users with an international Alibaba Cloud setup need to use
token-plan.ap-southeast-1.maas.aliyuncs.com, but the Token Plan preset only exposed the China Beijing endpoint, so/authcould not select the Singapore/International Token Plan region.Reviewer Test Plan
How to verify
Run the focused core provider tests and confirm Token Plan defaults to the China endpoint, can resolve/build models for the Singapore endpoint, matches credentials for both registered Token Plan base URLs, and owns models from registered endpoints while preserving legacy Token Plan name-prefix ownership. Run the VS Code companion subscription-plan test and confirm Token Plan defaults to China while supporting
CodingPlanRegion.GLOBALwith the Singapore endpoint and global model-name prefix. On a reliable TUI platform, run the AuthDialog Token Plan flow tests and confirm the wizard navigates Region -> API Key -> Model IDs, with Esc returning from API Key to Region and then to Token Plan selection. I also verified the Singapore endpoint responds without an API key by calling/compatible-mode/v1/modelsand receiving the expected401 InvalidApiKey; this confirms the endpoint is live enough to add, but does not validate a real international Token Plan subscription.Evidence (Before & After)
Before: Token Plan had a single fixed base URL,
https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1, so no region step was shown for/auth. After: Token Plan exposesChina (Beijing)andSingapore (International)region options,Regionis used as the base URL step title, model display names use the regional prefix, and provider matching recognizes both Token Plan endpoints. Endpoint check:curl.exe -i --max-time 15 https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1/modelsreturnedHTTP/1.1 401 UnauthorizedwithInvalidApiKey/No API-key provided.Tested on
Environment (optional)
Windows PowerShell, Node/Vitest from the repo workspace.
Risk & Scope
token-plan.<region>.maas.aliyuncs.comgenerically.TOKEN_PLAN_BASE_URLexport remains as an alias for the China endpoint, preserving the previous default behavior.Linked Issues
Closes #7252
中文说明
What this PR does
这个 PR 为
/auth使用的 Alibaba ModelStudio Token Plan provider 增加了中国区和新加坡（国际）区两个区域选项，同时保留现有中国区 endpoint 作为向后兼容的默认值。它也更新了 VS Code companion 的 subscription-plan 定义，使 Token Plan 的 metadata 和配置查找可以一致识别新加坡 endpoint。Why it's needed
修复 #7252。使用阿里云国际站配置的 Token Plan 用户需要使用
token-plan.ap-southeast-1.maas.aliyuncs.com，但当前 Token Plan preset 只暴露了中国北京 endpoint，因此/auth里无法选择新加坡/国际 Token Plan 区域。Reviewer Test Plan
How to verify
运行聚焦的 core provider 测试，确认 Token Plan 默认使用中国区 endpoint，可以为新加坡 endpoint resolve/build models，可以匹配两个已注册 Token Plan base URL 的 credentials，并且可以识别已注册 endpoint 下的 Token Plan models，同时保留旧版 Token Plan name-prefix ownership。运行 VS Code companion 的 subscription-plan 测试，确认 Token Plan 默认使用中国区，同时在
CodingPlanRegion.GLOBAL下支持新加坡 endpoint 和国际区 model-name prefix。在可靠的 TUI 平台上运行 AuthDialog Token Plan flow 测试，确认 wizard 按 Region -> API Key -> Model IDs 导航，并且 Esc 会先从 API Key 回到 Region，再回到 Token Plan 选择。我还通过调用/compatible-mode/v1/models验证新加坡 endpoint 在没有 API key 时会返回预期的401 InvalidApiKey；这说明 endpoint 已经在线，足以加入配置，但不代表我验证了真实的国际 Token Plan 订阅。Evidence (Before & After)
Before：Token Plan 只有一个固定 base URL，即
https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1，所以/auth不会展示区域选择步骤。After：Token Plan 暴露China (Beijing)和Singapore (International)两个区域选项，base URL 步骤标题使用Region，模型显示名会根据区域使用不同 prefix，并且 provider matching 可以识别两个 Token Plan endpoints。Endpoint check：curl.exe -i --max-time 15 https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1/models返回了HTTP/1.1 401 Unauthorized，响应中包含InvalidApiKey/No API-key provided.。Tested on
Environment (optional)
Windows PowerShell，使用仓库 workspace 里的 Node/Vitest。
Risk & Scope
token-plan.<region>.maas.aliyuncs.com。TOKEN_PLAN_BASE_URLexport 仍然保留为中国区 endpoint 的 alias，保留之前的默认行为。Linked Issues
Closes #7252