GPT-5.4 Fast and GPT-5.5 Fast are extremely slow (~1 token/s)
What version of the Codex App are you using (From “About Codex” dialog)?
26.519.41501 (3044)
What subscription do you have?
chatgpt pro 20x
What platform is your computer?
Darwin 25.3.0 arm64 arm
What issue are you seeing?
GPT-5.4 Fast and GPT-5.5 Fast have become extremely slow over the past 2–3 days.
Previously, responses were near real-time, but now both models frequently:
- stall during thinking
- take 10–30+ seconds before first token
- stream at ~1 token/s or even slower
- feel almost identical to standard/deep reasoning latency
This happens even with:
- low effort
- fast mode
- small prompts
- new sessions
- simple repositories/tasks
The issue became very noticeable around May 24–26.
Environment:
- Codex app
- macOS
- GPT-5.5 Fast
- GPT-5.4 Fast
- low effort mode enabled
Current experience is significantly worse than last week.
What steps can reproduce the bug?
- Open Codex.
- Start a new session.
- Select GPT-5.5 Fast or GPT-5.4.
- Set reasoning/effort to Low.
- Send a simple coding prompt, for example:
Please explain what this function does and suggest one small improvement.
or:
Please update this component to change the button label from "Submit" to "Save".
- Observe the response speed.
Expected behavior:
The model should respond quickly in Fast / Low mode, with normal streaming speed.
Actual behavior:
Both GPT-5.4 and GPT-5.5 Fast are extremely slow. The model often waits a long time before the first token, then streams at around 1 token/s or slower. This happens even for simple prompts and new sessions.
This started becoming very noticeable around May 24–26, 2026.
Session ID:
N/A / I can provide one if needed.
Token limit usage:
Not near the limit.
Context window usage:
Low. This also happens in new sessions with simple prompts.
What is the expected behavior?
_No response_
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Honestly, this has easily become the most annoying thing I’ve ever faced using Codex of late. It feels like Codex officially running on CPU. Since my workflow is Codex backend and Claude frontend, Opus will take on a task complete it — no frustrations whatsoever ! It returns and ready for more while Codex seems to be on vacation 30 min later stuck on 2 simple “greps”. Sadly my pro subscription renewed before all this but I hear Mythos is going public soon. Codex was good while its maintainers cared but I guess also on vacation.
关闭fast模式,反而变快了
Seeing more reports like this lately 👀 The slowdown pattern here feels broader than isolated model inference latency.
What makes this especially notable is that the slowdown doesn’t sound purely inference-related.
A lot of the symptoms seem to cluster around:
Once modern coding agents start mixing:
tool execution + context compression + retrieval + model routing + long-running sessions,
“model latency” becomes surprisingly hard to separate from “runtime scheduling latency”.
In heterogeneous runtimes, users often perceive all orchestration overhead as “the model became slow,” even when the bottleneck may actually sit in routing, continuation scheduling, compaction policy, or backend queue behavior.
We’ve been observing similar patterns while exploring capability-routing / execution-optimization layers:
the more dynamic the runtime becomes, the harder it gets to maintain predictable latency characteristics across sessions 😊
Really useful report.