[CLI] Shift+Down no longer cycles reasoning effort to Ultra

Open 💬 3 comments Opened Jul 13, 2026 by f1nando

What version of Codex CLI is running?

codex-cli 0.144.3

What subscription do you have?

ChatGPT account with Ultra access; the exact tier is not exposed in the CLI.

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal / Windows PowerShell 5.1.26100.8655; no terminal multiplexer.

Codex doctor report

{
  "status": "not available",
  "reason": "codex doctor --json timed out after 60 seconds while the active Codex CLI session was running"
}

What issue are you seeing?

After updating Codex CLI from 0.144.2 to 0.144.3, Shift+Down no longer lets me cycle the reasoning-effort selector all the way to Ultra in the TUI.

Previously, this was a very convenient and fast way to switch reasoning effort without opening /model.

Ultra is still available for gpt-5.6-sol through /model or model_reasoning_effort="ultra", so this appears to be a TUI shortcut/model-picker regression rather than an availability issue.

What steps can reproduce the bug?

  1. Run Codex CLI 0.144.3 in Windows Terminal with PowerShell.
  2. Use model gpt-5.6-sol in an interactive TUI session.
  3. Press Shift+Down to cycle the reasoning-effort selector.
  4. Continue cycling toward the highest reasoning setting.
  5. Observe that the quick selector no longer reaches Ultra as it did in 0.144.2.

Uploaded thread: 019f5d37-957a-7bf0-a3d7-fb73a9193c4d

What is the expected behavior?

Shift+Down should continue cycling through the available reasoning-effort settings, including Max and Ultra, as it did previously. Alternatively, please provide an option that includes Max and Ultra in quick reasoning-effort cycling.

Additional information

The model catalog still advertises Ultra for gpt-5.6-sol, and setting model_reasoning_effort="ultra" is accepted. The regression affects the convenient keyboard workflow rather than access to Ultra itself.

View original on GitHub ↗

3 Comments

DeepThinkingZhouLiu · 1 month ago

Please restore a fast keyboard path to Max and Ultra reasoning in Codex CLI.

The change introduced in 0.144.3 creates a significant usability regression:
users can quickly lower reasoning effort, but cannot quickly raise it to the
strongest available level. When a task turns out to be difficult, requiring
/model -> current model -> More reasoning... adds unnecessary friction.

Please provide one of the following:

  1. Allow Shift+Up / Alt+. to reach Max and Ultra;
  2. Add an opt-in setting that includes advanced levels in shortcut cycling; or
  3. Add a dedicated shortcut for Max and Ultra.

Users who frequently switch between simple and difficult tasks need a symmetric,
keyboard-first workflow. Preventing accidental usage can remain the default, but
experienced users should be able to opt into faster access.

PaulRBerg · 1 month ago

yes, this is very annoying and it's a regression, please allow Max and Ultra to be toggled via key bindings! @etraut-openai

Rycen7822 · 16 days ago

I traced this behavior to the intentional guard that keeps Max and Ultra out of ordinary shortcut cycling, so simply restoring silent cycling would also restore the risk of accidentally selecting a high-usage level.

A possible compromise is to preserve the keyboard-first workflow while keeping an explicit confirmation boundary:

  • When the reasoning-up shortcut would move from XHigh to Max, or from Max to Ultra, open a native Yes/Cancel confirmation surface matching the existing Full Access confirmation layout.
  • Opening the confirmation must not change reasoning effort or persist any setting.
  • Yes applies the target effort only for the current session. In normal mode this updates the session reasoning effort; in Plan mode it updates only the Plan-mode override.
  • Cancel or Esc leaves the current effort unchanged.
  • Downward cycling remains immediate, including Ultra → Max → XHigh.
  • The Ultra confirmation includes the existing multi-agent concurrency/usage warning when applicable.
  • The first version prompts every time and does not add a persistent bypass or global opt-in.

I have a local prototype against main using the existing SelectionViewParams, SelectionItem, and standard Enter/Esc footer. Its focused TUI coverage includes both advanced transitions, no event before confirmation, confirm/cancel behavior, Plan-mode event semantics, popup ownership, downward cycling, and Max/Ultra snapshots. The relevant tests pass locally.

Would this interaction and owner seam be acceptable to the Codex team? If so, would a maintainer explicitly invite a PR for #32874? I will not open one without an invitation.