Summary
Allow qwen-chat-template and qwen as thinkingFormat values in JSON config
Problem to solve
Local Qwen3.5 setups via llama.cpp can't get per-request thinking control through OpenClaw because thinkingFormat is restricted in the JSON validator to OpenAI/OpenRouter/DeepSeek/ZAI values.
Proposed solution
Allow qwen and qwen-chat-template as thinkingFormat values in the JSON config schema. The underlying pi-coding-agent library already supports this — it sends chat_template_kwargs: {"enable_thinking": ...} based on the thinking level. Only the validator gate needs to open.
Alternatives considered
Writing a TS extension via pi.registerProvider() works but is heavier than necessary for what should be a one-line schema change. extraBody passthrough exists but is static-only and can't toggle by thinking level.
Impact
Affected users/systems/channels: Anyone running OpenClaw against a local llama.cpp/llama-server backend serving a Qwen3-family model (Qwen3, Qwen3.5, Qwen3.6) configured via JSON. This is a growing user segment — Qwen3.5 GGUFs from Unsloth are popular for self-hosted setups due to the hybrid MoE architecture's CPU-friendly performance.
Severity: Workflow-degrading, not blocking. OpenClaw connects and routes correctly; the failure mode is silent — thinkingDefault and --thinking flags become no-ops because OpenClaw can't toggle thinking on the actual backend. Users are unaware their thinking-level config is being ignored unless they inspect raw API responses.
Frequency: Always, on every request to a Qwen-based local backend. 100% reproducible.
Consequence:
Forced thinking-on for every request means 5–10× higher latency on simple chat (Qwen3.5's reasoning step adds 200–1500 tokens before any reply). On a 122B model running locally at ~10 tok/s, "say hello" takes 30+ seconds instead of <1 second.
Users wanting fast chat must either bypass OpenClaw entirely (curl the backend directly), force thinking off at the server level via --chat-template-kwargs (which then breaks tool selection for autonomous agent runs — they want the opposite trade-off), or write a custom TypeScript extension via pi.registerProvider() to bypass the validator.
The underlying pi-coding-agent library already implements this correctly. The only gap is the JSON config validator's allowlist, making this a one-line schema fix that unblocks all three workarounds above.
Evidence/examples
No response
Additional information
No response
Summary
Allow qwen-chat-template and qwen as thinkingFormat values in JSON config
Problem to solve
Local Qwen3.5 setups via llama.cpp can't get per-request thinking control through OpenClaw because thinkingFormat is restricted in the JSON validator to OpenAI/OpenRouter/DeepSeek/ZAI values.
Proposed solution
Allow qwen and qwen-chat-template as thinkingFormat values in the JSON config schema. The underlying pi-coding-agent library already supports this — it sends chat_template_kwargs: {"enable_thinking": ...} based on the thinking level. Only the validator gate needs to open.
Alternatives considered
Writing a TS extension via pi.registerProvider() works but is heavier than necessary for what should be a one-line schema change. extraBody passthrough exists but is static-only and can't toggle by thinking level.
Impact
Affected users/systems/channels: Anyone running OpenClaw against a local llama.cpp/llama-server backend serving a Qwen3-family model (Qwen3, Qwen3.5, Qwen3.6) configured via JSON. This is a growing user segment — Qwen3.5 GGUFs from Unsloth are popular for self-hosted setups due to the hybrid MoE architecture's CPU-friendly performance.
Severity: Workflow-degrading, not blocking. OpenClaw connects and routes correctly; the failure mode is silent — thinkingDefault and --thinking flags become no-ops because OpenClaw can't toggle thinking on the actual backend. Users are unaware their thinking-level config is being ignored unless they inspect raw API responses.
Frequency: Always, on every request to a Qwen-based local backend. 100% reproducible.
Consequence:
Forced thinking-on for every request means 5–10× higher latency on simple chat (Qwen3.5's reasoning step adds 200–1500 tokens before any reply). On a 122B model running locally at ~10 tok/s, "say hello" takes 30+ seconds instead of <1 second.
Users wanting fast chat must either bypass OpenClaw entirely (curl the backend directly), force thinking off at the server level via --chat-template-kwargs (which then breaks tool selection for autonomous agent runs — they want the opposite trade-off), or write a custom TypeScript extension via pi.registerProvider() to bypass the validator.
The underlying pi-coding-agent library already implements this correctly. The only gap is the JSON config validator's allowlist, making this a one-line schema fix that unblocks all three workarounds above.
Evidence/examples
No response
Additional information
No response