Qwen models via OpenAI-compatible passthrough (LimitRouter) fail with 400: enable_thinking / thinking_budget not stripped

[prajadiputra]

Problem

When routing Qwen models (e.g. qwen3.7-plus) through an OpenAI-compatible passthrough provider like LimitRouter, 9router v0.5.40 injects enable_thinking: true and thinking_budget: 8192 into the request body. LimitRouter (and other strict OpenAI-compatible providers) reject these fields with HTTP 400:

{"error":{"message":"2 request validation errors: Extra inputs are not permitted, field: 'enable_thinking', value: True; Extra inputs are not permitted, field: 'thinking_budget', value: 8192","type":"invalid_request_error","code":"invalid_request"}}

Root Cause

In chunks/52136.js, the Qwen thinking format adapter unconditionally injects enable_thinking and thinking_budget for any model whose name contains "qwen":

case "qwen": {
    if (g && h) { b.enable_thinking = false; break; }
    b.enable_thinking = true;
    let a = k(i, d.thinkingRange);
    Number.isFinite(a) && a > 0 && (b.thinking_budget = a);
    break;
}

This is correct when the downstream provider is Qwen-native (DashScope/Qwen API). But when the downstream is an OpenAI-compatible passthrough like LimitRouter, these fields are not in the OpenAI Chat Completions spec and get rejected.

Same bug class as #1468 and #1442

• Claude Code fails with "context_management: Extra inputs are not permitted" on anthropic-compatible endpoint #1468: context_management injected → Anthropic-compatible provider rejected → PR fix: strip Claude context management for compatible providers #1500 fix strips it
• Opencode Go kimi-2.6 Model Error #1442: client_metadata injected → provider rejected
• This issue: enable_thinking / thinking_budget injected → OpenAI-compatible passthrough rejected

Expected behavior

9router should strip enable_thinking and thinking_budget when the downstream provider is openai-compatible-chat (passthrough), similar to how PR #1500 strips context_management for Anthropic-compatible providers.

Alternatively, the thinking format adapter should only apply when the provider is Qwen-native (qwen provider type), not when routing through openai-compatible-chat.

Reproduction

# Via 9router with limit/qwen3.7-plus combo:
# 9router injects enable_thinking → LimitRouter returns 400

# Direct to LimitRouter (works without enable_thinking):
curl https://limitrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -d '{"model":"qwen3.7-plus","messages":[{"role":"user","content":"Hi"}]}'
# → 200 OK

# With enable_thinking (fails):
curl https://limitrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -d '{"model":"qwen3.7-plus","messages":[{"role":"user","content":"Hi"}],"enable_thinking":true,"thinking_budget":8192}'
# → 400: Extra inputs are not permitted

Environment

• 9router v0.5.40 (installed Jul 20, 2026)
• Provider: LimitRouter (openai-compatible-chat)
• Combo: limit/qwen3.7-plus
• Downstream: https://limitrouter.com/v1

Workaround

Remove Qwen models from combos that route through openai-compatible-chat providers.