Problem

Fast mode is useful for interactive first replies, but long tool-heavy turns should stop spending fast-tier capacity once the user is no longer waiting on the first response.

Today fast mode is effectively on or off; it does not express "start fast, then become cheap if this turn has become background work".

Proposal

Add fast: auto / fastMode: "auto":

• Keep the configured/session mode as auto.
• Resolve the effective provider fast tier per model call.
• Use fast tier for calls that start during the first configurable threshold, default 60s.
• Start later retry, fallback, tool-result, continuation, or app-server turn-start calls without fast tier.
• Emit channel progress when auto resolves off, e.g. 💨Fast: auto-off(75s>60s).
• Emit 💨Fast: auto-on at the end of a turn when auto-off was announced, so the next turn is visibly reset.

Notes

Codex app-server can receive serviceTier on thread start/resume and turn start, but not on steer for an already-running turn. So auto should apply at the next OpenClaw-started model call/turn-start boundary, not as a mid-stream retier of one already-running Codex app-server turn.

Related but different work:

• feat: add fast-lane override for immediate response execution #57239 handles a fast-lane scheduling path for quick follow-up messages while another run is active.
• feat(agents): allow spawn fast mode overrides #82148 handles fast-mode overrides for spawned sessions.

Acceptance

• /fast auto works in chat/UI/TUI/ACP session controls.
• agents.list[].fastModeDefault and model params accept "auto".
• params.fast_seconds / params.fastSeconds configures the cutoff.
• OpenAI, Anthropic, MiniMax, xAI, provider SDK stream families, and Codex app-server turn starts re-resolve automatic fast mode per call.
• Progress streaming includes auto-off and end-of-turn auto-on events.
• Docs explain the Codex app-server limitation.