Description
Summary
Two behaviors combine into a silent breakage for international Alibaba Token Plan users:
- The provider migration (shipped around 2026-07-21, created
config.json.bak-before-alibaba-provider-rename-*) renamed/merged user providers into the idalibaba-token-planand deleted the user's duplicate (alibaba-token-plan-1). - The router (
src/router.ts:158-162) ignores the user's savedbaseUrlwhenever the registry entry lacksallowBaseUrlOverride— andalibaba-token-plan(Beijing) lacks it, whilealibaba-token-plan-intl(Singapore) has it.
Net effect: after the migration, config.json points at the saved international URL (token-plan.ap-southeast-1.maas.aliyuncs.com), but the router forces the Beijing URL (token-plan.cn-beijing.maas.aliyuncs.com). The international plan key is rejected there → every request fails with 401, with no warning that the configured baseUrl was discarded.
Registry asymmetry (src/providers/registry.ts)
| id | baseUrl | allowBaseUrlOverride |
|---|---|---|
alibaba-token-plan |
token-plan.cn-beijing... |
❌ (absent) |
alibaba-token-plan-intl |
token-plan.ap-southeast-1... |
✅ + baseUrlChoices |
Before/after migration (actual ~/.opencodex/config.json)
Before:
"alibaba-token-plan": { "baseUrl": "https://coding-intl.dashscope.aliyuncs.com/v1" },
"alibaba-token-plan-1": { "baseUrl": "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1" }After:
"alibaba-token-plan": { "baseUrl": "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1" }The saved URL survived, but router.ts resolves it back to Beijing at runtime.
Suggested fixes
- Honor the saved baseUrl: give
alibaba-token-planallowBaseUrlOverride: true+baseUrlChoices(Beijing/Singapore), mirroring the-intlentry — or make region a first-class field. - Fail loudly: when the router discards a user-configured
baseUrlbecause override isn't allowed, emit a warning. Silent ignoring is the footgun. - Migrations must not rename user provider ids into a registry id with different semantics (region, override policy). If consolidation is needed, preserve the resolved baseUrl or map to the id matching the saved URL's region.
Workaround (confirmed)
Rename the provider id to alibaba-token-plan-intl in config.json and re-prefix disabledModels/providerContextCaps. The international URL is then honored; the endpoint returns 200.
Environment
opencodex 2.7.40 (npm global), macOS arm64. Note: ocx update runs migrations unattended via the background service, so this class of breakage lands without user interaction.
Activity
github-actions commentedon Jul 25, 2026
Automated translation bookkeeping — detected language: English.
Ingwannu commentedon Jul 26, 2026
Confirmed against current
dev: this is a real routing regression.routedProviderConfig()honors a saved non-template URL only for template registry URLs or entries withallowBaseUrlOverride, whilealibaba-token-planstill lacks that opt-in. A migrated international URL is therefore silently replaced with the Beijing registry URL at request time.PR #459 tracks the root fix by making the token-plan endpoint choice explicit and preserving the saved resolved URL; PR #464 separately tracks the diagnostic warning when a pinned registry URL discards user configuration. Please keep using the
alibaba-token-plan-intlworkaround until the root fix is merged. I am keeping this issue open until the migration/routing regression test and the verified fix land ondev.docs(devlog): 260726 issue loop roadmap — 21 issues triaged, 3 phases…
feat(providers): add a provider-id reference rewriter
fix(providers): recover a config migrated across Alibaba regions
docs(devlog): 260726 issue loop roadmap — 21 issues triaged, 3 phases…
feat(providers): add a provider-id reference rewriter
fix(providers): recover a config migrated across Alibaba regions