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
Maka Desktop persists active-task model, thinking-level, and permission-mode changes asynchronously through Runtime Host. Persistence feedback currently creates unnecessary visual latency and redundant success notifications:
Success toasts stack during rapid changes. Several model or thinking-level changes create notifications for intermediate values that are no longer relevant.
The source model in the toast can be wrong. It is derived from the latest assistant message rather than the configuration immediately before the switch, so A → B → C can be reported as A → C.
Pending presentation makes lightweight settings feel slow. A control can become disabled or display a spinner while waiting for the Host round trip even though the user's latest intent is already known.
Model and thinking writes can block each other. They are independent Runtime Host operations and should not share one pending gate.
The selected control is the success surface. Successful persistence should be silent; only a failure to commit the latest intent requires interruption.
How to reproduce
Stacked success toasts
Open an existing Desktop task.
Change the thinking level several times quickly, for example High → Extra high → Low.
Observe a separate success toast for each completed change.
Repeat with model changes and observe the same obsolete feedback.
Incorrect source model
Open a task whose latest assistant response used model A.
Change the task model from A to B.
Before receiving an assistant response from B, change from B to C.
Observe that the second toast can report A → C instead of B → C.
Visible mutation latency
Change the active task's model, thinking level, or permission mode.
Observe the pending/loading state while Desktop waits for Runtime Host.
Change the model or thinking level again and observe that the control does not continuously represent the latest selection.
Expected behavior
Model and thinking-level controls reflect the newest selection immediately, without a settings spinner, disabled flicker, or success toast.
Permission-mode persistence is also silent. Full access is confirmed before its optimistic value appears.
Model, thinking level, and permission mode have independent per-session intents.
Rapid changes converge on the latest requested value.
A terminal failure rolls the affected control back to the last successfully committed value and shows the existing localized error toast on the owning task surface.
A newer successful session-catalog observation retires the optimistic overlay and returns presentation authority to Runtime Host.
Successful model commits update the saved composer default; failed or mismatched commits do not.
Model-control optimism does not affect session-health, execution-state, or other unrelated decisions.
Assistive technology can read the selected model and thinking level, including the current value from each trigger.
Acceptance criteria
Successfully changing the active task model updates the selector immediately without a spinner or success toast.
Successfully changing the thinking level updates the selector immediately without a spinner or success toast.
Permission-mode persistence has no success toast or persistence-pending prop chain; Full access still requires confirmation before the new value appears.
Rapid changes converge on the latest selection, and model/thinking writes remain independent.
A cross-connection model selection works when two connections expose the same model ID and can be changed again while persistence is pending.
A terminal failure rolls back to the last committed value and reports the existing localized error on the owning task surface.
Superseded or late completions do not overwrite a newer selection or report an error on an unrelated surface.
A newer catalog revision retires a committed optimistic overlay.
Successful model commits update the composer default; failed or mismatched commits do not.
Session teardown clears model, thinking-level, and permission-mode overlays.
Model and thinking options expose selected radio state, and their triggers expose the current value in the accessible name.
Session-health and execution-state decisions continue to use authoritative session data.
Background
Maka Desktop persists active-task model, thinking-level, and permission-mode changes asynchronously through Runtime Host. Persistence feedback currently creates unnecessary visual latency and redundant success notifications:
A → B → Ccan be reported asA → C.The selected control is the success surface. Successful persistence should be silent; only a failure to commit the latest intent requires interruption.
How to reproduce
Stacked success toasts
High → Extra high → Low.Incorrect source model
A → Cinstead ofB → C.Visible mutation latency
Expected behavior
Acceptance criteria
Out of scope