GPT-5.5 performance and reliability seem significantly worse today

[GGBondBlueWhale]

Today, GPT-5.5 has felt significantly worse than usual in Codex.

It went through multiple rounds of conversation but still failed to fix a bug. Even worse, some of the attempted changes ended up breaking parts of my project that were previously working.

Over the past two days, this noticeably degraded Codex behavior has also caused repeated failed bug-fix attempts followed by rollbacks, wasting a large amount of my usage. My $200 Pro plan quota has already consumed around 60% of the weekly limit in just these two days because of these unsuccessful cycles.

This does not feel like normal model behavior compared with previous sessions. The debugging quality, consistency, and ability to preserve existing functionality all seem noticeably degraded today.

Is anyone else seeing the same issue with GPT-5.5/Codex today?

[github-actions]

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

• GPT-5.5/Codex reliability regression: context window error blocks an in-progress app bug fix #24378
• GPT-5.5 Fast suddenly feels as slow as Standard, with long thinking/context/search stalls #24422

Powered by Codex Action

[GGBondBlueWhale]

Additional feedback ID for reference: 019e5e71-b802-7be2-91a2-d9d9ddf5111e

[lumen-rot]

it feels better for me today actually maybe they gave me ur compute

[GGBondBlueWhale]

For me, it has actually been getting worse over the last two days.

GPT-5.5 has been struggling to fix even relatively basic bugs, and in long-context coding tasks the reliability has been especially poor. I have been seeing repeated failed fixes, regressions, and much weaker reasoning over the existing project context.

So in my case, the issue is not only speed/latency — long-context bug-fixing sessions have become much less dependable than before.

[JC-S]

I also observed similar slowdowns in response speed on my side. I have my own tooling that logs the input tokens, output tokens, cache-read tokens, and response time for each request.

After analyzing my logs, I found that around 5%–10% of requests took as long as 2–5 minutes to complete, even when the input and output token counts were not particularly high. Normally, requests of this type would complete within 30 seconds.

I started noticing this issue within the past 72 hours.

[JC-S]

I also observed similar slowdowns in response speed on my side. I have my own tooling that logs the input tokens, output tokens, cache-read tokens, and response time for each request.

After analyzing my logs, I found that around 5%–10% of requests took as long as 2–5 minutes to complete, even when the input and output token counts were not particularly high. Normally, requests of this type would complete within 30 seconds.

I started noticing this issue within the past 72 hours.

Here is an update on my findings:

It seems that around May 22, OpenAI introduced an IP-based per-minute request rate limit for subscription users.

When the number of requests per minute becomes too high, OpenAI’s servers may stop responding to new requests. In the Codex CLI client, there is a 300-second timeout counter, with some random variation. Once the client-side timeout is triggered, the client sends a retry request. By that time, the rate limit may have already been lifted, making it appear as if the original request simply took several minutes to complete.

Since my device has two public IP addresses, I tried assigning different sessions to different IPs, and the situation seems to have improved.

Of course, given the limited transparency across the full request chain, this is only an educated guess based on the information currently available to me.