Decide if the model is reasoning-capable
The supportsReasoning flag controls TWO behaviors, and both must be appropriate before flagging:
- chat-ui renders the thinking-effort dropdown and forwards
reasoning_effort to the router;
- chat-ui echoes the model's prior reasoning back as
reasoning_content on past assistant messages (cross-turn "preserved thinking" — see prepareFiles.ts / endpointOai.ts).
A model qualifies for (1) if it accepts the OpenAI-style reasoning_effort: low|medium|high parameter via the HF router and meaningfully changes its chain-of-thought depth in response. Whether that holds depends on both the model and the providers serving it — the router is a transparent proxy, so behavior comes from each provider's implementation. Don't decide from the name alone.
For (2), check the vendor's preserved-thinking / multi-turn guidance, because it can point in either direction:
- Flag-strengthening: the vendor documents that prior
reasoning_content must or should be passed back in multi-turn or tool-calling flows. Known examples: Moonshot thinking.keep (Kimi K2.6+/K3), MiniMax "Interleaved Thinking" ("must preserve the model's thinking content completely"), DeepSeek V4 thinking mode (hard 400 if reasoning_content is missing on tool-call turns), Z.ai "Preserved Thinking" (clear_thinking: false), Qwen3.6 preserve_thinking.
- Flag-blocking: the vendor documents that historical thoughts must be STRIPPED across completed turns. Known example: the Gemma family — Google requires removing thoughts from previous turns ("historical model output must only include the final response") while preserving them only inside a single turn's tool loop, which chat-ui handles automatically without the flag. Do not flag such models even though they emit reasoning and may accept an effort knob — flagging would make chat-ui echo reasoning the vendor says to strip.
Vendor doc entry points for the preserved-thinking check: https://platform.kimi.ai/docs/guide/use-kimi-k2-thinking-model, https://platform.minimax.io/docs/guides/text-m3-function-call, https://api-docs.deepseek.com/guides/thinking_mode/, https://docs.z.ai/guides/capabilities/thinking-mode, https://ai.google.dev/gemma/docs/capabilities/thinking, plus the model card's own multi-turn/best-practices section (Qwen cards document what their chat template does with historical <think> blocks).
Heuristic shortlist (candidates worth verifying):
- Name contains
gpt-oss, -Thinking, -thinking, -Reasoning, -reasoning, QwQ, R1, MiniMax-M, Kimi-K2-Thinking, cogito-
- Hybrid models with a thinking switch: DeepSeek V3.1+, GLM-4.5 / 4.6 / 4.7 / 5.x, Qwen3 thinking variants
- Model card mentions "thinking mode", "reasoning traces", "extended thinking", "test-time compute", or shows
<think>...</think> examples
Skip without further checking:
- Generic "good at reasoning" marketing copy — every modern LLM claims this. Only flag when reasoning is the mode of operation.
- Non-thinking siblings (
Qwen3-235B-A22B-Instruct-2507 ≠ Qwen3-235B-A22B-Thinking-2507).
- Translation / vision-only / guard / coder-only models with no documented thinking mode.
Verify each candidate via provider docs before flagging:
For each model on the heuristic shortlist, look up its live providers in the /v1/models payload, then check those providers' chat-completions documentation for reasoning_effort, reasoning_content, enable_thinking, or a thinking parameter. If at least one live provider documents it for this model (or for the model family in general), flag it as reasoning-capable. The HF router will proxy the parameter to whichever provider it picks.
Provider docs to consult (use WebFetch / WebSearch):
If none of the live providers document reasoning support for the model, don't flag it — even if the name pattern-matches. If documentation is ambiguous, lean toward not flagging and mention it in the commit so it can be revisited.
