Selecting `gpt-5.3-codex` in Codex shows response.model = `gpt-5.2-2025-12-11`

Resolved 💬 8 comments Opened Feb 6, 2026 by UniverseFly Closed Feb 10, 2026
💡 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.98.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Darwin 24.1.0 arm64 arm

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

Terminal.app

What issue are you seeing?

When I select gpt-5.3-codex in Codex, the returned Responses API object reports a different model: gpt-5.2-2025-12-11.

Log evidence (PII redacted) from ~/.codex/log/codex-tui.log:

2026-02-05T21:02:42.597590Z  INFO  codex_tui::chatwidget: Selected model: gpt-5.3-codex, Selected effort: xhigh

2026-02-06T21:34:23.110590Z TRACE codex_api::sse::responses: SSE event: {"type":"response.completed","response":{"model":"gpt-5.2-2025-12-11", ...}}

What steps can reproduce the bug?

  1. Run Codex with SSE tracing enabled:

``bash
RUST_LOG='codex_tui::chatwidget=info,codex_api::sse::responses=trace' codex
``

  1. In the model picker, select gpt-5.3-codex (effort xhigh).
  2. Send any prompt (e.g. “hello”).
  3. Inspect ~/.codex/log/codex-tui.log and find the response.completed SSE event; observe response.model is gpt-5.2-2025-12-11.

What is the expected behavior?

If I choose gpt-5.3-codex, I expect response.model reflects gpt-5.3-codex.

Additional information

_No response_

View original on GitHub ↗

8 Comments

etraut-openai contributor · 5 months ago

If you're able to repro this, please use /feedback to upload your logs and session details, then post the thread ID here.

UniverseFly · 5 months ago
If you're able to repro this, please use /feedback to upload your logs and session details, then post the thread ID here.

Thanks for the guidance. Here is the thread id: 019c3695-daf8-7b11-b5df-f53832fb233d.

etraut-openai contributor · 5 months ago

Have you continued to see this problem, or was this a one-time issue?

UniverseFly · 5 months ago

Yes, the issue still existed in my try just now. Is there a way to verify which model is routed for inference in the backend? My guess is either incorrect routing (the underlying model isn't gpt-5.3-codex) or a less severe missing mapping that triggers a fallback model name in the final response (the underlying model is still gpt-5.3-codex).

theBucky · 5 months ago

same, #11189

aryasaatvik · 5 months ago

ran into this issue. thread id 019c484e-b025-7d90-9c9c-5a63edb2b741

MisterRound · 5 months ago
etraut-openai contributor · 5 months ago

I'm going to consolidate this issue in #11189. I just posted a response there.