OpenClaw cannot connect to Alibaba Cloud Model Studio (Token Plan) — model validation fails

[cerulean rock]

SETUP
OpenClaw version: 2026.5.12
Provider: Alibaba Cloud Model Studio Token Plan (Singapore region)
Endpoint: https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode
API key format: sk-sp-... (Token Plan specific)
Model trying to use: qwen3.6-plus

WHAT WORKS
Direct curl to POST /v1/chat/completions with my key returns HTTP 200. The endpoint and key are valid.
WHAT DOES NOT WORK
OpenClaw gets a 404 error before sending any chat request. I tested both api: openai-completions and api: openai-responses adapters, same result.

THEORY
OpenClaw appears to call GET /v1/models (or similar model validation endpoint) before sending chat requests. Alibaba Cloud Model Studio only supports /v1/chat/completions and does not expose a model list endpoint. This causes OpenClaw to fail with 404 before ever reaching the actual chat endpoint.

QUESTION
Is there a way to bypass or disable the model validation step for custom OpenAI-compatible providers? Can I declare models statically so OpenClaw does not probe the provider, or is there another workaround?

[harsh musk]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[old osprey]

I checked the current docs/source. Short answer: there isn't a separate "disable model validation" switch, but the intended bypass is to define a static custom provider catalog under models.providers.<id>.models. Then OpenClaw can resolve the model from config instead of needing the provider to expose /v1/models.

For your endpoint, use the Chat Completions adapter, not Responses, since you said only /v1/chat/completions exists. Also make the configured baseUrl include the /v1 prefix:

{
  env: {
    ALIBABA_TOKEN_PLAN_API_KEY: "sk-sp-..."
  },
  models: {
    mode: "merge",
    providers: {
      "alibaba-token-plan": {
        baseUrl: "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1",
        apiKey: "${ALIBABA_TOKEN_PLAN_API_KEY}",
        api: "openai-completions",

[old osprey]

        authHeader: true,
        models: [
          {
            id: "qwen3.6-plus",
            name: "Qwen 3.6 Plus (Alibaba Token Plan)",
            input: ["text"],
            reasoning: false,
            contextWindow: 1000000,
            maxTokens: 65536
          }
        ]
      }
    }
  },
  agents: {

[old osprey]

    defaults: {
      model: { primary: "alibaba-token-plan/qwen3.6-plus" }
    }
  }
}

Then verify the static catalog first:

openclaw models list --provider alibaba-token-plan
openclaw infer model run --model alibaba-token-plan/qwen3.6-plus --prompt "hi" --json

If models list works but the infer run still 404s, the next useful data is the exact log line/path from:

[old osprey]

openclaw logs --follow

One important wrinkle: OpenClaw already has a bundled qwen provider, but its documented endpoints are dashscope-intl.aliyuncs.com/compatible-mode/v1, dashscope.aliyuncs.com/compatible-mode/v1, and the Coding Plan hosts. Your token-plan.ap-southeast-1.maas.aliyuncs.com endpoint is not one of those documented built-ins, so I’d keep it as a separate custom provider id like above.

Docs:
https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls
https://docs.openclaw.ai/providers/qwen

[cerulean rock]

New problem: After fixing Alibaba Cloud Token Plan auth for CLI (works with env var in systemd), subagents still fail with 401 "Invalid API-key provided." The env var is confirmed set in the gateway process, but subagents don't inherit it.

Evidence:
oc infer model run --model alibaba-token-plan/qwen3.6-plus → works ✅
Subagent spawn with same model → 401 ❌
cat /proc/$PID/environ shows ALIBABA_CLOUD_API_KEY is set in gateway
Subagent exec doesn't see the env var

Config:
"apiKey": "${ALIBABA_CLOUD_API_KEY}"

Question for upstream: How do subagents/child processes inherit env vars from the gateway? Is there a config option, or is this a bug?

[old osprey]

I checked the source path. There are two separate things here:

1. Subagent/tool exec env: this is not a reliable auth diagnostic. Exec/sandboxed commands do not inherit the full gateway process.env by design, especially in sandboxed runtimes. Docs call this out for sandbox exec; use agents.defaults.sandbox.docker.env only if the tool process itself needs a key.

2. Model auth for the subagent: that should be resolved by the agent runtime from config/auth, not by the subagent seeing the env var in exec.

For your custom provider, I’d make the key available through OpenClaw’s config/env loading rather than relying only on the systemd unit env. Two good options:

{
  env: {
    vars: {
      ALIBABA_CLOUD_API_KEY: "sk-sp-..."
    }
  },
  models: {

[old osprey]

    providers: {
      "alibaba-token-plan": {
        apiKey: "${ALIBABA_CLOUD_API_KEY}",
        // ...
      }
    }
  }
}

or put it in:

~/.openclaw/.env

[old osprey]

then restart the gateway.

If you want to keep it as a structured ref instead of ${...}, this is the equivalent shape:

apiKey: { source: "env", provider: "default", id: "ALIBABA_CLOUD_API_KEY" }

If that still fails while the gateway process definitely has the var, I’d treat it as a bug in the subagent/runtime auth path and file it with these details:

• openclaw --version
• whether the subagent is sandboxed
• the redacted models.providers.alibaba-token-plan config
• redacted ~/.openclaw/agents/<agentId>/agent/models.json entry for that provider
• the 401 log line from openclaw logs --follow

One extra suspicion: if models.json has a stale/incorrect apiKey entry for alibaba-token-plan, the subagent may be reading that generated catalog instead of the source ref you expect. Don’t paste the real key, but check whether it contains a marker like ALIBABA_CLOUD_API_KEY, a literal old key, or something unexpected.