OpenAI-compatible Chat Completions: top-level reasoning_effort ignored, only chat_template_kwargs controls reasoning

Summary

When using the OpenAI-compatible /v3/chat/completions endpoint with Qwen3 reasoning models, OVMS ignores the standard top-level reasoning_effort field and only honors reasoning controls passed through chat_template_kwargs.

This creates interoperability issues with OpenAI-compatible clients that correctly send reasoning_effort but have no knowledge of OVMS-specific chat-template parameters.

Additionally, with --reasoning_parser qwen3, reasoning still appears inside message.content instead of being returned separately as reasoning_content.

I'm not sure whether both behaviors are intentional, so this issue is primarily a request for clarification.

---

Environment

• OVMS 2026.2.1 (Windows binary)
• REST API (/v3/chat/completions)
• Windows 11
• GPU target
• Model: OpenVINO/Qwen3-8B-int4-ov
• --tool_parser hermes3
• --reasoning_parser qwen3

---

What I verified

Using direct curl requests against OVMS:

Request	Result
reasoning_effort: "none"	❌ ignored
reasoning_effort: "high"	❌ ignored
chat_template_kwargs.enable_thinking=false	✅ works
chat_template_kwargs.enable_thinking=true	✅ works
chat_template_kwargs.reasoning_effort="low"	✅ works

This confirms that reasoning is currently controlled exclusively through:

{
  "chat_template_kwargs": {
    "enable_thinking": true,
    "reasoning_effort": "low"
  }
}

while the OpenAI-style top-level

{
  "reasoning_effort": "low"
}

appears to have no effect.

---

Interoperability concern

OVMS advertises an OpenAI-compatible Chat Completions API.

Many OpenAI-compatible clients expose reasoning through the standard reasoning_effort field.

Some OpenAI-compatible inference servers translate this internally into the chat-template parameters required by the underlying model.

OVMS currently appears to require every client to explicitly know about chat_template_kwargs, reducing interoperability despite exposing an OpenAI-compatible endpoint.

If this behavior is intentional, documenting it explicitly would help client implementations avoid silent incompatibilities.

---

Questions

1. Is ignoring top-level reasoning_effort intentional?

If yes, I'll report this as an OVMS-specific capability that client implementations need to support.

If no, would OVMS consider automatically mapping

{
  "reasoning_effort": "low"
}

into

{
  "chat_template_kwargs": {
    "enable_thinking": true,
    "reasoning_effort": "low"
  }
}

for reasoning-capable models?

This would improve interoperability with existing OpenAI-compatible clients while remaining backward compatible.

---

2. What is the intended behavior of --reasoning_parser qwen3?

Even with the parser enabled, reasoning remains inside

choices[0].message.content

instead of being emitted separately as

choices[0].message.reasoning_content

Is this expected for Qwen3 models?

Or does it indicate a parser/template mismatch?

---

Why this matters

This is not specific to one client implementation.

Any OpenAI-compatible client that only knows the standard reasoning_effort field currently cannot dynamically control thinking on OVMS.

If appropriate, a server-side mapping would improve interoperability without requiring every client to implement OVMS-specific request rewriting.

---

Related

Client-side discussion:

https://github.com/NousResearch/hermes-agent/issues/99820

That issue discusses how Hermes Agent could work around the current OVMS behavior.

This issue asks whether the current OVMS behavior is intentional and whether improving compatibility at the server level would be desirable.