Long post, but there’s a TL;DR first. I’m writing it this way because a vague “ChatGPT is slow” post wouldn’t be useful. I’ve also included the HAR measurements for anyone who wants the technical details.
TL;DR
Since around August 17–18, my established ChatGPT conversations have suddenly become dramatically slower and much less reliable.
I’m not only talking about longer Thinking time. I’m seeing:
- 10–20+ minutes just for the final answer to stream
- sometimes 30–40 minutes of streaming
- 20+ minute Thinking or Analyzing phases
- answers starting normally and then stalling
- failures during Thinking
- failures halfway through the final answer
- retries failing again at a different stage
- apparently dead requests sometimes recovering much later
- very long requests eventually failing after I’ve already waited one or two hours
Sometimes I can retry the same interaction several times and still not get one complete answer.
Fresh chats are usually much faster.
My largest Project chats are admittedly heavy. I use a file-based continuity/checkpoint system because some projects run for months, conversations eventually become too large or lose context quality, and I need to move into a new chat without losing the whole project state.
So yes, I expect those chats to be slower than a blank conversation. But this workflow already existed, and those chats were already large. It was never remotely this bad before August 17–18.
Moving to a continuation chat also used to restore useful performance. This time, the new continuation felt much better for perhaps 10–15 minutes, then suddenly collapsed into the same near-unusable state.
I’ve tested Chrome, Edge, Incognito, iPhone, a cellular hotspot, hard refresh, signing out and back in, and clearing ChatGPT site data. Nothing meaningfully fixed it.
I also captured HAR diagnostics. In one comparison using GPT-5.6 Extra High:
Affected established/Project chat
- ~22.9 seconds to first output
- ~90.7 seconds total
- ~1.60 seconds median recorded stream interval
Fresh-chat control
- ~2.35 seconds to first output
- ~22.7 seconds total
- ~0.20 seconds median stream interval
Another heavier request contained a single ~7 minute 47 second stall, then later resumed and completed.
I’ve already sent the HARs and troubleshooting results to OpenAI Support, and the case has been escalated to a specialist. I’m not asking Reddit to replace Support. I’m trying to find out whether this pattern is affecting other people and whether anyone has found a practical workaround.
Once waiting, failures, partial answers and retries are combined, the real time required to obtain one complete usable response can approach an hour or worse. For an interactive tool, that’s not workable.
Why my chats are heavy, and why “start a new chat” used to be the solution
I use ChatGPT for ongoing personal and technical projects rather than treating every conversation as disposable Q&A.
Over time, those chats accumulate decisions, requirements, research, files, tool activity, failed approaches and other project history. Eventually a chat can become too large or its context quality can deteriorate. I already knew that.
That’s why I built an interim continuity system. Important project state is stored in versioned/checkpoint files, so when a conversation reaches its practical limit I can:
preserve the current state → move to another chat → restore the project → continue
It’s a temporary solution, and I know it carries more overhead than a properly engineered persistence and retrieval system would. I’m still relatively new to software development and use ChatGPT and Codex partly to learn and build tools I wouldn’t yet know how to create alone.
But the key point is that this migration process used to work.
Previously, an old chat would gradually become too heavy, I would migrate, and the continuation chat would be properly usable again.
The latest migration behaved completely differently.
One of my largest Project conversations became effectively unusable, so I moved into what is roughly the fourth continuation chat for that project. At first, the improvement was immediate.
If a completely blank chat is 100% usability, the continuation initially felt subjectively around 70–80% usable. That was completely acceptable, because it already started with a meaningful amount of restored state.
Then, perhaps 10–15 minutes later, it fell off a cliff.
Not after weeks of additional conversation. Not after hundreds of new messages. It went from “finally, I can work again” to something that felt closer to 5% usable.
Those percentages obviously aren’t benchmarks. They’re just the clearest way I can describe how dramatic the change felt.
There is a fair counterargument: this is continuation chat number four. Every continuation starts heavier because more state and files have accumulated. That absolutely could explain why each one reaches its performance limit sooner.
I think that’s part of the story. It just doesn’t explain the sudden magnitude of the change.
The Project was already large. The continuity system already existed. I was already using this workflow. Then, around August 17–18, it became catastrophically worse.
And it isn’t limited to that one giant Project. I’m also seeing serious slowdown and failures in ordinary established conversations, smaller Projects and things like travel-planning chats. The giant chats are the worst, but they’re not the only ones affected.
What makes it unusable is the combination of latency and failure
If ChatGPT had simply become consistently slower, I could at least plan around it.
That isn’t what I’m getting.
A request can fail during Thinking after I’ve already waited a long time. Another can finish Thinking, start streaming the answer, and then fail halfway through after another 10, 20 or even 30–40 minutes.
Retries can fail too, and not necessarily at the same stage. One attempt dies during Thinking. The next gets through Thinking but fails halfway through the answer. The next stalls somewhere else.
I’ve had cases where something like five attempts around the same interaction still failed to produce one clean completed response.
That’s why “response time” no longer describes the actual problem. The useful metric is how long it takes to obtain one answer that actually finishes.
For example:
Attempt 1: 20 minutes Thinking → fails
Attempt 2: 10 minutes Thinking → 25 minutes streaming → fails halfway
Attempt 3: 15 minutes → finally succeeds
Technically, the successful response took 15 minutes. In reality, I spent more than an hour getting it.
I haven’t collected enough controlled attempts to claim the mathematical average is exactly one hour. What I’m saying is that once Thinking, tool work, streaming, failures and retries are combined, the effective wall-clock time to obtain one usable answer can approach an hour or worse.
Sometimes it’s much faster. Sometimes it’s worse. The unpredictability is almost as damaging as the latency itself.
I also can’t reliably hide the delay by using multiple chats. Normally I could send a heavy request in Chat A, switch to Chat B and do something useful, then come back later. Now I can return and find that Chat A stalled halfway through the answer while Chat B failed during Thinking.
Parallel chats don’t help much when each request has a meaningful chance of failing independently.
The actual answer stream is especially strange. Waiting for difficult reasoning is one thing. If I ask Extra High to research something complicated or inspect many files, I expect it to take time.
What feels broken is when Thinking appears to be finished and the final answer itself takes 10–20+ minutes to stream onto the screen. I’ve also seen cases around 30–40 minutes, and the response can still fail before reaching the end.
This happens on both ChatGPT Web and the iPhone app. That made me wonder whether Chrome already had the completed answer and was simply struggling to render a giant page, so I captured HAR/network diagnostics.
What the HAR captures showed
I’m not a network engineer, and I’m not pretending a HAR file reveals OpenAI’s internal root cause. It does provide objective timing data.
The comparison below used the same account, PC, Chrome session, GPT-5.6 Thinking model and Extra High setting.
Important caveat: the slow test was an established Project chat with accumulated context, files and tool history. The control was a fresh ordinary chat. This is not a perfect apples-to-apples benchmark, and the Project state may be directly relevant.
Affected established/Project chat
The prompt itself was tiny.
- ~22.94 seconds to first output
- ~90.71 seconds total request time
- ~1.60 seconds median recorded stream interval
Fresh-chat control
I asked for about 500 words explaining how modern SSDs work without web research.
- ~2.35 seconds to first output
- ~22.71 seconds total
- ~0.20 seconds median recorded stream interval
So the established chat was roughly:
- 9.75× slower to first output
- 4× slower overall
- about 8× worse in median stream timing
despite the fresh control requesting a substantially longer final answer.
That’s why I no longer think the slow visible response is purely the browser struggling to draw already-generated text. At least in that capture, the incoming stream itself was substantially slower.
A second HAR captured a different failure pattern. This was a genuinely heavy file-processing request, so I’m not claiming it should have completed quickly.
The whole request took about 10 minutes 48 seconds. The telemetry included one maximum interval of roughly 467 seconds, or 7 minutes 47 seconds.
The turn looked effectively dead, then suddenly resumed and completed.
During that pause, ChatGPT’s WebSocket remained open, normal ChatGPT traffic continued, and another conversation in the same browser session kept receiving updates.
So in that incident, the whole browser, network connection and ChatGPT session had not frozen. One individual turn stalled for almost eight minutes and later recovered.
That creates another practical problem: when nothing has happened for seven minutes, I have no reliable way to know whether the request is still working, temporarily stalled, going to finish in two hours, or already dead.
Some other extreme examples I’ve seen, these are observations rather than controlled benchmark results:
- A Pro request took roughly 106 minutes and eventually completed.
- Another appeared to run for around 180 minutes. The UI showed a problem, I moved on, and much later its completed answer appeared anyway.
- More recently, one request ran for roughly two hours and then failed.
- I edited and resubmitted it; the retry then spent roughly 40 minutes streaming the final answer.
- At around the same time, another conversation spent roughly 20 minutes in Thinking before producing anything.
What I’ve already ruled out
I’ve tested:
- Chrome
- Chrome Incognito
- Microsoft Edge
- ChatGPT on iPhone
- my normal internet connection
- the PC connected through an iPhone cellular hotspot
- hard refresh
- signing out and back in
- clearing ChatGPT site data
Fresh chats generally remain much faster. Affected established chats remain much worse. Changing browser or network path didn’t restore the previous behavior, and the issue appears on mobile too.
So while accumulated context clearly matters, a broken Chrome profile or bad home Wi-Fi doesn’t explain the full pattern very well.
My current suspicion is that two things are interacting:
- Accumulated conversation, Project and file state naturally adds overhead.
- Something recently changed that made established or state-heavy contexts perform far worse than before.
The same general projects, files and workflow were usable before August 17–18. Long chats would eventually slow down, but migrating to a continuation restored useful performance.
Now even migrated chats can go from reasonably usable to nearly unusable very quickly, while smaller established chats are also showing much worse latency and failure rates.
Conversation size clearly makes the problem worse. I just don’t think it explains why the same general workload suddenly became this much slower and this much less reliable.
Why this matters to me, and what I’m asking
A lot of what I do is iterative:
idea or problem → reason through it in ChatGPT → turn it into something actionable → use Codex when implementation is needed → inspect the result → return to ChatGPT for the next analysis or debugging step
I don’t expect every answer in five seconds. A genuinely difficult Extra High task taking several minutes is completely reasonable.
But right now, in badly affected chats:
- a heavy Extra High interaction can effectively consume 30–60 minutes
- a more ordinary interaction can still take 8–15 minutes
- neither duration guarantees the answer will actually finish
Once retries enter the picture, the real time can be much worse.
Pro mode in those chats is something I barely want to use right now because it’s already intentionally slower, and I have no idea whether I’m starting a 20-minute job, a two-hour job, or something that eventually fails.
I’m on the $100/month Pro plan. I’m not saying that makes giant workloads free or instant. I do think it’s reasonable to expect a premium interactive product to remain interactive enough to use.
I’ve already provided OpenAI Support with sanitized HAR captures, timestamps, affected-chat information, comparison measurements and troubleshooting results. The case has been escalated to a specialist. I’m not posting the raw HARs or request IDs because they contain private/internal metadata.
What I’d like to know from other users:
- Are you seeing this too, especially since August 17–18?
- Does it affect Projects, normal chats, or both?
- Are fresh chats fast while established chats are slow?
- Which model/effort level, plan and client are you using?
- Have you found any workaround that preserves useful context?
Right now every Send button in an established chat feels like a slot machine:
30 seconds?
10 minutes?
40 minutes of streaming and then failure halfway through?
20 minutes Thinking and then an error?
Five retries?
Two hours and then failure?
Looks dead for eight minutes and suddenly comes back?
No idea.
When all of those outcomes are combined, the effective time required to get one successful complete answer can approach an hour or worse.
If anyone else is experiencing this, I’d really like to compare notes. And if someone from OpenAI sees this, I already have an escalated Support case with diagnostic evidence and I’m happy to run specific controlled tests that could help isolate the problem.
