🔥🔥🔥🔥 Starting from 2026-07-13 , Codex's (to Server) response speed dropped threefold ( ⬇️ 3X). 🔥🔥🔥

Open 💬 3 comments Opened Jul 18, 2026 by Accademia
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 44 established local Codex/Cockpit connections.
  • 21 requests started within the last 60 minutes but had not completed.
  • 15 of those had not yet received the first streaming chunk.
  • No recent 429 Too Many Requests errors were observed.
  • No recent server_is_overloaded errors 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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32987
  • #33024
  • #32990

Powered by Codex Action

Accademia · 1 month ago

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

<img width="1600" height="700" alt="Image" src="https://github.com/user-attachments/assets/6e282ea8-3262-41a8-87bd-75afc6b4e219" />

🔥🔥🔥 Latency tripled

<img width="1600" height="700" alt="Image" src="https://github.com/user-attachments/assets/b2fea4f6-0984-433d-b1fc-277ce81ae7dc" />

Daily results

| New York date | Successful requests | Mean full-request latency | Median | P90 | Performance index |
|---|---:|---:|---:|---:|---:|
| 2026-07-11 (partial) | 7,849 | 20.62s | 12.40s | 45.21s | 87.1% |
| 2026-07-12 | 37,717 | 17.95s | 11.51s | 32.58s | 100.0% |
| 2026-07-13 | 40,190 | 28.95s | 12.48s | 58.73s | 62.0% |
| 2026-07-14 | 29,577 | 48.84s | 14.50s | 120.05s | 36.8% |
| 2026-07-15 | 26,211 | 56.23s | 13.71s | 149.98s | 31.9% |
| 2026-07-16 | 26,130 | 59.71s | 20.38s | 152.83s | 30.1% |
| 2026-07-17 | 38,157 | 46.40s | 22.13s | 116.51s | 38.7% |
| 2026-07-18 | 30,714 | 46.18s | 17.11s | 104.64s | 38.9% |
| 2026-07-19 (partial) | 22,426 | 59.26s | 26.05s | 154.13s | 30.3% |

Method

Performance index = July 12 daily mean latency / observed daily mean latency x 100

This is a latency-derived throughput proxy, not measured tokens/sec. It includes every successful gpt-5.6-sol text 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 at 100% before July 12.

Summary

  • Mean full-request latency increased from 17.95s on July 12 to 59.26s on July 19 so far: approximately 3.30x slower.
  • The latency-derived performance index fell from 100% to 30.3%.
  • The P90 increased from 32.58s to 154.13s, showing a particularly severe long-tail regression.
  • The regression is visible across consecutive daily aggregates, not only isolated samples.

Please investigate whether there is an ongoing Codex / gpt-5.6-sol request 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 · 1 month ago

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