ChatGPT Web Conversation History Returns Persistent 429 Rate Limit and Fails to Load

ChatGPT
,
1

Summary

Opening the ChatGPT conversation history/sidebar frequently triggers a temporary rate limit and prevents my conversation list from loading.

Environment

  • ChatGPT Plus

  • Windows desktop app and ChatGPT Web

  • Same account on both

  • Very large conversation history: several thousand conversations

Problem

When I open the conversation history/sidebar, ChatGPT frequently displays:

You’re making requests too quickly. We’ve temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again.

When this happens, the sidebar can become completely empty and I can no longer access my conversation history.

Normal ChatGPT usage continues to work. The problem appears specifically related to loading the conversation history.

Network evidence

Using Chrome DevTools, I can reproduce the problem when opening the sidebar.

Requests such as:

GET /backend-api/conversations?offset=0&limit=28&order=updated_at...

return:

429 Too Many Requests

At the same time, other ChatGPT backend requests continue returning 200 OK.

This suggests that the rate limit specifically affects the conversation-history endpoint rather than my general ChatGPT usage.

Possible trigger

I notice this problem particularly often after launching the ChatGPT Windows desktop application.

It appears possible that the desktop application and ChatGPT Web are simultaneously loading or synchronizing the conversation history, resulting in too many requests to /backend-api/conversations.

My account contains several thousand conversations, which may make the issue easier to reproduce.

Persistence of the issue

I have already waited for several hours before testing again, but the problem still occurs.

The warning continues to reappear even after a long period without intentionally refreshing or repeatedly opening the conversation history.

This does not appear to be a short-lived rate limit that clears after a few minutes as the message suggests.

Steps to reproduce

  1. Use a ChatGPT account with a very large conversation history (several thousand conversations).

  2. Launch the ChatGPT Windows desktop application.

  3. Open ChatGPT Web using the same account.

  4. Open the conversation-history sidebar.

  5. Observe the requests to /backend-api/conversations.

  6. The endpoint returns HTTP 429 Too Many Requests.

  7. The conversation sidebar becomes empty.

  8. ChatGPT displays the temporary conversation-access rate-limit warning.

  9. Wait several hours and try again.

  10. The same error can still occur.

Expected behavior

Opening or synchronizing conversation history during normal use should not trigger a user-facing rate limit.

If multiple official ChatGPT clients are connected to the same account, conversation-history requests should be cached, deduplicated, queued, or otherwise handled without temporarily preventing access to the user’s conversations.

Accounts with very large conversation histories should also remain usable.

If a temporary rate limit is applied, it should actually clear within the time suggested by the warning rather than remaining reproducible several hours later.

Actual behavior

The /backend-api/conversations endpoint becomes rate-limited.

As a result:

  • the conversation sidebar fails to load;

  • the conversation list becomes empty;

  • access to existing conversations is temporarily unavailable;

  • reopening the sidebar can immediately reproduce the 429 response;

  • the problem can still occur several hours later;

  • other parts of ChatGPT can continue working normally.

Additional observation

If I keep the conversation sidebar closed, ChatGPT generally continues functioning normally.

Opening the sidebar triggers the conversation-history requests and can immediately cause the error again.

Please investigate the conversation-history synchronization/loading behavior between the Windows desktop application and ChatGPT Web, particularly for accounts containing several thousand conversations, and whether the rate-limit state can become stuck or persist much longer than intended.

2

I can independently corroborate this on ChatGPT Web. As a ChatGPT Pro subscriber paying about $200 per month, I consider this a serious usability problem because ordinary conversation-management actions in the official web client can expand into many history requests.

Environment

  • ChatGPT Pro
  • Firefox 153 on Linux Mint, X11/GTK
  • Europe/Zurich (CEST, UTC+2)
  • Multiple ChatGPT tabs were open

Ordinary manual behavior

On my 32-inch monitor, opening a new ChatGPT tab or window commonly requires at least two sequential 28-item history loads to populate the sidebar. Multiple open tabs repeat that work.

I then tested deleting one conversation manually through the normal ChatGPT interface—not through the bulk-delete extension. That one deletion produced at least these six follow-up requests in the browser Network panel:

  1. GET /backend-api/conversations with offset 0, limit 28
  2. the same list request with offset 28
  3. the same list request with offset 56
  4. GET /backend-api/conversation/{redacted}
  5. GET /backend-api/pins
  6. one client-telemetry request

Renaming a conversation causes the same general problem: multiple already-loaded history pages are fetched again rather than updating the affected item locally. The exact request count depends on how many history pages the window has already loaded.

This is not a hypothetical cleanup case. As of 22 August 2026, I have been manually deleting selected conversations for roughly two weeks and have only worked back to conversations from around 2024. “Delete all” is not an equivalent solution because I need to retain some conversations while removing others.

