litellm_config: Qwen3 thinking flag wrong for OpenRouter — 30-60s latency regression

[emooreatx]

Summary

OpenRouter Qwen3 model entries used chat_template_kwargs.enable_thinking=false — the vLLM flag — rather than the top-level OpenRouter flag enable_thinking=false. This meant Qwen3 thinking/reasoning mode ran unchecked on all OpenRouter requests.

Root cause

• DeepInfra/vLLM API: extra_body.chat_template_kwargs.enable_thinking = false
• OpenRouter API: extra_body.enable_thinking = false (top-level, not nested)

The wrong nesting silently fell through; OpenRouter ignored the unknown nested key and served Qwen3 in its default extended-thinking mode.

Impact

Observed 2026-08-22 from billing_callback logs:

• 59s gap for 24K-token request
• 38s gap for 10K-token request
• One response hit 8192-token output limit (model was thinking rather than answering)

Expected latency without thinking: 3-10s for these context sizes.

Fix

Applied in commit 3148c9e. OpenRouter entries now use top-level enable_thinking: false; DeepInfra entries keep the correct chat_template_kwargs nesting; Groq entry has no extra_body (Groq does not support Qwen3 thinking).

Lesson

When adding a new provider that has the same model family but different API contract, verify which parameter nesting the provider expects.