openclaw - 💡(How to fix) Fix [Feature]: Support user_id field in OpenAI-compatible provider requests (DeepSeek API)

Summary

Support injecting user_id field into OpenAI-compatible API request bodies for providers that utilize it (e.g., DeepSeek API for KVCache isolation and rate-limit scheduling).

Problem to solve

DeepSeek API supports a standard user_id field in the request body (per their docs) for:

1. Content safety isolation between different business users
2. KVCache isolation for privacy management
3. Scheduling isolation (rate limiting per user_id for high-concurrency accounts)

Currently OpenClaw does not pass any user_id field when making OpenAI Chat Completions requests, making it impossible to leverage these features under the same API key. Users are forced to set up external proxy scripts to inject this field, which is fragile and hard to maintain.

Proposed solution

Add a configurable user_id field to OpenAI-compatible provider definitions, ideally at the provider or model level. When set, it should be injected into the chat completions request body at the top level alongside model, messages, etc.

For example, in openclaw.json:

{
  "models": {
    "providers": {
      "deepseek": {
        "baseUrl": "https://api.deepseek.com",
        "api": "openai-completions",
        "user_id": "openclaw_nas"
      }
    }
  }
}

This would result in requests like:

{
  "model": "deepseek-chat",
  "messages": [...],
  "user_id": "openclaw_nas"
}

Alternatives considered

1. External proxy: A Node.js/nginx sidecar that injects the field. Works but adds deployment complexity, a single point of failure, and extra latency.
2. Custom header: DeepSeek does not support user_id via HTTP headers; it must be in the request body.
3. Session-level dynamic injection: More flexible but over-engineered for a simple static field. Could be a future enhancement.

Impact

• Affected: All users of DeepSeek API through OpenClaw who need user-level isolation (multi-tenant setups, high-concurrency agents, privacy-conscious deployments)
• Severity: Medium — workaround exists (external proxy) but is suboptimal
• Frequency: Constant — every request lacks this field
• Consequence: Extra infrastructure maintenance (proxy scripts, systemd services), potential rate-limit issues under high concurrency, no KVCache isolation

Evidence/examples

DeepSeek API documentation explicitly lists user_id as a standard request body parameter:

• https://api-docs.deepseek.com/zh-cn/quick_start/rate_limit#user_id-%E9%9A%94%E7%A6%BB
• https://api-docs.deepseek.com/zh-cn/api/create-chat-completion (see the user_id field in the request body schema)

Other OpenAI-compatible providers (Together AI, Fireworks AI, etc.) also support similar user-level routing fields.

Additional information

• This should be an optional field; backward compatible for all existing configs.
• The field should be injected at the top level of the request body.
• For Anthropic-style transport, this maps to metadata.user_id.
• A simple fix would be to add a user_id field to the provider config schema and merge it into the request body during construction.