You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TUI plugins cannot read the currently selected model/agent (only the last-sent server session value) #50315
state.session.get(id).model is the server session value: it is updated only when a prompt is sent (the model is sent with session.prompt, and session.update is only used for title/archive).
The selected model/agent lives in the private Solid Local store in packages/tui/src/context/local.tsx. cycle() / set() only write that store; save() persists recent / favorite / variant to model.json but not the active model map.
Result: a status-line plugin that reads session.model (the only model value reachable from the plugin API) shows a stale value — it does not change on f2/tab model cycling, only after the next prompt is sent. The built-in prompt line does update live.
Reproduced on 1.18.31: cycling with f2 changes the built-in prompt line (· <model> <provider> · <variant>) but state.session.get(id).model stays on the previous value, and ~/.local/state/opencode/model.json never contains the active selection.
Ask
Expose the effective (pending) model / agent / variant through TuiState (or provide a change event on cycle/set), so TUI plugins can render an accurate status line without duplicating the built-in one inaccurately.
If a change event is preferred over a getter, something like tui.model.changed / tui.agent.changed would be enough.
I'll take this. The fix is to extend TuiPluginApi.state (packages/plugin/src/tui.ts) so a status-line plugin can read the live selected model/agent that the prompt input actually has on screen. The current gap is that state.session.get(id).model only mirrors the server-side value (set on the next session.prompt), and the in-memory selection lives in the private Solid store at packages/tui/src/context/local.tsx. The save() side already persists recent / favorite / variant to model.json — adding the active selection to that same payload keeps it consistent.
Plan: thread the active selection through the Solid Local store, surface it as a reactive read on the plugin state, and persist it alongside the recent/favorite set so refreshes can rebuild it. Cover with a TUI test that flips the model via the prompt and asserts the plugin sees the new value before the next prompt is sent.
Activity
holny commentedon Sep 23, 2026
I'll take this. The fix is to extend
TuiPluginApi.state(packages/plugin/src/tui.ts) so a status-line plugin can read the live selected model/agent that the prompt input actually has on screen. The current gap is thatstate.session.get(id).modelonly mirrors the server-side value (set on the nextsession.prompt), and the in-memory selection lives in the private Solid store atpackages/tui/src/context/local.tsx. The save() side already persistsrecent/favorite/variantto model.json — adding the active selection to that same payload keeps it consistent.Plan: thread the active selection through the Solid
Localstore, surface it as a reactive read on the plugin state, and persist it alongside the recent/favorite set so refreshes can rebuild it. Cover with a TUI test that flips the model via the prompt and asserts the plugin sees the new value before the next prompt is sent.Fixes #50315
fix(tui): expose the prompt's live model/agent selection to plugins
fix(tui): expose the prompt's live model/agent selection to plugins