GPT-5.5 performance and reliability seem significantly worse today

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

• #24378
• #24422

Powered by Codex Action

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

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

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.

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.

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.

@etraut-openai

When an MCP server has many tools and skills, it naturally generates more requests. In practice, this causes rate limits to be reached very quickly, making the system unreliable.

The issue becomes much worse when using sub-agents. In many cases, sub-agents become practically unusable because they consume the available request quota too fast.

This also makes the purpose of /fast mode questionable.

The expectation of /fast mode is that responses are generated more quickly. However, if requests are processed faster, users end up hitting rate limits sooner and can then be blocked from making progress for 3–4 minutes at a time. The overall experience becomes slower, not faster.

Could you please review whether the current rate limiting behavior is working as intended, especially for workflows that rely heavily on MCP tools, skills, and sub-agents?

Adding another data point for the current GPT-5.5 / Codex reliability regression.

Environment:

• Codex CLI: 0.142.5
• Model: gpt-5.5
• Reasoning effort: xhigh
• Date observed: 2026-07-02
• Interface: local Codex CLI session

Behavior pattern:

• User asks a narrow question; Codex answers with extra unasked framing/caveats, then has to be corrected.
• User challenges tone/interpretation; Codex over-explains and becomes overconfident before enough evidence is gathered.
• Diagnostic questions are treated as permission to propose or discuss file changes, which feels condescending and reduces trust.

Two recent examples from one session:

1. User asked whether Reddit had noticed a behavior pattern. Codex answered the Reddit question but added an unasked caveat about whether this proves an official backend downgrade. The user had not made that claim.
2. User asked why a duplicated AGENTS instruction block kept appearing. Codex initially asserted a symlink/load explanation too strongly from partial evidence, then had to walk it back after checking session logs and filesystem state.

Expected behavior:

• Answer the narrow question first.
• Mark uncertain causal explanations as hypotheses.
• Do not add judgment frames the user did not ask for.
• Do not propose file changes unless the user asks for a fix.

This overlaps with the older tone/instruction-following report in #7771, but I am adding it here because it is showing up as part of the current GPT-5.5 reliability and instruction-following regression.