Description
For coding-plan providers like Z.AI (GLM models on the OpenAI-compatible coding endpoint), reasoning effort levels are surfaced by expanding each model into duplicated rows in the model picker, e.g. glm-4.7 (high), glm-4.7 (med), glm-4.7 (low), glm-4.7 (none), etc. This is inefficient and clutters the model list. Effort should be controlled through the /effort command pipeline like other providers, with a single model row.
What happens
route_supports_reasoning_effort("openai-compatible:zai") returns true (OpenAiCompatible { profile_id } => profile_id.is_some() in crates/jcode-tui/src/tui/app/inline_interactive_placeholder_routes.rs).inferred_reasoning_efforts for zai/glm- models returns the full GLM ladder (GLM_SELECTABLE_EFFORTS = none/minimal/low/medium/high/xhigh/max) in crates/jcode-provider-core/src/reasoning.rs.- The model picker (
format_created in crates/jcode-tui/src/tui/app/inline_interactive.rs) then emits one PickerEntry per effort rung, producing duplicated model names with (effort) suffixes.
Meanwhile the intended command pipeline exists: /effort reads provider.available_efforts() and calls provider.set_reasoning_effort(...) (see crates/jcode-tui/src/tui/app/model_context.rs), which for the OpenAI-compatible runtime writes the reasoning_effort request field.
Expected
A single model row per model; changing reasoning effort goes through the /effort command (and effort cycling), not through duplicated model-list entries. If the picker must show effort at all, it should be a secondary control, not N duplicate model rows.
Suggested direction
Gate the per-effort picker expansion behind a route flag and rely on the /effort pipeline for coding-plan/OpenAI-compatible providers that expose a real top-level reasoning_effort field. GLM_SELECTABLE_EFFORTS already centralizes the ladder, so available_efforts()//effort can drive it without polluting the model list.
Description
For coding-plan providers like Z.AI (GLM models on the OpenAI-compatible coding endpoint), reasoning effort levels are surfaced by expanding each model into duplicated rows in the model picker, e.g.
glm-4.7 (high),glm-4.7 (med),glm-4.7 (low),glm-4.7 (none), etc. This is inefficient and clutters the model list. Effort should be controlled through the/effortcommand pipeline like other providers, with a single model row.What happens
route_supports_reasoning_effort("openai-compatible:zai")returns true (OpenAiCompatible { profile_id } => profile_id.is_some()incrates/jcode-tui/src/tui/app/inline_interactive_placeholder_routes.rs).inferred_reasoning_effortsforzai/glm-models returns the full GLM ladder (GLM_SELECTABLE_EFFORTS= none/minimal/low/medium/high/xhigh/max) incrates/jcode-provider-core/src/reasoning.rs.format_createdincrates/jcode-tui/src/tui/app/inline_interactive.rs) then emits onePickerEntryper effort rung, producing duplicated model names with(effort)suffixes.Meanwhile the intended command pipeline exists:
/effortreadsprovider.available_efforts()and callsprovider.set_reasoning_effort(...)(seecrates/jcode-tui/src/tui/app/model_context.rs), which for the OpenAI-compatible runtime writes thereasoning_effortrequest field.Expected
A single model row per model; changing reasoning effort goes through the
/effortcommand (and effort cycling), not through duplicated model-list entries. If the picker must show effort at all, it should be a secondary control, not N duplicate model rows.Suggested direction
Gate the per-effort picker expansion behind a route flag and rely on the
/effortpipeline for coding-plan/OpenAI-compatible providers that expose a real top-levelreasoning_effortfield.GLM_SELECTABLE_EFFORTSalready centralizes the ladder, soavailable_efforts()//effortcan drive it without polluting the model list.