Bug Description

Summary

The Alibaba Coding Plan provider integration works correctly for routing and switching models, but the API returns incorrect model identity in responses. All models respond as "glm-4.7" when asked "what model are you", regardless of the requested model
(qwen3.5-plus, kimi-k2.5, etc.). This prevents the agent from accurately reporting its identity to users.

Environment

• Hermes Version: Latest (from repository)
• Provider: alibaba-coding-plan
• Provider Config:
  • API Endpoint: https://coding-intl.dashscope.aliyuncs.com/v1
  • API Key: CODING_PLAN_API_KEY (format: sk-sp-xxxxx)
  • Models: qwen3.5-plus, qwen3-max-2026-01-23, qwen3-coder-next, qwen3-coder-plus, glm-5, glm-4.7, kimi-k2.5, MiniMax-M2.5

Configuration

# PROVIDER_REGISTRY (hermes_cli/auth.py)
"alibaba-coding-plan": ProviderConfig(
    id="alibaba-coding-plan",
    name="Alibaba Cloud Coding Plan",
    auth_type="api_key",
    inference_base_url="https://coding-intl.dashscope.aliyuncals.com/v1",
    api_key_env_vars=("CODING_PLAN_API_KEY",),
    base_url_env_var="CODING_PLAN_BASE_URL",
),

# _PROVIDER_MODELS (hermes_cli/models.py)
"alibaba-coding-plan": [
    "qwen3.5-plus",
    "qwen3-max-2026-01-23",
    "qwen3-coder-next",
    "qwen3-coder-plus",
    "glm-5",
    "glm-4.7",
    "kimi-k2.5",
    "MiniMax-M2.5",
]

# Context limits (agent/model_metadata.py)
"alibaba-coding-plan/qwen3.5-plus": 1000000,  # 1M context
"alibaba-coding-plan/kimi-k2.5": 262144,  # 256K context

Steps to Reproduce

1. Configure Alibaba Coding Plan provider with valid API key
2. Switch to qwen3.5-plus model:

   /model alibaba-coding-plan:qwen3.5-plus

3. Ask the model: "what model are you?"
4. Expected response: "I am qwen3.5-plus"
5. Actual response: "I am GLM-4.7"
6. Repeat step 2-3 with kimi-k2.5, glm-5, or any other model - all respond as GLM-4.7

Expected Behavior

The model should correctly identify itself based on the model parameter sent in the API request:

• Requesting qwen3.5-plus → Model responds as qwen3.5-plus
• Requesting kimi-k2.5 → Model responds as Kimi K2.5
• Context window should match model specifications (qwen3.5-plus: 1M tokens)

Actual Behavior

All models respond as "GLM-4.7" regardless of the model parameter in the request:

User: /model alibaba-coding-plan:qwen3.5-plus
User: what model are you?
Model:  GLM-4.7

The API response contains:

{
  "model": "I am GLM-4.7",
  ...
}

Affected Component

CLI (interactive chat)

Messaging Platform (if gateway-related)

No response

Operating System

Fedora Linux 43 (WSL)

Python Version

3.14.3

Hermes Version

v2026.3.17-336-ge42e111

Relevant Logs / Traceback

Root Cause Analysis

The Alibaba Coding Plan API endpoint (coding-intl.dashscope.aliyuncs.com/v1) ignores the model parameter in the request and always returns glm-4.7 as the model name in the response. This appears to be a bug on Alibaba's side.

Evidence

1. OpenCode Comparison: OpenCode (another AI coding tool using the same Alibaba Coding Plan API) correctly identifies models. Investigation shows OpenCode works around this by including model identity in the system prompt:

   You are powered by the model named qwen3.5-plus.
   The exact model ID is alibaba-coding-plan/qwen3.5-plus
   

2. API Response Verification: Direct API calls to Alibaba Coding Plan show the model field in response is always glm-4.7:

   curl -X POST https://coding-intl.dashscope.aliyuncs.com/v1/chat/completions \
     -H "Authorization: Bearer $CODING_PLAN_API_KEY" \
     -d '{"model": "qwen3.5-plus", "messages": [...]}'
   
   Response: {"model": "glm-4.7", ...}

3. Existing Workarounds: Hermes already has workarounds for this issue:

   • run_agent.py (lines 3801-3824): Uses self.model for display instead of response model name
   • model_metadata.py (lines 905-915): Uses requested model name for context length lookup

Impact

• User Confusion: Users cannot verify which model they're using
• Debugging Difficulty: Hard to diagnose whether the correct model is being used
• Trust Issues: Unclear if the API is actually routing to the requested model

Proposed Fix (optional)

Suggested Solution

Since this is an API-side bug, implement a workaround in Hermes by adding model identity to the system prompt for Alibaba Coding Plan providers:

Option 1: Add to _build_system_prompt() in run_agent.py

# Add model identity for Alibaba Coding Plan (workaround for API returning wrong model name)
if self.provider in ("alibaba-coding-plan", "alibaba-coding-plan-anthropic"):
    model_identity = (
        f"\n\nYou are powered by the model named {self.model.split('/')[-1] if '/' in self.model else self.model}. "
        f"The exact model ID is {self.model}."
    )
    prompt_parts.append(model_identity)

Option 2: Update DEFAULT_AGENT_IDENTITY in run_agent.py
Include model/provider information in the default agent identity.

Workaround for Users

Users can currently use ephemeral system prompts to specify model identity:

hermes chat --system-prompt "You are powered by the model named qwen3.5-plus. The exact model ID is alibaba-cading-plan/qwen3.5-plus."

Additional Notes

• Context Length: The context limit workaround in model_metadata.py appears to work correctly (1M for qwen3.5-plus)
• Model Routing: Model switching works correctly - the API processes requests with the intended model
• Issue: Only the model identity in the response is incorrect
• Documentation: Alibaba's official docs show qwen3.5-plus supports 1M context window

References

• Alibaba Coding Plan Documentation: https://www.alibabacloud.com/help/en/model-studio/openclaw-coding-plan
• Related Code:
  • run_agent.py lines 3801-3824 (model name display workaround)
  • model_metadata.py lines 905-915 (context length lookup workaround)
  • hermes_cli/auth.py (provider registry)
  • hermes_cli/models.py (model catalog)

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR