Apply Fast mode changes to the current active turn at the next model request

What variant of Codex are you using?

Codex Desktop / shared Codex core runtime.

What feature would you like to see?

Changing Speed / Fast mode while a turn is already running should affect the next model request in that same active turn, rather than waiting until the next user turn.

Today, thread settings are snapshotted for the active turn. The current regression test explicitly verifies this behavior for model, reasoning, service tier, and other settings:

settings_update_during_active_turn_applies_to_next_turn_only

https://github.com/openai/codex/blob/daca1fab840303152d7b488a4b403dee2f85b62f/codex-rs/core/tests/suite/model_switching.rs

That behavior is understandable for model/reasoning changes, but it is a poor fit for service tier / Fast mode. Service tier is a request-level latency/usage tradeoff. A long Codex turn may contain many separate inference requests around tool calls:

model -> tool -> model -> tool -> model -> ...

The user should be able to switch Standard -> Fast while waiting, accelerate subsequent inference requests in the same turn, then switch Fast -> Standard again when latency is no longer important.

Proposed semantics

Treat service-tier changes differently from model/reasoning changes:

• Do not modify a model request that is already in flight.
• Apply the newly selected service tier to the next Responses/model request, even if it belongs to the same active turn.
• Subsequent model requests keep using the latest selected tier until changed again.
• Switching back to Standard should likewise take effect on the next model request.
• Already-running tools/processes are unaffected.
• Model and reasoning effort may remain turn-scoped if changing them mid-turn would violate consistency assumptions.

In other words, make service tier request-scoped, not turn-scoped.

Example

Current behavior:

Turn starts on Standard
  request A: Standard
  tool call
  user switches to Fast
  request B: Standard   <- surprising
  tool call
  request C: Standard   <- still surprising
Turn completes
Next user turn
  request D: Fast       <- finally applies

Requested behavior:

Turn starts on Standard
  request A: Standard
  tool call
  user switches to Fast
  request B: Fast
  tool call
  user switches back to Standard
  request C: Standard

No interrupt, stop/resume, or synthetic new user turn should be required.

Why this matters

Fast mode has an intentionally higher usage/cost multiplier in exchange for lower latency. Its most useful interaction model is burst acceleration:

• leave routine/background work on Standard;
• enable Fast when the user is actively blocked and waiting;
• disable it again once the latency-sensitive section has passed.

With turn-scoped semantics, users must predict at the beginning of a potentially long agent turn whether they will need acceleration later. If they decide mid-turn that they need Fast, the only practical workaround is to interrupt the running turn and start another one. That is disruptive and can break execution continuity purely to change a scheduling tier.

It also makes the UI misleading: the Speed selector changes immediately, while the active turn can continue generating multiple Standard-tier requests for minutes afterward.

Suggested implementation/test boundary

The existing settings_update_during_active_turn_applies_to_next_turn_only coverage could keep the current expectations for model/reasoning, while service tier gets separate request-level behavior.

A deterministic test could:

1. Start one active turn on Standard.
2. Complete the first model request with a tool call while keeping the turn active.
3. Update thread settings to Fast.
4. Assert that the next model request in the same turn sends service_tier: "priority".
5. Update settings back to Standard.
6. Assert that a later model request in the same turn omits the priority tier.
7. Assert that no new user turn or interruption occurred.

If changing the tier while a model request is currently streaming cannot affect that request, the UI can state that the change applies starting with the next model request, which is both predictable and useful.

Related

• #32612 requests active-turn propagation for access-control changes. This request is narrower and specifically concerns the request-level service tier / Fast mode.
• #32596 demonstrates the broader UX problem when selectors show new settings while an active turn still runs under the old runtime snapshot.

I searched existing Fast-mode/service-tier issues and did not find an exact request for applying a tier change to the next inference request inside the current active turn.

Start with codex-rs/core/tests/suite/model_switching.rs and the settings_update_during_active_turn_applies_to_next_turn_only test to trace how active-turn settings reach model requests. Add focused coverage for changing service tier between requests in one turn: Fast should send priority on the next request, and switching back should omit it without interruption or a new user turn.