[Bug]: Stale provider registries in Ekko Studio 0.7.22 omit Hermes-supported providers

Ekko Studio Version

0.7.22 (hermes-web-ui)

Agent Runtime and Version (if applicable)

Hermes Agent 0.21.3

Bug Description

Ekko Studio 0.7.22 maintains provider registries (PROVIDER_ENV_MAP and PROVIDER_PRESETS) that are out of sync with Hermes Agent 0.21.3. Native Hermes providers missing from these tables are omitted from Studio’s built-in discovery path, even when Hermes supports them and valid credentials are configured. This affects /api/hermes/available-models and New Chat → Provider.

Verified reproduction: alibaba-token-plan-cn works through Hermes CLI but is absent in Studio. It is the concrete example below of a broader registry synchronization defect; other missing providers have not been individually tested end to end.

Affected profile: default; model: deepseek-v4.1-flash.

Steps to Reproduce

1. Configure Hermes’s native alibaba-token-plan-cn provider with a valid ALIBABA_TOKEN_PLAN_CN_API_KEY in ~/.hermes/.env.
2. Verify Hermes can call it:
   bash复制

   hermes chat --provider alibaba-token-plan-cn --model deepseek-v4.1-flash -q "reply only OK"

   This returned OK in the affected environment. An authenticated request to https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1/models also succeeded and listed deepseek-v4.1-flash.
3. Start Studio against the same Hermes home/profile and open New Chat → Provider.
4. Inspect GET /api/hermes/available-models?profile=default.

Expected Behavior

Studio should keep discovery aligned with the installed Hermes runtime for supported native providers, preserving canonical IDs, aliases, credentials, endpoints, and available models. A provider should not silently disappear solely because Studio’s manually maintained metadata is stale. Providers requiring an unsupported integration should have that limitation made explicit. For the verified case, alibaba-token-plan-cn and deepseek-v4.1-flash should be selectable.

Actual Behavior

alibaba-token-plan-cn is absent from both groups and allProviders, so it cannot be selected in New Chat. The response contains zai, deepseek, opencode-free, openai-codex, and the internal moa group. model_visibility is empty. The credential pool contains the canonical provider and its alias dashscope-token-plan-cn; the required API-key environment entry is present.

Logs / Error Messages

Environment

macOS

Node Version

No response

Additional Context

Root-cause evidence

The installed 0.7.22 source map identifies the following path. The same omission was verified in upstream main at commit b036cf24479a652559ea19e48143069e8596b61e:

• PROVIDER_ENV_MAP includes alibaba and alibaba-coding-plan, but not alibaba-token-plan-cn.
• buildAvailableForProfile() iterates Object.entries(PROVIDER_ENV_MAP) before checking credentials and resolving model catalogs. The missing provider never enters that loop.
• PROVIDER_PRESETS also lacks the provider. allProviders is built from those presets.

In the installed Hermes Agent 0.21.3, plugins/model-providers/alibaba/__init__.py registers alibaba-token-plan-cn, alias dashscope-token-plan-cn, API-key authentication, and base URL https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1. Its static model catalog also includes this provider. Studio’s manually maintained registries have therefore diverged from Hermes’s native registry.

Broader scope and verification limits

The affected installation’s diagnostic report compared Hermes 0.21.3’s registry with the union of Studio’s two tables and found additional missing identifiers, including alibaba-token-plan, deepinfra / deep-infra, nebius, fireworks / fw, upstage, vertex, and bedrock. The reported difference was 46 registry identifiers, including aliases—not 46 independently reproduced provider failures.

The code-level exclusion is shared: an ID absent from PROVIDER_ENV_MAP is never considered by the built-in discovery loop, and an ID absent from PROVIDER_PRESETS is not emitted through the preset-based allProviders path. Consequently, other omitted native providers can encounter the same discovery failure. Their authentication/transport requirements and actual runtime behavior need individual validation; this report does not claim that every provider can be fixed with an OpenAI-compatible preset.

The missing custom:* entries observed during diagnosis had a separate cause: corresponding providers / custom_providers definitions were absent from the current configuration. They are not evidence of this native-registry bug.

Suggested fix

• Audit and synchronize native provider coverage against Hermes 0.21.3, deduplicating aliases and checking authentication/transport support. Prefer deriving metadata from the installed Hermes registry, with explicit compatibility handling, over maintaining an independent snapshot.
• As an immediate fix for the verified case, add alibaba-token-plan-cn to both Studio registries, with ALIBABA_TOKEN_PLAN_CN_API_KEY, optional ALIBABA_TOKEN_PLAN_CN_BASE_URL, the native base URL, and a model fallback sourced from Hermes. Preserve Hermes’s supported API-key fallback (ALIBABA_TOKEN_PLAN_API_KEY) and normalize the alias to the canonical ID where appropriate.
• Add registry-parity/compatibility tests plus representative discovery tests across supported authentication types and aliases. For the verified case, assert that valid profile credentials produce the canonical provider in groups and allProviders, with the correct endpoint/model and existing providers preserved.

Related: #1186 concerned an older alibaba-coding-plan mapping problem. This report documents registry drift in 0.7.22, with alibaba-token-plan-cn as the verified reproduction. Runtime/API observations above come from the affected installation’s diagnostic report; the upstream source check was performed separately.