Where conversations contain personal data and ChatGPT’s Delete control is used to request erasure, this also raises an EU data-protection concern. GDPR Article 12(2) requires controllers to facilitate the exercise of data-subject rights, and Article 17 provides a right to erasure without undue delay when one of its grounds applies. I cannot determine legal compliance from these network captures, and the GDPR does not prescribe a particular conversation-management interface. However, a supported selective-deletion path that takes weeks and is then disrupted by rate limits raises a serious question about whether rights are being effectively facilitated and merits review by OpenAI’s privacy/legal team. Whatever the design intent, the practical effect is to discourage users from cleaning up selected history.

Separate rate-limit stress reproduction

I later used the third-party ChatGPT Bulk Delete Firefox extension only as a stress tool to reach the threshold quickly. That trace is not the basis for the single-manual-delete observation above, and it does not establish the cadence of repeated manual deletions.

In that retained stress trace on 22 August 2026 at about 00:59 CEST:

  • 22 history-list requests covered offsets 0, 28, 56, 84, and 112;
  • the first 13 returned HTTP 200 and the next 9 returned HTTP 429;
  • additional list requests continued after the first 429 instead of entering an effective cooldown; and
  • the “Too many requests” dialog appeared about 69 ms after the first retained 429 completed.

The throttled state then persisted across conversation hydration. Over approximately the next minute, five stream_status requests returned 200 while five conversation-preview requests and five fallback-detail requests returned 429. Conversation preparation, initialization, and one steer request also returned 200. The capture therefore shows successful run-control requests occurring while related conversation-preview and detail reads were being rejected—a state consistent with the display and reconciliation failures I observed.

After this limit has activated, I have also seen a busy conversation in regular Chat using Pro reasoning (not a Work chat) show a red “Network error” when I tried to send a steering message. I then had to stop the chat and ask it to continue from where it stopped. The retained stress trace does not prove that the model run itself failed—the steer request in that capture returned 200 while hydration remained rate-limited—so the generic error may instead reflect failed follow-up hydration or reconciliation.

Expected behavior

  • A single rename or deletion should update the affected cached history record instead of refetching every previously loaded page.
  • Coalesce identical and in-flight history requests, including across same-account tabs where possible.
  • Substantially raise the authenticated request limit for conversation-history list and detail operations—or use separate, appropriately sized rate-limit pools for sidebar synchronization and open-conversation hydration—so ordinary multi-tab use and supported high-volume conversation management do not trigger HTTP 429 responses. This should complement, not replace, eliminating redundant refetches, coalescing requests, and using bounded server-side batching.
  • After a 429, stop automatic pagination/retries, honor any Retry-After value, and show a real retry time.
  • Preserve the last-known authorized state of unaffected/open conversations when a refresh is throttled, with a visible “sync delayed” indication rather than an empty or unusable page.
  • For deletion, hide the selected conversation immediately and either confirm or restore it according to the mutation result. Successfully deleted data should not remain accessible merely because a cache is stale.
  • For rename, update the title optimistically and reconcile that one record without reloading all history pages.
  • Provide supported multi-select/bulk rename, archive, and delete operations with bounded server-side batching, visible progress, retry, and partial-failure reporting.
  • At minimum, ordinary multi-tab use and a single supported rename or deletion should not trigger a 429. If a user selects 100 conversations to rename or delete, the official client should queue and complete the batch reliably within a reasonable time—without requiring manual pacing over days or weeks or starving open-conversation hydration.
  • Rate limiting should remain compatible with legitimate authenticated data-management use. I cannot determine the limit’s security purpose from these captures, but the official client should shape, batch, or queue that traffic rather than fail unpredictably.
  • Do not let a history-read throttle prevent an already-open conversation from hydrating or reconciling after a run-control request succeeds.

All report-relevant request counts, offsets, statuses, timing, and limitations are included above because the Community reply composer available to me does not offer general file attachments. I will not publish the raw Firefox profiles: they contain conversation text, URLs, identifiers, signed realtime values, extension inventory, and unrelated browser state. I can provide a reviewed/redacted diagnostic through a Support-approved transfer route.

3

I tried reaching the AI support, and it actually provided a solution. What worked for me :

Fully quit the Windows desktop app (make sure it’s not running in the tray), then sign out of ChatGPT on web and back in.

  1. In Chrome, delete site data for chatgpt.com (cookies + storage), restart Chrome, and relog.

To delete cookies/site data for just one site:

  1. Open https://chatgpt.com

  2. Click the lock/sliders icon next to the address bar → Site settings

  3. Click Clear data (or Delete data) for the site