Summary
First-class support for the Alibaba Cloud Model Studio Token Plan (Team Edition) as a qwen-token-plan provider in the bundled qwen plugin.
Problem to solve
The qwen plugin already covers the Qwen Coding Plan, Standard pay-as-you-go, and Portal/OAuth, but not the Token Plan (Team Edition). The Token Plan is a separate prepaid subscription that Alibaba steers coding and agent users toward, and it ships its own recommended OpenClaw config. Today a Token Plan user has to hand-roll a custom provider (base URL, model list, thinking handling), which is fiddly and easy to get wrong, and it is not discoverable through onboarding.
Proposed solution
Add qwen-token-plan to the qwen plugin on the OpenAI-compatible gateway (/compatible-mode/v1), with two regions (Global / Singapore and CN / Beijing) selected by a base-URL swap, env var QWEN_TOKEN_PLAN_API_KEY, the plan's full chat-model catalogue, and reasoning. Reuse the existing qwen transport and thinking machinery so it behaves like the sibling Coding Plan and Standard providers. Keep bailian-token-plan (the id Alibaba's own recommended config uses) as a compatibility alias. Result: openclaw onboard --auth-choice qwen-token-plan (or qwen-token-plan-cn) gives a working provider with no manual config.
Alternatives considered
- A hand-written custom provider in
openclaw.json. Works, but error-prone and not discoverable through onboarding.
- The Anthropic-compatible surface of the same gateway (
/apps/anthropic). Also works, but the OpenAI-compatible surface keeps the provider consistent with the sibling qwen providers and reuses their thinking handling, so it is the lower-divergence choice.
Impact
- Affected: OpenClaw users on the Alibaba Token Plan (Team Edition), both Global and CN.
- Severity: blocks zero-config onboarding for a supported Alibaba product.
- Frequency: every Token Plan user setting up OpenClaw.
- Consequence: manual provider config with several easy-to-miss details (region base URL, model ids, reasoning), instead of a one-line onboard.
Evidence/examples
Additional information
I have an implementation ready and will open a PR that links this issue. This would be my first contribution to the repo.
Summary
First-class support for the Alibaba Cloud Model Studio Token Plan (Team Edition) as a
qwen-token-planprovider in the bundled qwen plugin.Problem to solve
The qwen plugin already covers the Qwen Coding Plan, Standard pay-as-you-go, and Portal/OAuth, but not the Token Plan (Team Edition). The Token Plan is a separate prepaid subscription that Alibaba steers coding and agent users toward, and it ships its own recommended OpenClaw config. Today a Token Plan user has to hand-roll a custom provider (base URL, model list, thinking handling), which is fiddly and easy to get wrong, and it is not discoverable through onboarding.
Proposed solution
Add
qwen-token-planto the qwen plugin on the OpenAI-compatible gateway (/compatible-mode/v1), with two regions (Global / Singapore and CN / Beijing) selected by a base-URL swap, env varQWEN_TOKEN_PLAN_API_KEY, the plan's full chat-model catalogue, and reasoning. Reuse the existing qwen transport and thinking machinery so it behaves like the sibling Coding Plan and Standard providers. Keepbailian-token-plan(the id Alibaba's own recommended config uses) as a compatibility alias. Result:openclaw onboard --auth-choice qwen-token-plan(orqwen-token-plan-cn) gives a working provider with no manual config.Alternatives considered
openclaw.json. Works, but error-prone and not discoverable through onboarding./apps/anthropic). Also works, but the OpenAI-compatible surface keeps the provider consistent with the sibling qwen providers and reuses their thinking handling, so it is the lower-divergence choice.Impact
Evidence/examples
bailian-token-plan).Additional information
I have an implementation ready and will open a PR that links this issue. This would be my first contribution to the repo.