Skip to content

Add dedicated reasoning-depth hotkeys, non-semantic depth meter, and next-turn-safe switching #14356

Open
Open
Add dedicated reasoning-depth hotkeys, non-semantic depth meter, and next-turn-safe switching#14356
Labels
TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayenhancementNew feature or request

Description

@oxysoft
oxysoft
opened on Mar 11, 2026

Summary

Codex should support dedicated reasoning-depth controls that are fast enough for frequent use, visually legible at a glance, and safe to use even while a turn is already in flight.

Problem

Right now, going through /models to change reasoning depth is too slow for something users may want to adjust constantly.

There are three related UX gaps:

  1. no dedicated shortcut for changing reasoning depth quickly
  2. the current semantic reasoning indicator is not the right mental shape for fast control/recognition
  3. commands are blocked during inference, so model/reasoning changes cannot cleanly participate in a fast adjust -> abort -> resume workflow

Requested behavior

  • add a dedicated shortcut for changing reasoning depth quickly, separate from the slower /models flow
  • optionally keep model selection and reasoning-depth selection as distinct controls/keymaps
  • add a non-semantic visual reasoning-depth indicator, for example:
    • [◉···]
    • [◉◉··]
    • [◉◉◉·]
    • [◉◉◉◉]
  • make the control work as a fast "control room" lever rather than a menu-heavy flow

Inference-safe switching semantics

If the user changes model or reasoning depth while a prompt is already running:

  • do not change the in-flight request mid-execution
  • the active turn should keep the model/reasoning configuration it was started with
  • the newly selected model/reasoning depth should be staged for the next turn

This implies the model/reasoning config is effectively cached/snapshotted when a prompt is sent.

Why this matters

This unlocks a much cleaner workflow:

  • adjust depth/model quickly
  • abort if needed
  • resume/continue without retyping

The broader point is that model/reasoning controls should feel like immediate cockpit switches, not buried menu actions.

Success criteria

  • users can change reasoning depth with a direct shortcut
  • the visual indicator is quickly readable without parsing semantic labels
  • changing depth/model during inference does not mutate the running request
  • the next-turn behavior is deterministic and visible to the user

Related context

Existing shortcut requests:

This issue broadens those requests with:

  • a dedicated reasoning-depth UX
  • a non-semantic indicator
  • safe staging semantics for in-flight turns

Activity

  1. github-actions
    added
    enhancementNew feature or request
    CLIIssues related to the Codex CLI
    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal display
    on Mar 11, 2026

  2. github-actions commented on Mar 11, 2026

    @github-actions
    github-actionsBot
    on Mar 11, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. oxysoft commented on Mar 11, 2026

    @oxysoft
    oxysoft
    on Mar 11, 2026
    Author

    One more connection: this pairs very naturally with the continuation/resume UX discussed in #14041 and #14042.

    If model/reasoning changes are next-turn-safe, then the control flow can become much cleaner:

    • adjust model/depth quickly
    • abort if needed
    • resume/continue without retyping

    That seems like a much stronger mental model than forcing users back through /models plus manual prompt editing every time they want to steer the current thread.

  4. etraut-openai
    removed
    CLIIssues related to the Codex CLI
    on Mar 11, 2026

  5. doublemover commented on Mar 13, 2026

    @doublemover
    doublemover
    on Mar 13, 2026

    I'd like to see this for /fast too, having to steer it to stop after it finishes its current task to do this is not great.

  6. bkerf commented on Apr 3, 2026

    @bkerf
    bkerf
    on Apr 3, 2026

    Strong +1 from real CLI usage.

    In actual development, I do not need to switch models very often, but I do need to switch reasoning effort frequently. Most turns can stay at medium/high, then when I hit a genuinely hard debugging or architecture problem I want to raise the next turn to xhigh immediately, inside the same active session.

    Right now this is much more awkward than it should be. In codex-cli 0.118.0, /model shows a dialog titled Select Model and Effort, but the screen only lists models. That makes the current UX and documentation feel misleading: the title implies effort is directly switchable there, but in practice there is no obvious in-session effort control.

    Using -c model_reasoning_effort=... with a fresh launch, or even fork/resume --last -c ..., is a workaround, not a good interactive workflow. When you are actively developing, getting stuck, and wanting to temporarily escalate to xhigh, this should be a one-step operation, not a session-management exercise.

    What would help most:

    • a dedicated /effort command or hotkey
    • or a clear second-step effort picker from /model
    • next-turn-safe semantics: do not mutate the in-flight request, but apply the new effort to the next turn in the same thread
    • make the staged/current effort visible in /status and the statusline
    • document the behavior clearly, because the current docs/UI wording suggests this already exists

    This is a very high-frequency control in real-world CLI use. It should be as cheap to change as temperature/gear in a cockpit, not something that requires restarting or forking the workflow.

  7. qiankunli commented on Apr 24, 2026

    @qiankunli
    qiankunli
    on Apr 24, 2026

    Adding a related manual-override case.

    If automatic reasoning selection is not available, or if the user wants to override it for a single turn, it would be useful to support lightweight inline markers in the prompt itself, not only a menu/hotkey flow.

    Examples:

    • @high investigate this failure and propose the fix
    • @medium summarize this diff
    • @xhigh review the architecture tradeoffs

    Why this helps:

    • it is faster than opening /model or another picker
    • it is naturally scoped to the current turn, so users do not have to remember to switch back afterward
    • it works well in copied prompts, saved workflows, and shell aliases
    • it can coexist with auto mode: explicit marker wins for that turn, otherwise auto/default policy applies

    Suggested semantics:

    • parse reserved effort markers at the start of the user message, e.g. @low, @medium, @high, @xhigh
    • apply only to the next submitted turn unless explicitly pinned
    • show the selected effort visibly before/while running, e.g. Effort: high (from @high)
    • avoid treating unknown @name mentions as effort markers, so this does not conflict with normal mentions or agent references

    A slash form like /effort high is also useful, but inline markers are lower-friction when the user already knows the desired effort for this one prompt.

  8. HubKing commented on May 9, 2026

    @HubKing
    HubKing
    on May 9, 2026

    I need this. As a Plus subscriber, I am very quota-conscious, so I try to use the lowest effort possible. But to switch the effort level in CLI, I need to type /model, then select the same model, and then select the effort level. Repeating this often is not fun.

    Either a simple /effort switch or better yet, maybe a custom preset. Like I can assign 1 to 5.5 low and 2 to 5.3-Codex xhigh in settings and then just type /model 1 or /model 2 to switch to it directly.

  9. etraut-openai
    added a commit that references this issue on Jun 20, 2026

    Allow resume and settings commands during tasks and MCP startup (#29154)

    d667082

  10. kevinb9n commented on Jun 23, 2026

    @kevinb9n
    kevinb9n
    on Jun 23, 2026

    It would be incredibly helpful for me if the color of something visibly changes based on the current selected reasoning level. That's about the only way I'll really notice it.

  11. unemployabot
    added a commit that references this issue on Jun 26, 2026

    checkpoint: into wallentx/termux-target from release/0.143.0 @ c13a6ba (

    dc2b92a
  12. wangjiecloud
    added a commit that references this issue on Jun 27, 2026

    Allow resume and settings commands during tasks and MCP startup (open…

    ab33751
  13. dkropachev
    added a commit that references this issue on Jul 5, 2026

    Allow resume and settings commands during tasks and MCP startup (open…

    05520d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions