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.create websocket frame, I don't see a service_tier field 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_tier comes back as default on 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, or
  • fast requires a specific entitlement/plan, but that isn't clear from the current behavior.

What steps can reproduce the bug?

  1. Use codex-cli 0.113.0 with ChatGPT auth.
  2. Configure:
model = "gpt-5.4"
service_tier = "fast"
  1. Run:
RUST_LOG=debug codex exec "Reply with OK only."
  1. Observe that Codex CLI uses websocket transport to /backend-api/codex/responses.
  2. Inspect the first outbound websocket response.create payload:

service_tier is not present.

  1. If service_tier: "fast" is injected directly into the websocket JSON request, the backend returns Unsupported service_tier: fast.
  2. On direct websocket probes with the same ChatGPT auth/account, the terminal response.completed.response.service_tier is default on 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 fast is 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 fast is requested, interpreted, or documented in ChatGPT-authenticated CLI mode.
  • If needed, I can provide redacted websocket header / first-event captures.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

  • #13960

Powered by Codex Action

defin85 · 5 months ago

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:

  • On native Codex CLI websocket captures, the first outbound response.create frame did not include a raw service_tier field.
  • On repeated direct websocket probes using the same auth style and no explicit service_tier field in the JSON payload, the terminal event completed successfully but returned response.service_tier = "default".
  • This reproduced across multiple tested accounts and across multiple attempts.
  • If service_tier: "fast" is injected directly into the websocket JSON payload, the backend responds with Unsupported service_tier: fast.

That makes it look like fast isn't selected via the obvious public request field in this websocket flow, even though the CLI config accepts service_tier = "fast".

If useful, I can also provide a redacted example of the first websocket headers and the first response.create frame.

pash-openai contributor · 5 months ago

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".
  • In this mode, Fast is handled by Codex routing logic server-side, so service_tier is not an end-to-end field you can reliably verify in the final response payload.
  • Because of that, seeing response.service_tier = "default" does not mean Fast was ignored.

Fast config is not being ignored.