fix: derive the pending-session current model from the enabled provider - #47
Merged
william0wang merged 4 commits intoAug 16, 2026
Merged
Conversation
The thought option carried category "thought", which no client recognises as the reasoning-effort selector — the ACP ecosystem keys on id/category "effort" / "thought_level" (CodeBuddy, jcode, reasonix all use thought_level). Multica's shared matcher is representative: it selects the effort option by those tokens, so the zcode thinking toggle was invisible to effort pickers and a per-agent reasoning level had nowhere to land. The id stays "thought" (that is what session/set_config_option addresses); only the category changes, which is display/marking metadata. Editors that group config options by category now file it with the other thinking controls instead of a bespoke group. Verified through Multica: with the category aligned, the per-agent thinking picker appears (values enabled/disabled verbatim from the advertised options) and set_config_option dispatches to the runtime's session/setThoughtLevel.
…easoning.variants The lazy session/new advertised a hardcoded max/high/nothink list, which was fiction on both ends for the default coding-plan model: the runtime's own session/read for GLM-5.3 offers low/high/max (default max), and it REJECTS nothink with 'Unsupported reasoning effort'. Clients that relay the advertised options into a picker (Multica's effort selector) then offered tokens the runtime refuses and hid ones it accepts. The pending-session path now reads the enabled provider's models[].reasoning.variants for the default model — the same source the runtime itself resolves — with the static fallback corrected to the verified low/high/max. The value advertised for a live session was and remains the backend's session/read. Verified end-to-end through Multica: the per-agent picker now mirrors the real vocabulary (low/high/max for GLM-5.3) and dispatches tokens the runtime accepts; a behavioural A/B on the same task produced 3 reasoning chunks at low vs 18 at max.
- pending-session buildConfigOptions must advertise the thought option under the spec's thought_level category (the regression the category fix addresses: a bare "thought" category is not one of the reserved SessionConfigOptionCategory names, so effort pickers never found it) - orderThoughtVariants unit tests: canonical ordering with unknown tokens preserved at the end (exported for testability) 461 → 463 tests, all green.
The pending (lazy) session advertised a hardcoded currentValue GLM-5.2, which can disagree with the model the runtime actually starts with. ACP clients skip a requested switch when it matches the advertised current value, so the fiction silently pinned the wrong model whenever the requested id happened to equal it (observed with Paseo --model GLM-5.2). Follow the dropdown's leading entry instead.
This was referenced Aug 16, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #44, branched on top of it (the pending-session branch it fixes was introduced there).
While testing the adapter from Paseo I asked for
--model GLM-5.2and the agent quietly ran GLM-5.3 instead. Root cause: the lazy session's configOptions advertised a hardcodedcurrentValue: "GLM-5.2", which can disagree with the model the runtime actually starts with (the enabled provider's leading model). Clients reasonably skip a requested switch when it equals the advertised current value — ACP's "the agent reports its state" contract — so whenever the requested id happened to match the fiction, the switch was silently dropped. That's a self-report bug, not a client quirk; anything trusting currentValue is affected.Fix: derive the pending
currentValuefromloadAllModels()[0]— the dropdown's leading entry — instead of the hardcoded string. Falls back consistently withloadAllModels' own fallback when config is unreadable.Fail-before / pass-after: new regression test fails on the parent (advertises GLM-5.2 vs the derived leading entry), passes with the fix; asserts the current value is also selectable in the dropdown. Suite on this branch: 464 green.
End-to-end on the real backend (zcode CLI 0.16.3): after the fix, model switching verified working across the whole discovered list — builtin (GLM-5.3 / GLM-5.2 / GLM-5-Turbo) and third-party provider models — with the agent self-reporting the requested model.