›_ Codex Issues
Codex Issues / #27379

CLI /fast docs mention on/off/status, but TUI behaves like a toggle

Open 💬 3 comments Opened Jun 10, 2026 by DCjanus
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.139.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

Codex CLI TUI.

Codex doctor report

not included; this looks like a slash-command parsing / documentation mismatch.

What issue are you seeing?

The public Codex docs say the CLI supports:

  • /fast on
  • /fast off
  • /fast status

Docs:

In codex-cli 0.139.0, /fast appears to behave as a local service-tier toggle, but the documented on, off, and status arguments do not appear to be parsed as explicit subcommands.

Manual check on codex-cli 0.139.0:

  1. Started the TUI with gpt-5.5 medium.
  2. Typed /fast on.
  3. The input rendered with /fast highlighted and on as trailing text.
  4. Submitted it.
  5. The TUI entered Working, token/context usage increased, and the assistant replied to the message.
  6. The status line still showed gpt-5.5 medium, not gpt-5.5 medium fast.

So /fast on is not behaving like a local "turn Fast mode on" command in the same way that bare /fast behaves as a local toggle.

What steps can reproduce the bug?

  1. Run codex with codex-cli 0.139.0.
  2. In the TUI, type /fast on.
  3. Submit it.
  4. Observe that it is handled like a user message rather than a local slash command.
  5. Compare with the docs, which describe explicit /fast on, /fast off, and /fast status forms.

What is the expected behavior?

Either:

  • /fast on, /fast off, and /fast status should be handled as documented; or
  • the docs should say that /fast is a bare toggle and remove the on/off/status examples.

Additional information

I could not find an existing issue or discussion specifically tracking this CLI documentation/behavior mismatch. Similar reports such as #25849 are about the Codex App, not this CLI TUI docs mismatch.

View original on GitHub ↗

3 Comments

etraut-openai contributor · 2 months ago

Thanks for reporting. This is a case of out-of-date documentation.

SylvainWinning · 2 months ago

I prepared an implementation branch for this in my fork: https://github.com/openai/codex/compare/main...SylvainWinning:codex/fast-service-tier-args?expand=1

Summary:

  • keeps bare /fast as the existing toggle behavior
  • accepts explicit /fast on, /fast off, and /fast status forms for the model service-tier slash command
  • handles both live composer input and queued slash commands
  • adds targeted TUI/composer coverage

Validation run locally:

  • cargo fmt --all -- --check
  • cargo test -p codex-tui fast_slash_command_accepts_on_off_status_args
  • cargo test -p codex-tui service_tier_slash_command_dispatches_with_args_from_catalog_name
  • cargo clippy -p codex-tui --lib -- -D warnings

I did not open an upstream PR because docs/contributing.md says external PRs are invitation-only, but happy to adjust or open one if a maintainer wants this direction.

linkai792644686 · 2 months ago

I can confirm this still reproduces on codex-cli 0.140.0.

Environment / model:

  • Codex CLI: codex-cli 0.140.0
  • Platform: macOS / Darwin arm64
  • Model: gpt-5.5
  • Reasoning effort: xhigh

What I observed:

  • codex features list shows fast_mode as stable true.
  • codex debug models shows gpt-5.5 advertises additional_speed_tiers: ["fast"] and service tier { id: "priority", name: "Fast" }.
  • Bare /fast is handled locally by the TUI and prints Service tier set to priority.
  • Running bare /fast again prints Service tier set to default, so the actual implementation behaves like a toggle.
  • /fast off and /fast status are not handled as local slash commands in this TUI session. They are persisted as normal user messages and start normal model turns.
  • The affected turns have model=gpt-5.5, reasoning_effort=xhigh, and no service_tier in the turn context.

So the issue still appears to be either:

  1. implement the documented /fast on, /fast off, and /fast status subcommands; or
  2. update the docs to describe the current behavior as a bare /fast toggle where priority = Fast and default = Standard/off.