Summary
After a remote model switch, the reasoning-effort chip keeps showing the previous model's effort level. A switch can clear an effort the new model does not advertise, so the chip then advertises a capability the new model does not have.
Version: current master 74577fe, macOS, remote session (TUI connected to the shared daemon).
Repro
- TUI remote session, pick a model with reasoning effort (e.g. medium).
- Switch model (
/model or picker) to one that does not advertise an effort.
- The effort chip next to the model name still shows the old level.
Cause
The daemon half already landed on master: since 74577fe, model_changed carries the effort the switched-to model runs with (crates/jcode-app-core/src/server/provider_control.rs, send_model_changed_result sends reasoning_effort in ServerEvent::ModelChanged, null on the error path), and the wire type always serializes the key with the comment "Always serialized (null = no effort) so a client can tell 'cleared' from an older server that omits it" (crates/jcode-protocol/src/wire.rs). The harness API translation adopted it (crates/jcode-harness-api-server/src/translate.rs).
But the TUI consumer never did: crates/jcode-tui/src/tui/app/remote/server_events.rs matches ServerEvent::ModelChanged with model, provider_name, error, resolved_credential, .. — the .. discards reasoning_effort, and nothing touches app.remote_reasoning_effort, which the status chip renders (crates/jcode-tui/src/tui/app/state_ui.rs).
Proposed fix
Bind reasoning_effort in the ModelChanged arm and assign it to app.remote_reasoning_effort on the success path (unconditional replace, mirroring the resolved_credential handling in the same arm: the wire key is always serialized, and None means cleared, so replace is also safe against older daemons that omit the field; the error path leaves the running model's effort untouched).
Happy to send a small PR with regression tests (adopt on switch, clear when none reported, untouched on failure).
Summary
After a remote model switch, the reasoning-effort chip keeps showing the previous model's effort level. A switch can clear an effort the new model does not advertise, so the chip then advertises a capability the new model does not have.
Version: current master 74577fe, macOS, remote session (TUI connected to the shared daemon).
Repro
/modelor picker) to one that does not advertise an effort.Cause
The daemon half already landed on master: since 74577fe,
model_changedcarries the effort the switched-to model runs with (crates/jcode-app-core/src/server/provider_control.rs,send_model_changed_resultsendsreasoning_effortinServerEvent::ModelChanged, null on the error path), and the wire type always serializes the key with the comment "Always serialized (null= no effort) so a client can tell 'cleared' from an older server that omits it" (crates/jcode-protocol/src/wire.rs). The harness API translation adopted it (crates/jcode-harness-api-server/src/translate.rs).But the TUI consumer never did:
crates/jcode-tui/src/tui/app/remote/server_events.rsmatchesServerEvent::ModelChangedwithmodel, provider_name, error, resolved_credential, ..— the..discardsreasoning_effort, and nothing touchesapp.remote_reasoning_effort, which the status chip renders (crates/jcode-tui/src/tui/app/state_ui.rs).Proposed fix
Bind
reasoning_effortin theModelChangedarm and assign it toapp.remote_reasoning_efforton the success path (unconditional replace, mirroring theresolved_credentialhandling in the same arm: the wire key is always serialized, andNonemeans cleared, so replace is also safe against older daemons that omit the field; the error path leaves the running model's effort untouched).Happy to send a small PR with regression tests (adopt on switch, clear when none reported, untouched on failure).