Skip to content

feat(providers): add Alibaba Cloud Token Plan provider - #35347

Closed
cudasuan wants to merge 1 commit into
NousResearch:mainfrom
cudasuan:feat/alibaba-token-plan-provider
Closed

feat(providers): add Alibaba Cloud Token Plan provider#35347
cudasuan wants to merge 1 commit into
NousResearch:mainfrom
cudasuan:feat/alibaba-token-plan-provider

Conversation

@cudasuan

Copy link
Copy Markdown

Summary

Add support for Alibaba Cloud Token Plan (Team Edition) — a subscription-based billing model with a separate API endpoint (token-plan.cn-beijing.maas.aliyuncs.com).

Docs: https://help.aliyun.com/zh/model-studio/token-plan-overview

Changes

  • auth.py: Register alibaba-token-plan in PROVIDER_REGISTRY with api_key auth type and base URL
  • providers.py: Add HermesOverlay with openai_chat transport + alias mappings
  • models.py: Add curated model list (qwen3.7-max, deepseek-v4-pro, kimi-k2.6, glm-5.1, MiniMax-M2.5, etc.)
  • doctor.py: Add health check for ALIBABA_TOKEN_PLAN_API_KEY / DASHSCOPE_API_KEY
  • model_metadata.py: Add provider prefix + URL-to-provider mapping
  • system_prompt.py: Extend model identity workaround to cover token-plan provider
  • plugins/model-providers/alibaba-token-plan/: Bundled plugin profile
  • tests/providers/test_plugin_discovery.py: Add spot-check for new provider

Aliases

alibaba_token_plan, alibaba-token, aliyun-token-plan, token-plan all resolve to alibaba-token-plan.

Testing

  • pytest tests/providers/test_plugin_discovery.py — 4 passed
  • Verified end-to-end with hermes send on weixin channel — LLM responds correctly

Add support for Alibaba Cloud Token Plan (Team Edition), a subscription-based
billing model hitting a separate endpoint (token-plan.cn-beijing.maas.aliyuncs.com).

Changes:
- Register 'alibaba-token-plan' in PROVIDER_REGISTRY (auth.py)
- Add provider overlay with openai_chat transport (providers.py)
- Add curated model list: qwen3.7-max, deepseek-v4-pro, kimi-k2.6, glm-5.1, etc.
- Add aliases: alibaba_token_plan, alibaba-token, aliyun-token-plan, token-plan
- Add doctor check for ALIBABA_TOKEN_PLAN_API_KEY / DASHSCOPE_API_KEY
- Add URL-to-provider mapping in model_metadata.py
- Extend system prompt model identity workaround to cover token-plan provider
- Add bundled plugin profile (plugins/model-providers/alibaba-token-plan/)
- Add spot-check in test_plugin_discovery.py

Docs: https://help.aliyun.com/zh/model-studio/token-plan-overview
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/plugins Plugin system and bundled plugins comp/cli CLI entry point, hermes_cli/, setup wizard labels May 30, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Note: This appears to be a resubmission of #33109 (same feature, closed 2026-05-28). If the prior PR was closed for specific reasons, please address that feedback in this PR description.

@oliver-mee

oliver-mee commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Thanks for picking this up, the wiring here looks clean and the transport call is right.

For context on who is commenting: I have been working on the Alibaba Token Plan metadata across the wider ecosystem. On models.dev I added the newest model to the Global Token Plan provider and created the separate alibaba-token-plan-cn provider (both merged), and I have an OpenClaw Token Plan provider in review. I have verified the Token Plan surface across both the Anthropic-compatible and OpenAI-compatible endpoints, so the notes below come from confirmed behaviour rather than docs alone.

On the open question from @alt-glitch about #33109: this PR already resolves the two reasons that one was closed. #33109 was self-closed for branch drift and for leaving the transport choice undocumented (it defaulted to the Anthropic-compatible surface, which the author flagged as needing to be "documented more clearly"). This PR settles that by using openai_chat on /compatible-mode/v1, which is the consistent choice: every other Alibaba surface in the repo (alibaba, alibaba-coding-plan) is openai_chat, and the gateway returns reasoning in reasoning_content on that surface as expected. So the transport is no longer ambiguous, and the provider is cleanly separated from alibaba-coding-plan.

