Skip to content

Allow Session configuration changes while a turn is running #3347

Description

@chihumyum

Problem

Maka Desktop currently disables the model, thinking-level, and permission-mode controls while a turn is running.

This is intentional today:

  • the active AgentRun must keep the model and execution configuration it started with;
  • changing Session configuration during the send → run-start window previously created a race where an already submitted turn could observe the new configuration;
  • Runtime Host therefore rejects Session configuration transitions while a linked Turn is active.

However, preventing changes entirely creates unnecessary friction. Users often know which model, thinking level, or permission mode they want to use for their following message before the current response has finished. Today they must wait for the turn to settle, change the setting, and only then continue.

Related work:

Desired outcome

Desired behavior

Keep the existing invariant that an active AgentRun is immutable, while allowing the user to change these controls during the run:

  • model;
  • thinking level;
  • permission mode.

The controls should behave like their ordinary idle-state versions:

  • no separate “Next turn” label;
  • no duplicate current/next configuration display;
  • no persistent pending badge or pending-configuration panel;
  • the control displays the user’s latest selection;
  • the current response and its tool execution continue with their original configuration;
  • the selected configuration is used when the following root Turn is admitted.

The last selection before the following message wins.

If the user changes a value back to the currently effective Session configuration before sending the following message, that part of the pending change disappears automatically. No explicit Cancel action is needed.

For example:

  1. The current turn is running with model A.
  2. The user selects model B.
  3. The user changes back to model A before sending another message.
  4. No model transition is performed.

The same rule applies independently to thinking level and permission mode.

Configuration semantics

The active Session configuration and the user’s not-yet-applied selection should remain separate internally.

A pending configuration should be initialized from the effective Session configuration and updated as the user changes the controls.

When the pending configuration once again equals the effective configuration, it should normalize to “no pending change”.

Model and thinking-level behavior should remain compatible with the existing per-model rules:

  • selecting another model resets the pending thinking level to that model’s default;
  • returning to the original model before the change is applied should restore the original effective thinking level unless the user explicitly selected another level;
  • unsupported thinking levels must never be silently carried across models.

Runtime behavior

A configuration selected during an active turn must not mutate the active AgentRun or its Backend.

At the following root-Turn boundary, Runtime Host should atomically:

  1. resolve and validate the pending model target and thinking level;
  2. apply the permission-boundary transition;
  3. refresh or dispose Backend and execution resources as required;
  4. update the effective Session configuration;
  5. clear the pending configuration;
  6. create the new AgentRun from the updated configuration snapshot.

The configuration transition and root-Turn admission must share an authoritative ordering boundary so another client cannot start a Turn between configuration application and AgentRun creation.

The pending state should be owned by Runtime Host rather than only by the Desktop renderer, so reconnects, restarts, and multiple clients cannot disagree about the selected configuration.

Permission safety

A permission-mode selection made during a running turn must not:

  • change the authority of the active AgentRun;
  • change the handling of tools already running;
  • resolve or bypass a permission request already waiting for the user;
  • widen or narrow linked child-Session authority before the existing lineage becomes quiescent.

If the pending permission transition cannot safely commit when the following Turn is admitted, Maka should report the conflict and preserve the user’s selection. It must not silently start the Turn using a different permission mode.

Stopping the current turn and then sending should follow the same configuration-application path.

Message queue coordination

This proposal should coordinate with #2262 / #2634.

The implementation needs one deterministic rule for successor messages that are submitted while the current turn is running:

  • configuration may be snapshotted when the successor message is authoritatively submitted; or
  • the latest configuration may be consumed when that successor Turn is admitted.

Whichever rule is chosen must be Host-owned, visible consistently across clients, and free of a queue-admission/configuration-application race.

Non-goals

  • Hot-swapping the model used by an active provider request.
  • Changing the thinking level of an active provider request.
  • Changing the permission boundary of the active AgentRun.
  • Adding a separate configuration queue UI.
  • Adding new “current” and “next” labels to the Composer.
  • Covering Plan, Swarm, Graph, workspace, or other Session settings in the first version.
  • Requiring Side Chat parity in the first implementation.

Acceptance criteria

  • Model, thinking-level, and permission controls remain interactive while a root Turn is running.
  • The active AgentRun retains its original model, thinking, and permission configuration.
  • The following root Turn uses the latest valid selection.
  • Changing a selection back to the effective value automatically removes that pending change.
  • Model switching preserves the existing per-model thinking-level validation behavior.
  • Permission changes do not affect active tools, pending approvals, or linked running Sessions.
  • Application restart or Runtime Host reconnect does not lose an acknowledged selection.
  • Multiple clients observe one authoritative pending/effective state.
  • Configuration application and successor-Turn admission cannot race.
  • An application failure is reported rather than silently falling back to the old configuration.
  • Existing idle-state configuration changes continue to apply immediately.

Alternatives or workarounds

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions