Codex App Fast Mode should be configurable per thread/session instead of globally

Resolved 💬 2 comments Opened Apr 28, 2026 by pauloportella Closed Aug 5, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex App

What feature would you like to see?

Fast Mode in the Codex App currently behaves like a global setting, including for remote chats. I would like Fast Mode / priority to be configurable per thread or per session instead.

I am on a Pro 200 subscription, where Fast Mode/high-priority usage is useful but should be applied deliberately. The current global behavior is awkward when running multiple conversations at once. Some sessions should run at normal priority, while others should be high priority / Fast Mode. This is similar to how multiple Codex CLI sessions can be run with different priority/service-tier choices depending on the task.

A better behavior would be:

Allow each new chat/thread to choose normal vs Fast Mode priority.
Preserve that choice on the thread/session rather than applying it globally to all Codex App chats.
Include remote chats in that per-thread behavior, so enabling Fast Mode for one remote chat does not force every other remote/local chat into Fast Mode.
Optionally keep a global default, but let the user override it per thread/session.

Additional information

I searched for related issues before filing. The closest existing issue I found is #2916, which asks for OpenAI service tier support mostly around CLI/config. This request is specifically about Codex App Fast Mode being global across app chats, including remote chats, and needing per-thread/per-session control.

Other related but different issues:

#18841 was about Fast Mode disappearing from settings/chat.
#14593 is about token/usage burn rate.

View original on GitHub ↗

2 Comments

davibusanello · 2 months ago

I’m running into the same issue on the Codex App side.

The core problem is that Fast Mode/service-tier selection appears to behave like global app state rather than thread/session state. This can lead to unintended and inefficient resource usage when multiple Codex sessions run simultaneously.

Expected behavior:

Each thread/session should retain the speed/service tier it was started with.
Changing Fast/Standard/other speed/service-tier mode should affect only the current thread or the next new thread, not unrelated existing or running threads.
There should be a clear precedence model, for example:

  explicit thread/session setting  
  > project/repo setting  
  > selected profile  
  > global app default  
  > built-in default

Use case:

I often want one Codex thread running in a cheaper/slower “Flex” mode or a faster/higher-priority “Fast” mode, while another thread remains in the normal “Standard” mode for regular work. A global toggle makes this error-prone because changing the mode for one task can silently affect unrelated sessions.

So I think the missing piece is first-class per-thread/session speed-tier state in the Codex App, with global config/profile support acting only as defaults.

Today, the CLI can partially work around this with per-project config or explicit service-tier selection, but I should not need to switch to the CLI or manage multiple terminal sessions to get this level of control. The App should expose equivalent session/project isolation in the UI, as one of its expected advantages is to provide a single, focused view for controlling multiple Codex sessions and projects in parallel.

etraut-openai contributor · 23 days ago

Speed/service-tier settings are stored per conversation.