Ability to set different model + reasoning for collab modes

yes please

Am I free to create a pull request to attempt this?

I think this request is more important than it may look at first, because Default and Plan are not just two labels on the same workflow. They represent two different optimization goals, but today Codex still treats /model as effectively global.

That creates a real UX mismatch:

• Shift+Tab makes it look like I am switching into a distinct mode with its own behavior.
• But if /model changes the same underlying default for both modes, the mode switch is only partial.
• In practice, this means users who want a coding-optimized model in Default and a broader/planning-oriented model in Plan have to keep reconfiguring the same global setting.
• The more intentionally someone uses Plan, the more this friction shows up.

For me, the natural mental model is:

• Default = execution / coding / editing
• Plan = decomposition / design / planning
• /model should affect the mode I am currently in
• I should then be able to choose whether that change is:
• only for this session, or
• saved as that mode’s default

Concretely, I think the most coherent behavior is:

1. Default continues to use model + model_reasoning_effort
2. Plan gets its own persisted defaults, e.g. plan_mode_model + plan_mode_reasoning_effort
3. /model operates on the active mode only
4. after choosing model + reasoning, Codex asks:

• Apply for this session
• Save as this mode's default

1. if the chosen value already matches the persisted default for that mode, the extra prompt can be skipped

Why I think this fits Codex well:

• it preserves the existing Shift+Tab mental model instead of inventing a new one
• it keeps the current /model command instead of adding a new command surface
• it scales cleanly to future collaboration modes
• it reduces repeated configuration churn for users who actually rely on mode-switching as a workflow primitive

I implemented this in my fork and validated the TUI/config flow, including:

• mode-scoped persisted defaults
• mode-scoped session-only overrides
• /model updating the active mode only
• restoring the correct model when switching between Default and Plan
• a footer/status-line refresh fix so the displayed model stays in sync with the active mode

Implementation branch / compare:
https://github.com/openai/codex/compare/main...DongwonTTuna:mode-scoped-model-selection?expand=1

I understand external PRs are by invitation only, so I am not trying to jump the process here. I mainly want to check whether this direction matches the intended product behavior. If it does, I’d really appreciate a maintainer read on whether this is something you’d want upstream. I’m happy to adapt the branch to whatever config shape or UX wording you would prefer.

One additional data point: there is already external precedent for this workflow.

Anthropic’s Claude Code docs describe an opusplan model alias that uses Opus during plan mode and Sonnet for execution:
https://docs.anthropic.com/en/docs/claude-code/model-config

I do not mean Codex should copy that exact alias or UX literally. But I do think it is evidence that this is a real user workflow, not just a personal preference: planning and implementation often benefit from different model tradeoffs, and users notice the friction when mode-switching does not carry model semantics with it.

In other words, the request here is not just “more settings.” It is about making the existing Default/Plan distinction behave like a true workflow distinction.

This is closely related to #14356.

This issue is about mode-scoped model/reasoning defaults, which makes sense. The companion question is how users quickly manipulate those settings moment to moment once the mode model exists.

#14356 argues for:

• direct reasoning-depth hotkeys
• a non-semantic depth meter that is readable at a glance
• next-turn-safe staging semantics, so if model/depth is changed while a turn is already running, the active request keeps its original config and the new selection applies to the next prompt

That seems like the right lower-level behavior underneath mode-specific defaults too.

This is possible with plan_mode_reasoning_effort = "high"