What variant of Codex are you using?
CLI (codex-cli 0.144.0, macOS, ChatGPT auth)
What feature would you like to see?
Two related asks around Fast mode in non-interactive use:
1. Warn when the serviced tier differs from the requested tier. #31284 added a client-side warning when the configured service tier isn't advertised by the model catalog. The silent case remains: the request goes out with the tier and the server declines it. response.completed already reports the tier that actually serviced the request, so the client has what it needs to surface "Fast mode was requested but this turn ran on standard."
2. Clarify (and ideally support) Fast mode for codex exec. Related: #22622. Verified on 0.144.0 and an instrumented build of main (6138909): with service_tier = "priority" in config.toml (what /fast on persists) and the fast_mode feature enabled, codex exec turns DO transmit "service_tier":"priority" in the websocket response.create payload — but the backend echoes service_tier:"auto" and response.completed reports "default". Same result on gpt-5.6-sol and gpt-5.5, so it is not model-specific. If Fast mode is intentionally unavailable for headless traffic, documenting that (plus the warning from ask 1) would save users the investigation; if it's meant to work, honoring the transmitted tier would be even better.
Additional information
Repro:
# config.toml: service_tier = "priority"; features fast_mode enabled
RUST_LOG=trace codex exec -m gpt-5.6-sol -c 'service_tier="priority"' "Reply with exactly one word: ok"
# trace shows the outbound response.create payload carrying "service_tier":"priority",
# response.created echoes "auto", response.completed reports "default"
Why headless matters: the Codex plugin for Claude Code (https://github.com/openai/codex-plugin-cc) delegates review/rescue work through the local Codex CLI and app server, so codex exec-style non-interactive runs are becoming a primary surface. Plugin users who configure Fast mode currently get the standard tier with no signal anywhere that their setting isn't taking effect.
What variant of Codex are you using?
CLI (codex-cli 0.144.0, macOS, ChatGPT auth)
What feature would you like to see?
Two related asks around Fast mode in non-interactive use:
1. Warn when the serviced tier differs from the requested tier. #31284 added a client-side warning when the configured service tier isn't advertised by the model catalog. The silent case remains: the request goes out with the tier and the server declines it.
response.completedalready reports the tier that actually serviced the request, so the client has what it needs to surface "Fast mode was requested but this turn ran on standard."2. Clarify (and ideally support) Fast mode for
codex exec. Related: #22622. Verified on 0.144.0 and an instrumented build of main (6138909): withservice_tier = "priority"inconfig.toml(what/fast onpersists) and thefast_modefeature enabled,codex execturns DO transmit"service_tier":"priority"in the websocketresponse.createpayload — but the backend echoesservice_tier:"auto"andresponse.completedreports"default". Same result ongpt-5.6-solandgpt-5.5, so it is not model-specific. If Fast mode is intentionally unavailable for headless traffic, documenting that (plus the warning from ask 1) would save users the investigation; if it's meant to work, honoring the transmitted tier would be even better.Additional information
Repro:
Why headless matters: the Codex plugin for Claude Code (https://github.com/openai/codex-plugin-cc) delegates review/rescue work through the local Codex CLI and app server, so
codex exec-style non-interactive runs are becoming a primary surface. Plugin users who configure Fast mode currently get the standard tier with no signal anywhere that their setting isn't taking effect.