Problem
As the ecosystem moves to reasoning-first models (DeepSeek-R1, Qwen3, etc.), we at Siemens need to retire older models while keeping client API calls unchanged. Simply remapping an alias to a reasoning model forces chain-of-thought on every request, including ones where it is undesired, with no way to control it at the router level. Mainly we need a way to force reasoning_effort=none so we can swap in a reasoning model as a drop-in replacement without changing client behaviour.
It would also enable creating dedicated aliases for capability tiers (fast, thorough, etc.) from a single engine deployment.
What we'd want is something like:
# CLI / JSON
gpt-4o:qwen3-32b|reasoning_effort=none
gpt-4o-mini:qwen3-32b|reasoning_effort=low
gpt-4o-thorough:qwen3-32b|reasoning_effort=high
# YAML
static_aliases:
gpt-4o:
model: qwen3-32b
reasoning_effort: none
The router injects reasoning_effort into the forwarded request when the client hasn't set it (client value always wins). Plain alias:model aliases stay unchanged, fully backward-compatible.
Problem
As the ecosystem moves to reasoning-first models (DeepSeek-R1, Qwen3, etc.), we at Siemens need to retire older models while keeping client API calls unchanged. Simply remapping an alias to a reasoning model forces chain-of-thought on every request, including ones where it is undesired, with no way to control it at the router level. Mainly we need a way to force
reasoning_effort=noneso we can swap in a reasoning model as a drop-in replacement without changing client behaviour.It would also enable creating dedicated aliases for capability tiers (fast, thorough, etc.) from a single engine deployment.
What we'd want is something like:
The router injects
reasoning_effortinto the forwarded request when the client hasn't set it (client value always wins). Plainalias:modelaliases stay unchanged, fully backward-compatible.