CLI: `service_tier = "fast"` is unclear / appears ineffective in ChatGPT websocket mode
Resolved 💬 3 comments Opened Mar 10, 2026 by defin85 Closed Mar 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
codex-cli 0.113.0
What subscription do you have?
Tested with ChatGPT Plus and ChatGPT Team accounts.
Which model were you using?
gpt-5.4
What platform is your computer?
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
Windows Terminal (WSL), xterm-256color
What issue are you seeing?
service_tier = "fast" appears ineffective or at least unclear in ChatGPT-authenticated Codex CLI websocket mode.
What I observed:
- Codex CLI uses websocket transport to
wss://chatgpt.com/backend-api/codex/responses. - After inspecting the first outbound
response.createwebsocket frame, I don't see aservice_tierfield in the JSON payload. - If
service_tier: "fast"is forced directly into the websocket JSON request, the backend responds with an error like:
{"type":"error","status":400,"error":{"type":"invalid_request_error","message":"Unsupported service_tier: fast"}}
- On direct websocket probes using the same ChatGPT auth tokens and account IDs, terminal
response.completed.response.service_tiercomes back asdefaulton the tested Plus and Team accounts.
So from the outside it looks like:
service_tier = "fast"in CLI config doesn't have an obvious effect in ChatGPT-auth mode, orfastrequires a specific entitlement/plan, but that isn't clear from the current behavior.
What steps can reproduce the bug?
- Use
codex-cli 0.113.0with ChatGPT auth. - Configure:
model = "gpt-5.4"
service_tier = "fast"
- Run:
RUST_LOG=debug codex exec "Reply with OK only."
- Observe that Codex CLI uses websocket transport to
/backend-api/codex/responses. - Inspect the first outbound websocket
response.createpayload:
service_tier is not present.
- If
service_tier: "fast"is injected directly into the websocket JSON request, the backend returnsUnsupported service_tier: fast. - On direct websocket probes with the same ChatGPT auth/account, the terminal
response.completed.response.service_tierisdefaulton the tested accounts.
What is the expected behavior?
One of these should be true:
service_tier = "fast"should actually request/select fast tier when the account is entitled to it, or- Codex CLI should reject or warn that
fastis unsupported in this auth mode, or - The docs/config behavior should explicitly clarify which plans/entitlements are expected to return
fast.
Additional information
- The websocket transport itself appears to work fine.
- The issue is specifically about how
fastis requested, interpreted, or documented in ChatGPT-authenticated CLI mode. - If needed, I can provide redacted websocket header / first-event captures.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Follow-up runtime note with redacted observations.
I tested this a bit more using direct websocket requests against
wss://chatgpt.com/backend-api/codex/responses, staying as close as possible to native ChatGPT-authenticated Codex CLI behavior.What I observed:
response.createframe did not include a rawservice_tierfield.service_tierfield in the JSON payload, the terminal event completed successfully but returnedresponse.service_tier = "default".service_tier: "fast"is injected directly into the websocket JSON payload, the backend responds withUnsupported service_tier: fast.That makes it look like
fastisn't selected via the obvious public request field in this websocket flow, even though the CLI config acceptsservice_tier = "fast".If useful, I can also provide a redacted example of the first websocket headers and the first
response.createframe.Thanks for the detailed report. The behavior is confusing, but what you’re seeing is expected in ChatGPT-authenticated Codex mode:
service_tier = "fast"in config is a Codex setting, not a raw websocket value you can send as"fast".service_tieris not an end-to-end field you can reliably verify in the final response payload.response.service_tier = "default"does not mean Fast was ignored.Fast config is not being ignored.