Bug Description

OpenClaw sends the developer message role (from the newer OpenAI Responses API convention) when making requests to all OpenAI-compatible providers. However, most non-OpenAI backends (Qwen, GLM, DeepSeek, Kimi, etc.) only support the standard Chat Completions API roles: system, user, assistant, tool, function.

This causes a 400 error when using these models through any OpenAI-compatible proxy:

400 developer is not one of ['system', 'assistant', 'user', 'tool', 'function'] - 'messages.['0].role'

Steps to Reproduce

1. Configure an OpenAI-compatible provider (e.g., CPA proxy) pointing to a Qwen backend
2. Add qwen-3.5-plus as a model under that provider
3. Try to use the model (e.g., via subagent spawn or direct chat)
4. Request fails with 400 because Qwen API does not recognize developer role

Expected Behavior

OpenClaw should use the standard system role for Chat Completions API requests, especially for non-OpenAI providers. The developer role is an OpenAI-specific convention (primarily for the Responses API) and is not part of the widely-adopted OpenAI Chat Completions standard.

Verified via curl

Same CPA proxy, same model:

• {"role": "system", ...} → ✅ works perfectly
• {"role": "developer", ...} → ❌ 400 error

Other chat clients (e.g., Cherry Studio) connecting through the same CPA proxy work fine because they use system.

Suggested Fix

• Use system role by default for all OpenAI-compatible providers
• Or provide a per-provider/per-model config option to choose between system and developer
• The developer role should only be used when the provider is confirmed to be OpenAI native

Environment

• OpenClaw version: latest (2026-02-26)
• Provider: CPA (OpenAI-compatible proxy)
• Affected models: qwen-3.5-plus, potentially all non-OpenAI models