Repository navigation
🔥🔥🔥🔥 Starting from 2026-07-13 , Codex's (to Server) response speed dropped threefold ( ⬇️ 3X). 🔥🔥🔥 #34064
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.715.31925
What subscription do you have?
200USD Pro
What platform is your computer?
MacOS 26.5.2 ARM
What issue are you seeing?
Codex GPT-5.6-Sol / 5.5-Pro latency regression / slow SSE streaming
I am seeing a significant latency regression when using Codex with gpt-5.6-sol.
This is not just subjective slowness. I compared recent local telemetry against my July 13 baseline using Cockpit/Codex request logs.
Current measurement
Measured at: 2026-07-18 13:21-13:22 (New York time)
| Metric | Current 30-minute window | July 13 baseline |
|---|---|---|
| First response median | 11.1s |
2.7s |
| First response P90 | 40.3s |
19s |
| Full request median | 20.1s |
11.4s |
| Full request P90 | 98.8s |
38s |
Current state
- Around
44established local Codex/Cockpit connections. 21requests started within the last 60 minutes but had not completed.15of those had not yet received the first streaming chunk.- No recent
429 Too Many Requestserrors were observed. - No recent
server_is_overloadederrors were observed. - Some failures were
cyber_policy, but those appear unrelated to the latency issue.
Summary
The severe overload / 429 errors appear reduced, but streaming latency has not returned to the July 13 baseline. The main remaining issue is high tail latency: first chunks and full completions are still much slower than before, especially at P90.
This affects active Codex development sessions because many tasks wait a long time before receiving the first response, even when the request eventually succeeds with HTTP 200.
Question
Is there an ongoing GPT-5.6 Sol / Codex streaming latency issue, especially for SSE-based streaming? If so, is there a recommended workaround or expected recovery timeline?
What steps can reproduce the bug?
NA
What is the expected behavior?
No response
Additional information
Feedback ID : 019e2c27-8d57-7ff1-8189-26d8db36913f
Activity
github-actions commentedon Jul 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Accademia commentedon Jul 19, 2026
What issue are you seeing?
Codex GPT-5.6 Sol daily latency regression
I am seeing a sustained latency regression in Codex when using
gpt-5.6-sol.The charts use daily averages grouped by New York date (EDT). July 12 is normalized to
100%. July 11 and July 19 are partial days because the retained dataset starts at 16:47 EDT on July 11 and July 19 was still in progress when the report was generated.🔥🔥🔥 performance dropped 3X
🔥🔥🔥 Latency tripled
Daily results
20.62s12.40s45.21s87.1%17.95s11.51s32.58s100.0%28.95s12.48s58.73s62.0%48.84s14.50s120.05s36.8%56.23s13.71s149.98s31.9%59.71s20.38s152.83s30.1%46.40s22.13s116.51s38.7%46.18s17.11s104.64s38.9%59.26s26.05s154.13s30.3%Method
Performance index = July 12 daily mean latency / observed daily mean latency x 100This is a latency-derived throughput proxy, not measured tokens/sec. It includes every successful
gpt-5.6-soltext request with a recorded positive full-request duration. Failed requests are excluded. First-response timing is not shown because retained first-chunk logs do not cover the full period.The live database and migration backups contain no comparable full-request latency records before July 11 at 16:47 EDT. Earlier days therefore cannot be plotted reliably. The partial July 11 sample was
87.1%of the July 12 baseline, so the available evidence does not show that performance was continuously at100%before July 12.Summary
17.95son July 12 to59.26son July 19 so far: approximately3.30xslower.100%to30.3%.32.58sto154.13s, showing a particularly severe long-tail regression.Please investigate whether there is an ongoing Codex /
gpt-5.6-solrequest and streaming latency regression.Other
I am not sure if Codex's recent free token reset for so many users has caused server congestion, leading to a massive drop in request performance. I am currently running more than 10 "20x Pro" accounts in parallel to develop different modules for a single project. Even though I pay over $2,000 per month, our project progress has slowed down by a factor of three over the past week.
🤮🤮🤮🤮🤮
I hope you can prioritize guaranteeing that performance does not drop for paying users before giving everyone token reset opportunities. As things stand, even if I wanted to spend more money to buy more tokens, it wouldn't help because the speed ceiling is completely bottlenecked. Because the request speed has dropped threefold, the token consumption rate has become too slow, meaning our current token quota cannot even be used up.
Therefore, I hope you can restore the performance to what it was before July 12th. If some users feel they are consuming tokens too quickly, you could offer them an option to intentionally reduce their response speed by three times (down to the current speed level). This way, everyone can get exactly what they need.
What steps can reproduce the bug?
NA
What is the expected behavior?
No response
Additional information
No response
dezmen3 commentedon Jul 22, 2026
It's real. My usual prompt task takes 30-40 minutes to execute, since few weeks now it's always over 1h to 2h :/ It's like it has some delay between server calls. Last time i had similar when i had many session files, after cleaning up session folder, logs, temp files, everything except memories and auth, it worked blazzing fast, now those steps do nothing
Windows 11 x64, codex cli 0.145.0