# "Could not load this ChatGPT conversation" **URL:** \ **Category:** Bugs\ **Tags:** chatgpt, custom-gpt\ **Created:** [October 5, 2026, 2:30am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341 "2026-10-05T02:30:10Z")\ **Posts on this page:** 11\ **Page:** 2
**Author:** ![zhangjaychou](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/zhangjaychou/32/158559_2.png) [@zhangjaychou](https://community.openai.com/u/zhangjaychou)\ **Post date:** [October 15, 2026, 3:22am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/21 "2026-10-15T03:22:20Z")
Hi everyone, I’m also heavily affected by the “Could not load this ChatGPT conversation” error and wanted to add a detailed report so the team has as much information as possible. ### Environment - Platforms: ChatGPT Web (Chrome / Edge / Brave), official macOS desktop app, and iOS app - Plan: ChatGPT Pro - Affected scope: Almost all existing conversations (both regular chats and those inside Projects). New chats can usually be started, but opening any previous conversation frequently fails. - Frequency: Happening daily since late September 2026. Sometimes it affects nearly every chat; other times it hits roughly every second or third conversation. The problem is intermittent but very persistent. ### What happens 1. The conversation list in the sidebar loads normally and shows all my previous chats. 2. When I click any existing conversation, the page shows exactly: **“Could not load this ChatGPT conversation”** 3. Clicking “Try again” sometimes works after many attempts (sometimes 20–50+ clicks or hard refreshes), but the conversation often becomes unloadable again shortly afterward. 4. Related errors I also see: - “Connection interrupted. Waiting for the complete answer” - “ChatGPT stream recovery polling timed out” - “Error in message stream” - Network tab frequently shows **HTTP 429 Too Many Requests** even when I’m not sending many requests. Interestingly, the same conversation that fails on the web version sometimes loads fine on the iOS app (or vice versa). Archived chats seem even more problematic. ### What I’ve already tried - Hard refresh (Ctrl+Shift+R / Cmd+Shift+R) - Signing out and back in - Incognito / private window with all extensions disabled - Different browsers (Chrome, Edge, Brave, Safari) - Official desktop app - Waiting several hours / overnight and trying again None of these permanently solve the issue. The error keeps coming back. ### Impact This is seriously disrupting my workflow. I have important ongoing projects and long conversations that I can no longer reliably access. Having to spam “Try again” or refresh dozens of times just to open a single chat is extremely frustrating, especially for a paid subscription. ### Additional observations - The problem does **not** seem limited to ChatGPT Work or Cloud runs — it happens on normal chats as well. - Long conversations appear more likely to fail, but short ones are also affected. - Data itself does not seem deleted (I can still see the titles and, when it eventually loads, the full history is there). The issue appears to be with loading / retrieving the conversation from the server. I’ve seen many similar reports across multiple threads since around September 24–28, 2026, so this is clearly a widespread backend or frontend reliability problem rather than an isolated account issue. Could the OpenAI team please look into this urgently? A proper fix or at least a clearer status update would be greatly appreciated. Happy to provide conversation URLs, timestamps (with timezone), browser version, or a HAR file privately via support if needed. Thanks in advance for any updates. ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [October 16, 2026, 3:23pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/22 "2026-10-16T15:23:50Z")
Hi everyone, Thanks for flagging this and sharing the additional details. We’re investigating the conversation-loading issue further and will post an update once we have more information. ~ Ziad ---
**Author:** ![abdullahkassha](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/abdullahkassha/32/620309_2.png) [@abdullahkassha](https://community.openai.com/u/abdullahkassha)\ **Post date:** [October 16, 2026, 6:38pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/23 "2026-10-16T18:38:55Z")
I experienced a similar issue on October 16, 2026, around 17:23 CEST (UTC+2), using ChatGPT Plus on Chrome (Windows). While organizing my ChatGPT conversations, I opened at least 35 existing conversations from the **Recents** section in the sidebar. Afterward, multiple conversations started displaying **“Could not load this ChatGPT conversation”** , and several other ChatGPT features also stopped working. After waiting for some time, everything returned to normal without any intervention. Could loading a large number of conversations in succession trigger temporary rate limiting, request throttling, or another issue affecting the web interface? I couldn’t verify the underlying cause, but I’m sharing the sequence of events in case it helps reproduce and investigate the problem. ---
**Author:** ![drive.cloud.x1](https://avatars.discourse-cdn.com/v4/letter/d/db5fbb/32.png) [@drive.cloud.x1](https://community.openai.com/u/drive.cloud.x1)\ **Post date:** [October 17, 2026, 6:05pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/24 "2026-10-17T18:05:53Z")
Dear OpenAI Support Team, I am writing to formally report a critical and ongoing issue with ChatGPT that has severely disrupted my professional work over the past two weeks. Since the beginning of October 2026, I have been regularly encountering the following error when attempting to open conversations, including newly created chats: **“Failed to load this ChatGPT conversation.”** Button: **“Retry”** The issue occurs particularly when I run several ChatGPT conversations in parallel. Once the error appears, the affected conversations become temporarily inaccessible. Sometimes I have to wait 10 minutes before they become available again; in other cases, the disruption lasts an hour or longer. **This is no longer an occasional technical issue. It has become a persistent, systemic problem that makes ChatGPT practically unusable for my professional workflows.** Furthermore, since approximately August 2026, I have observed a dramatic deterioration in both the performance and analytical quality of the available models. Previously, I could execute complex analytical prompts simultaneously across 5–10 conversations and receive results within approximately 5–15 minutes. Today, the same prompts and workflows frequently fail due to conversation loading errors and other service disruptions. **As a result, tasks that previously took me 5–15 minutes now take 2–3 days to complete using ChatGPT.** This represents an unacceptable degradation of a paid service. The situation also raises serious concerns about whether OpenAI has introduced undisclosed resource limitations, concurrency restrictions, or other capacity-management mechanisms that negatively affect paying subscribers. Reports from other users suggest that similar problems are affecting customers on significantly more expensive subscription plans, including plans costing $100 and $500. What makes this situation particularly frustrating is that an OpenAI representative has acknowledged in a community discussion that the issue is being investigated. However, users have not received a clear explanation, a resolution timeline, or even actionable recommendations for mitigating the problem. For customers who depend on ChatGPT for professional analytical work, this lack of transparency and practical support is deeply disappointing. **I request that OpenAI provide specific answers to the following questions:** 1. Is OpenAI officially aware of the recurring “Failed to load this ChatGPT conversation” error, particularly when multiple conversations are running simultaneously? 2. What is the root cause of these failures, and is the problem related to infrastructure capacity, server-side resource allocation, or newly introduced concurrency limits? 3. Have any restrictions on parallel conversations, computational resources, or model usage been introduced or tightened since August 2026? 4. What immediate workarounds can affected users apply to restore reliable access to their conversations? 5. What is the expected timeline for a permanent resolution? 6. How does OpenAI intend to address the significant loss of service availability and productivity experienced by paying customers? @OpenAI_Support I expect this issue to be escalated to the appropriate technical team and investigated as a serious service reliability incident rather than treated as an isolated browser or connectivity problem. **The current service reliability is unacceptable for a paid product used in professional environments.** Please provide a substantive technical response, practical mitigation recommendations, and a clear update on the investigation and resolution timeline. ---
**Author:** ![shodan](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/shodan/32/448534_2.png) [@shodan](https://community.openai.com/u/shodan)\ **Post date:** [October 18, 2026, 12:53pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/25 "2026-10-18T12:53:10Z")
Hi, I think what is happenning is that there is a invisible rate limiting system that we are hitting. But the real problem is that this system is also VERY buggy. What I suspect OpenAI is trying to do is prevent resale of their service and ultimately to incite customer to subscriber to upgrade their subscription to higher tier, but in a way that will prevent user from coordinating some backlash and especially with regards to the timing of the IPO proceedings. The reason we can’t even read our chat and at least start writing next prompts is because the rate limiting system doesn’t stop prompts, it stop you entirely from opening a chat at all. Once you can read and scroll you are not subject to rate limiting. So what should happen to at least let us read our chats and prepare the next prompt while we’re on timeout, is to have a prompt queue system, where the system will process the next prompt once the rate limiting cooldown expires. And they will probably do this so that you have to go in and press enter … Because overt rate limiting signs create clear signals that automation could use to wire in an external MCP server or other AI agents which could then use your chatgpt pro subscription as a much cheaper source of token. I think that some transparency about the cool down, their durations, when we’re in timeout (there are multiple layers of cooldown and timeout btw). Transparency AND bugfixes, because, you can have just one chat going, but “something” happens with that chat and it will bug out your account. In one case I got banned and deactivated pending appeal and in many more cases my account got in a kind of lockdown with a message about “to protect your account we have restricted access” All of these system are clearly cobbled together, try to stay invisible and opaque, try to defeat commerial operators and the result is an increasingly frustrating user experience. ---
**Author:** ![rok1](https://avatars.discourse-cdn.com/v4/letter/r/c6cbf5/32.png) [@rok1](https://community.openai.com/u/rok1)\ **Post date:** [October 18, 2026, 3:00pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/26 "2026-10-18T15:00:20Z")
I actually suspect the problem might be something entirely different. What I’ve noticed recently is that **ChatGPT has become incredibly resource-hungry, even when simply opening existing conversations.** On my PC, just opening a ChatGPT tab can consume **around 1 GB of RAM per tab** , along with unusually high CPU usage. This wasn’t happening before. Something has clearly changed in how ChatGPT loads or handles conversations. And I’m pretty confident it’s not my computer, because **the exact same thing happens on my iPhone** , both in the official ChatGPT app and in Safari. In Safari, conversations frequently reload themselves, seemingly because of memory pressure. In the ChatGPT app, the situation is sometimes even worse: the app simply crashes or closes. What’s particularly interesting is that **sometimes just opening an existing conversation triggers a “Could not load this conversation” error** , without even submitting a new prompt. This makes me suspect that ChatGPT might be loading or processing far more data in the background than it used to, potentially getting stuck in some kind of loop, memory leak, or inefficient loading process. It almost feels like some of these apparent “limits” aren’t intentional rate limits at all, but rather **the application overwhelming itself with unnecessary processing or resource consumption.** Of course, actual server-side rate limiting may also exist, but I don’t think it explains why simply reading an existing conversation can bring both a powerful desktop computer and an iPhone to their knees. **OpenAI really needs to investigate client-side memory consumption, CPU usage, conversation loading, and potential memory leaks.** Something has noticeably deteriorated recently, and it’s affecting the most basic functionality: simply opening and reading our conversations. ---
**Author:** ![farvint](https://avatars.discourse-cdn.com/v4/letter/f/b38774/32.png) [@farvint](https://community.openai.com/u/farvint)\ **Post date:** [October 18, 2026, 7:01pm UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/27 "2026-10-18T19:01:13Z")
### Possible cause of loading failures: repeated recovery of one stuck conversation affecting access to other chats @OpenAI_Support, I would like to share a possible explanation for some of the conversation-loading failures being investigated here. **Observed symptoms** During a prolonged incident, ChatGPT conversations failed to load across multiple devices and network connections, while Codex remained usable. Most conversations displayed **“Could not load this ChatGPT conversation.”** Because affected conversations usually would not open, their contents and response states were not visible. On the rare occasions when one particular conversation loaded, it remained stuck in the **“Thinking”** state even though there had been no user interaction with it for many hours. This made the possible source difficult to identify: the visible failure affected many conversations, while the unfinished response in one conversation was usually hidden behind the same loading error. **Evidence from the local application logs** The local application logs showed the following sequence for the stuck conversation: 1. The client retained a reference to the unfinished conversation and automatically rebound the interface to its conversation route. 2. An attempt to resume the response returned: 3. The client then emitted: 4. Background requests for that conversation’s history subsequently continued approximately once per minute, without manual retries. 5. During the observed period, **225 requests returned HTTP 429 — Too many requests**. Two additional requests returned HTTP 500. All recurring requests targeted the same conversation. No comparable request loop was found for other conversations in the available local application logs. **What changed after intervention** The affected conversation was deleted after it remained in the **“Thinking”** state and could not be loaded reliably. After deletion: - the conversation disappeared from the active conversation list; - the associated background requests were no longer observed; - the once-per-minute requests to that conversation stopped appearing in the logs. I then deliberately waited approximately **105 minutes** without loading other ChatGPT conversations or sending ChatGPT messages. After that pause, I tested two previously inaccessible conversations individually. Both loaded successfully, and no new HTTP 429 responses were observed. Access was not tested immediately after deletion. Therefore, these observations do not establish whether deletion itself restored access, whether the subsequent waiting period was necessary, or how long any rate-limit cooldown might have been. **Hypothesis to investigate** Could automatic recovery traffic consume a rate limit shared with ordinary conversation loading? If so, an unfinished conversation might repeatedly attempt recovery, fail to resume its response stream, encounter rate limiting, and remain unable to reconcile its state with the server. Other conversations could then become inaccessible if their history requests share the same limiting mechanism. This could explain why many hours without direct user interaction do not necessarily resolve the problem while a client remains open or automatically restores an unfinished conversation. It could also explain why users may be unable to identify the source. A conversation they try to open might be affected by recovery traffic originating from a different conversation, while the loading failure prevents them from seeing that the source conversation is still marked as unfinished. This is a single-case observation and remains a hypothesis. The logs confirm a recovery sequence, recurring requests, repeated HTTP 429 responses, and cessation of those requests after deletion. Access was restored later, after a period without manual ChatGPT requests. These observations do not establish the exact rate-limit scope or prove causation. **Possible areas for investigation or improvement** - Reconcile resume failures with the server’s actual turn status. - Place a clear limit on unsuccessful recovery attempts. - Respect `Retry-After` when present and apply increasing backoff after repeated failures. - Prevent duplicate recovery attempts caused by interface restoration, route rebinding, or focus changes. - Check whether background recovery requests can exhaust capacity required to load unrelated conversations. - Make a stuck recovery process visible to the user. - Provide a supported way to cancel recovery even when the conversation cannot be loaded, while preserving the conversation and its history. Could the engineering team check whether this sequence matches the failures under investigation and correlate the recovery requests with the relevant rate-limit counters? ---
**Author:** ![shodan](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/shodan/32/448534_2.png) [@shodan](https://community.openai.com/u/shodan)\ **Post date:** [October 20, 2026, 3:29am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/28 "2026-10-20T03:29:21Z")
I’m not sure but, I’m starting to think merely having open chatgpt tabs is enough to trigger the rate limits and all the other nasty things ! Then you do the following ![2026-10-19_23h13s57_x](https://us1.discourse-cdn.com/openai1/original/4X/6/e/4/6e4f5d26c8d87a64180274c071104498226e52d3.gif) I am pretty sure this “activates” a tab. Before you do that, maybe it doesn’t count toward your limit, but I’m pretty sure after you do, it counts as whatever the max limit of your threads is. I used to have 20-30 tabs of chatgpt on different topics or aspects. And I would go to one, and then another and read and ask prompts. I noticed at about 4-6 actually running prompt, all the other tabs started malfunctionning. The first thing that goes, is the enumeration of your chats. ![image](https://us1.discourse-cdn.com/openai1/original/4X/a/5/0/a50a7c64960c26a1ca5fa83e9d25238ddd044333.png) Only way to find your chats now is, already open tabs, bookmarks and the search Then you start to get errors like ![2026-10-19_23h19s20_firefox_Could_not_load_this_ChatGPT_conversation_-_ChatGPT_1070x96](https://us1.discourse-cdn.com/openai1/optimized/4X/f/8/f/f8f9859617604c1f22c8afa34e25a08407e8c150_2_690x61.png) ![image](https://us1.discourse-cdn.com/openai1/original/4X/e/5/2/e5296f774745125673d34659504cbaeee4baf78c.png) Which sometimes can be fixed by just refreshing the tabs But eventually, you will tray refreshing the tab and you will get these ![image](https://us1.discourse-cdn.com/openai1/original/4X/e/5/1/e51fef8c0daeea4bebfff5d5d609a1b6a44f916e.png) At this point you are in time out, your active chats will continue but you won’t be able to load anything else and your newest? oldest? chats will start malfunctionning until your number of active chat is under some unknown, probably dynamic limit. If you persist, because the limits are unknown so there’s no reason not to keep trying You will get these ![image](https://us1.discourse-cdn.com/openai1/original/4X/f/d/b/fdb54928528b364ed22e6eec67e2c34c931767fc.png) Now you have activated anti abuse security system, you account is now in danger If you persist anyway This will happen ![image](https://us1.discourse-cdn.com/openai1/original/4X/4/b/2/4b200499f79c377a57d92bd75fa31fb5ad0b9d56.png) And now you must repent, my account was locked out for hours while ,y prayer/appeal to the machine god was waiting. Eventually the machine showed mercy and allowed me to have my history of tens of thousands of chats. You might not be so lucky. ---
**Author:** ![Yukime](https://avatars.discourse-cdn.com/v4/letter/y/9dc877/32.png) [@Yukime](https://community.openai.com/u/Yukime)\ **Post date:** [October 20, 2026, 6:55am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/29 "2026-10-20T06:55:26Z")
Here is why it is happening, I have tested it with exporters before : There are multi-scale level limits at per 5 minute, per 1 minute and per 15 minute intervals and you can get step-up or step-down in lockout time extensions all the way up to 30 minutes if you keep repeatedly sending requests. A local account aggregates all the chat / Non-Work / Codex simultaneous use. If you have over 250 chats distributed across your projects/non-projects and try to load them, you will hit the rate limit immediately. OpenAI used to render the entire page, then they switched to lazy loading, then they switched to lazy loading with buffer pre-rendering like Youtube videos, now they switch to on-request loading with first pre-cached last 10 prompts or whatever and if you keep going to historical pages say 6 times in a row you hit the limits quickly if a session had 50-300 prompts or you fork a lot like I do. You used to be able to scroll down 2 years worth of convos, not anymore if you have over 300-600 chats. If you open 5 concurrent tabs and have it running, you hit a rate limit at the 15-25 minute mark; and if you open 6 burst tabs or a browser or more if you switch between them and type you also hit a rate-limit. If they are simultaneously working each tab for over 10-20 minutes, the latest tab will time out and the first tab will disconnect you roughly 20-40 minutes depending on how long the task is. It used to work about up to an hour or two but they cut it down to 25 minutes at some point now it is some kind of adapt-rate limiting where concurrency of requests and burstiness determines whether you can see your historical chats or not. If you didn’t do burst activity of 3 concurrent chats or more working, you can stretch it to 40 or 50 minutes or so if nothing is happening on non-Pro answers. After loading 50-80 chats, you need to wait like 1-2 minutes to scroll another amount otherwise you get hit with a 5-minute limit. Since they have this all projects-crap of toggling I think they auto-load it in background too so when you check-mark it or not, you are screwed because the account fetches the chat list and thinks you have that many concurrent accountst o prevent anti-distillation or botting or whatever. This is a global shared limit across all platforms and browsers. ChatGPT work and Codex also get blocked if you use chat, but the reverse is not true with simultaneous sessions on Codex/Work. So they are trying to prevent you from using 3,000 chat messages or viewing your account history by making you spend 1-2 hours scrolling to see your past chats, or even going up any chat with more than 100KB in cache with rendering times taking up to 8 seconds per loading of 10-20 prompts or whatever. It is obnoxious and annoying and it has rolled out since the first iteration change of mass UI-consolidation, with multiple iterations after that. Same crap with the time-back machine button and requiring you to start a different chat. The step-up timer is something like 1 minute, then 3.5 minutes, then 5 minutes, then 15 minutes, then 30 minutes and eventually lockout. Same with deleting chats, it is literally a misery to browse-quickly through your chats or search them up to see what you were talking about, you can’t open shit like e-mails. After say 6 consecutive starting new chats or deletions within 1 minute you get-rate limited. The safest way is like 1 request per 15 seconds globally including tool calls and deletes or whatever, though not one message per active session. I think about 20 consecutive messages in same tab in under a minute also rate-limits you. When I say loading I mean like the left chat bar going to see your chat history, if you launch simultaneous tabs from opening a browser or reinstating an inactive memory you will quickly reach rate-limits upon 8 simultaneous chats or so loading. It is literally ridiculous that closing and opening your browser does this shit, well if you start typing a message in two tabs at least. One should be able to scroll across 100 chats, they should pre-buffer and pre-render chats in the background at least last 250 recents like YouTube does with 30 most recent chats with more messages loaded, and not rate limit you unless you exceed 5 concurrent active sessions with free-use to message between each but no more than 4/minute per tab or 15/minute per tab if you need to do some rapid chatting. Right now it’s like, if you have concurrent tabs working after 3-4, if accumulates X active time you get that perma-rate limiting shit so you aren’t allowed to see your chats. It starts with like 20 chats, then goes down to 10 then to 5 then zero unless you saved hotlink chats. Pretty lame. ---
**Author:** ![shodan](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/shodan/32/448534_2.png) [@shodan](https://community.openai.com/u/shodan)\ **Post date:** [October 20, 2026, 10:21am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/30 "2026-10-20T10:21:48Z")
Thank you, Everything you said aligns with my experience except you have a much clearer picture. They make these opaque changes and they won’t tell us because they’re going to nickel and dime as much as it take to get a certain percentage of pro user to convert to the higher tiers. Last week I was writing prompt absolutely non-stop on 5-8 concurrent chats at high thinking level it was pretty amazing, it all came crashing down out of nowhere, lost a week just figuring out how everything works again, that is so frustrating. It’s clear they don’t want to say what the limits are, probably going to be dynamic per-user, based on what kind of work they’re doing and going to extremely manipulative they’re going to figure out they just need to navigate the thin line between “frustration and quit” and “frustration and upgrade”. Classic abusive silicon valley behaviour. edit : Also getting plain file download problems ![image](https://us1.discourse-cdn.com/openai1/original/4X/d/5/7/d57934839cf8d14c6ed77c94c8547e320605e79b.png) And also sometimes it just can’t create a file at all ![image](https://us1.discourse-cdn.com/openai1/original/4X/4/d/b/4db0ed47890b0c451f8ec1cbb57178c9997f6ea9.png) ---
**Author:** ![adey1234](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/adey1234/32/448288_2.png) [@adey1234](https://community.openai.com/u/adey1234)\ **Post date:** [October 21, 2026, 5:16am UTC](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341/31 "2026-10-21T05:16:21Z")
Hi everyone, I am adding my experience here because I have been dealing with similar ChatGPT reliability problems for nearly two weeks and have been unable to get a clear resolution through OpenAI Support. I first reported the problem on 10 October. Initially, ChatGPT responses would fail after processing, displaying “This response couldn’t load”. Since 17 October, the problem has continued and become considerably worse. As of 21 October, I have experienced failures affecting approximately a dozen conversations, potentially more. Some now fail to open entirely and display “Could not load this ChatGPT conversation” with a Retry button. This is happening across newer and older conversations in my paid ChatGPT workspace. I have reproduced the conversation-loading problem in Chrome Incognito mode. On mobile, I have also encountered “Too many requests” errors. These are not simply disposable conversations. They contain ongoing project work and important context. When a conversation becomes inaccessible, I cannot continue the work or reliably determine the state of any ongoing tasks. **My concern is now as much about the support process as the original technical problem.** My current support case is #17498433, following my original report under #16878068. I appreciate that support has acknowledged the issue and referred it to a specialist. They have requested additional diagnostic information, including conversation identifiers. I raised some privacy questions about sharing these identifiers and have subsequently provided example links through private correspondence. However, despite repeated follow-ups, I have not received a case-specific technical finding, confirmation of what has actually been investigated or a practical solution that restores access to my existing conversations. The repeated requests for information, without a clear explanation of how the investigation is progressing, have become quite frustrating. I have also noticed what appears to be declining usage credits while some conversations and potentially running tasks are inaccessible. I cannot establish whether these are related but would appreciate that being checked as well. **@OpenAI_Support, could someone please help clarify the following?** Is case #17498433 being investigated alongside the wider conversation-loading problems reported here? Has there been any account-side or technical investigation of the failed requests, particularly the possible rate-limiting behaviour? Can someone confirm whether the specialist team has taken ownership of the case and what the next concrete investigation step will be? Most importantly, is there a supported way to restore access to affected conversations without losing their existing context? I am willing to provide further targeted diagnostics privately where they genuinely help investigate the issue. What I am looking for now is some evidence of technical progress rather than another general troubleshooting checklist. I would also be interested to hear whether others are still experiencing these failures as of 21 October, particularly across multiple conversations and devices. Thanks, Adrian [Previous page](https://community.openai.com/t/could-not-load-this-chatgpt-conversation/1403341.md?page=1)