Two suggestions:

1. Ship both regions, with Global as the default. Token Plan is two separate gateways (Singapore and Beijing) with different consoles, catalogs, and keys, so it is cleanest to model them the way the repo already models MiniMax (minimax / minimax-cn), and the way models.dev now carries both Token Plan providers. Concretely:

  • Default alibaba-token-plan to the Global / Singapore endpoint https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1. This also matches how the repo defaults alibaba to dashscope-intl rather than the CN host. That is a one-line host swap in hermes_cli/auth.py (registry inference_base_url), plugins/model-providers/alibaba-token-plan/__init__.py (base_url), hermes_cli/doctor.py (health-check URL), and the comment in hermes_cli/models.py.
  • Add a second provider alibaba-token-plan-cn for https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1. This is the same wiring applied a second time (registry entry, overlay, aliases, doctor entry, metadata prefix plus URL map, plugin profile, catalog), so it is mechanical rather than new logic. Both hosts should be in the agent/model_metadata.py URL-to-provider map so each region resolves to its own provider.

2. Add qwen3.7-plus to the catalog. It is the plan's default model and is on the models.dev Token Plan provider, but it is missing from the list here (currently 11). One line in hermes_cli/models.py:

    "alibaba-token-plan": [
        "qwen3.7-max",
        "qwen3.7-plus",
        "qwen3.6-plus",
        ...

I've gone ahead and left a PR on your branch with both changes: cudasuan#1. It targets feat/alibaba-token-plan-provider, so if you merge it the changes fold straight into this PR (no action needed beyond the merge). It defaults the provider to Global/Singapore, adds the alibaba-token-plan-cn provider, and adds qwen3.7-plus. Tests (plugin-discovery, provider-groups, api-key suites) pass and ruff is clean. If you'd rather not take it, no worries at all, happy to fold it into a fresh PR and credit your work here instead.

(Drafted with AI assistance and reviewed by me before posting.)

@oliver-mee

Copy link
Copy Markdown
Contributor

Opened #52915, which carries this work forward onto current main. It keeps your provider commit with your authorship, and adds the region split (Global default plus a China provider) and the catalog updates I had proposed back to this branch in cudasuan#1. Since that follow-up hadn't had a chance to land here, the new PR brings the whole thing to a branch the maintainers can merge directly. Happy to keep crediting you, and if you'd rather drive it from here just say so.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the careful provider wiring and for documenting the Token Plan endpoint and transport choice.

This automated hermes-sweeper review is closing this under the standing in-tree provider-integration policy.

  • The PR adds a new Alibaba-specific bundled profile at plugins/model-providers/alibaba-token-plan/__init__.py and wires its endpoint, credentials, catalog, and aliases through core provider surfaces.
  • Current policy in AGENTS.md:797-810 requires integrations for third-party vendor products to ship as standalone plugin repositories, installed under ~/.hermes/plugins/ or via a pip entry point. This is a coupling and maintenance decision, not a judgment of the implementation quality.
  • The supported extension route already exists: website/docs/developer-guide/model-provider-plugin.md:9-23 documents user model-provider plugins, and hermes_cli/auth.py:447-477 auto-registers API-key provider profiles and aliases.

Please publish the Alibaba Token Plan integration as a standalone model-provider plugin repository and share it in #plugins-skills-and-skins.


Closed as not-planned per standing maintainer policy (in-tree-provider-integration). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.

@teknium1 teknium1 closed this Jul 13, 2026
@teknium1 teknium1 added sweeper:not-planned Sweeper: closed per standing maintainer policy (design direction) sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard comp/plugins Plugin system and bundled plugins P3 Low — cosmetic, nice to have sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:not-planned Sweeper: closed per standing maintainer policy (design direction) sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants