# Recurring “Too many requests” blocks conversation access during normal use — plus an unresolved incident-ownership loop

What issue are you seeing?

Summary

Since approximately mid-August 2026, I have repeatedly encountered the following condition during normal interactive ChatGPT use:

Too many requests
Access to conversations is temporarily restricted.

This is not merely a model-message rate limit.

When the condition occurs, the web application can also prevent access to existing conversations and therefore block ongoing work contexts.

The issue has repeatedly occurred despite substantial usage capacity still being displayed.

I formally reported the problem to OpenAI Support on 20 August 2026.

As of 1 September 2026, I still have:

• no confirmed root cause;
• no explanation of which specific server-side limit is being triggered;
• no explanation of why the visible usage indicators can show substantial remaining capacity while conversation access is restricted;
• and no clear incident owner.

The technical issue itself is serious.

The incident-handling loop that followed has become a second problem.

---

Environment / affected surfaces

Observed on:

• ChatGPT web
• normal interactive use
• long-running conversation contexts
• ChatGPT Work

The same account may remain usable through another ChatGPT surface while the web application is affected.

This therefore does not behave like a simple account-wide subscription exhaustion condition.

---

Observed behaviour

In one documented occurrence, the ChatGPT interface still showed approximately:

• 79% remaining in the visible five-hour allowance;
• 58% remaining in the visible weekly allowance.

Despite that, the “Too many requests” restriction occurred.

Another recurring pattern:

1. Stop using ChatGPT for approximately one hour.
2. Access becomes available again.
3. Resume normal interactive work.
4. After approximately ten minutes and very few interactions, the same restriction returns.
5. In some occurrences it can return almost immediately after one additional interaction.

This is not automated bulk traffic.

It is normal interactive use.

---

Impact

The restriction does more than reject a new model request.

It can prevent me from opening existing conversations.

For long-running projects, this means that the current working context becomes temporarily inaccessible.

The issue has also occurred while using ChatGPT Work.

That turns a rate-limit-style condition into a continuity problem: I cannot reliably know whether an existing work context will remain accessible.

---

Related public reports

This appears related to an existing cluster of reports, including:

• #37518 — repeated /conversations HTTP 429 responses
• #38503 — “Too many requests” temporarily restricts access to conversations and disrupts Work tasks
• #38763 — conversation history blocked during normal ChatGPT use

I am not asserting that all of these reports necessarily have the same root cause.

I am asking OpenAI to correlate them.

Substantially similar conversation-access/rate-limit symptoms were therefore already being publicly reported around the time my own problem began.

Irrespective of what internal knowledge those public reports created, OpenAI had direct notice of my individual incident no later than 20 August 2026.

---

The second problem: incident ownership

I have more than 25 years of professional experience in IT and IT support.

I do not expect every technical incident to be solved immediately.

Complex incidents take time.

What I do expect from a professional support process is:

• incident ownership;
• preservation of the incident history;
• meaningful status communication;
• functional escalation when first-line troubleshooting is exhausted;
• management escalation where appropriate;
• and a clear distinction between automated triage and specialist investigation.

That is where this case becomes unusual.

---

Support / escalation timeline

20 August

Formal incident reported.

The recurring behaviour and its impact on ongoing paid ChatGPT use were described.

Following days

Additional technical observations were supplied.

Among other things, I specifically asked OpenAI to investigate:

• which server-side limit or mechanism generates the restriction;
• why it does not correspond with the visible usage indicators;
• why it can recur after substantial inactivity and very little subsequent use;
• why ChatGPT Work is also affected;
• whether routing, serving or rate-limit changes correlate with the behaviour.

I explicitly did not claim a root cause that I could not establish client-side.

I requested server-side investigation.

Original incident subsequently closed

The underlying problem was still occurring.

I later escalated the closure because I had not received a substantive explanation of the technical cause or a meaningful incident status.

Management escalation

I explicitly stated that I did not want to restart generic first-line troubleshooting.

The response nevertheless came from AI-assisted support and returned to generic troubleshooting.

A new case reference was generated.

I then explicitly asked for the new case to be correlated with the original incident and again requested escalation beyond automated/first-line handling.

Specialist response

OpenAI later stated in writing that it still had:

• no confirmed root cause for the recurring restriction;
• and no confirmed information explaining why the original unresolved incident had been closed.

This is one of the most concerning points in the entire timeline.

Contractual / Legal escalation

Because the incident remained unresolved and the closure itself could not be explained, I sent a formal escalation outside the ordinary support process.

I explicitly stated that it should not simply be returned to automated or routine first-line troubleshooting.

The result:

A third case reference was created.

The response again began:

“I’m AI-assisted support for OpenAI.”

It again requested troubleshooting evidence and referred me to generic rate-limit guidance.

At the same time, it told me to consolidate the previous two case references.

The consolidation request itself therefore arrived under yet another newly created case.

---

The loop

This is the part I believe deserves investigation independently of my individual account.

The effective sequence has been:

technical incident

→ first-line handling

→ additional technical evidence

→ unresolved incident closed

→ escalation

→ AI-assisted first-line handling

→ new case

→ request for specialist / management escalation

→ no confirmed root cause

→ no confirmed explanation for original closure

→ formal escalation beyond normal support

→ AI-assisted support again

→ another new case

→ request to consolidate the previous cases.

At this point my central question is no longer only:

What is generating the “Too many requests” restriction?

It is also:

Who actually owns this incident?

---

Incident-management questions

I am not claiming that ITIL mandates a particular L1/L2/L3 organisational structure.

I am using the following questions as ordinary incident-management / service-desk questions:

Ownership

Who owns an unresolved incident end-to-end?

Functional escalation

At what point does repeated unsuccessful first-line troubleshooting result in transfer to someone capable of server-side investigation?

Hierarchical escalation

At what point can a customer obtain management review when the incident itself — and even the reason for its closure — remains unexplained?

Incident history

Why did escalation repeatedly generate additional case references instead of maintaining one coherent incident record?

Closure

Under what condition was the original incident considered suitable for closure while the reported problem continued?

Communication

What status should a customer receive when:

• the incident remains unresolved;
• no root cause has been established;
• and investigation requires additional time?

AI-assisted support

Most importantly:

At what point does “AI-assisted support” stop assisting support and start replacing it?

Automation is useful for intake, classification, FAQ retrieval and routine troubleshooting.

But when a customer explicitly requests escalation because routine troubleshooting has failed, sending that escalation back through essentially the same automated flow creates a support loop from which the customer has no visible exit.

---

Expected behaviour — technical

Normal interactive ChatGPT use should not unexpectedly block access to existing conversations.

If a conversation-history endpoint or another backend service is being rate-limited:

1. the UI should identify the relevant type of limit;
2. it should distinguish that condition from model/subscription usage limits;
3. displayed usage information should not imply substantial available capacity while another undisclosed limit blocks conversation access;
4. clients should use appropriate request deduplication and backoff;
5. existing conversation history should remain accessible whenever technically possible;
6. ChatGPT Work should receive a coherent recoverable error state rather than losing reliable access to ongoing work.

---

Expected behaviour — support / incident management

Once routine troubleshooting has been exhausted:

1. one incident should retain clear ownership;
2. additional escalation should not repeatedly create disconnected cases;
3. the complete incident history should follow the escalation;
4. a specialist should be able to state what has actually been investigated;
5. unresolved incidents should not be closed without a documented reason;
6. a management escalation should not simply return to the same automated first-line loop;
7. a formal escalation beyond ordinary support should not result in yet another automated first-line case unless that routing is explicitly intended and explained.

---

What I am asking OpenAI to investigate

I am not asking GitHub maintainers to resolve a compensation or contractual dispute.

Those matters are being handled separately.

For this repository, I am asking for technical and process correlation:

1. Is my recurring conversation-access restriction part of the same technical cluster as #37518, #38503 and #38763?

2. Which backend endpoint or rate-limit mechanism is responsible for the conversation-access restriction?

3. Can normal ChatGPT UI behaviour itself generate enough requests to trigger that mechanism?

4. Why can visible usage limits show substantial remaining capacity while this restriction is active?

5. Why does the restriction affect existing conversation access rather than only new requests?

6. Why can the same account remain usable on another ChatGPT surface?

7. Why is ChatGPT Work affected?

8. Is there a server-side diagnostic identifier or account event that Support/Engineering can correlate with the occurrence timestamps already provided privately?

9. How should Support correlate this technical issue with an existing support incident without repeatedly opening new cases?

10. Who owns the incident once routine first-line troubleshooting has demonstrably failed?

---

Why I am posting this publicly

I first reported my own incident privately on 20 August 2026.

I continued attempting to resolve it through the normal support and escalation channels.

I am posting the technical and incident-management aspects publicly because, after repeated escalation, OpenAI has told me that it still does not have a confirmed root cause and cannot presently explain why the original unresolved incident was closed.

The purpose of this issue is therefore not to attack individual support staff.

It is to document a reproducible service problem and ask whether the support/escalation architecture surrounding that problem is functioning as intended.

If a company uses AI to assist customer support, that can be entirely reasonable.

But the resulting system still needs a reliable exit from automated triage into accountable human investigation.

Otherwise the escalation mechanism itself becomes a loop.

---

Final question

After nearly two weeks, the question is no longer merely:

Why am I being rate-limited?

It is:

Who at OpenAI owns responsibility for resolving an incident once the automated support path has failed?

What steps can reproduce the bug?

see above

What is the expected behavior?

see above

Additional information

see abov

No Codex file, test, or entry point is identified. Start by verifying whether the reported ChatGPT web and conversation-access behavior belongs in this repository, then review the referenced issues #37518, #38503, and #38763 for technical overlap. Done would require confirmed repository relevance and a maintainer-defined investigation scope, not a self-contained code change.