I am adding another structured update because the GPT-5.6 Sol problems affecting my workflow have now continued for approximately seven days, and today I encountered another serious failure mode.
I want to keep this post factual, respectful, and technically focused.
I am not claiming that every symptom below necessarily has the same root cause. Some may involve model routing, some execution/runtime behavior, some long-context or file retrieval, some streaming/session infrastructure, and some the ChatGPT web UI.
My purpose is to document the complete regression pattern as clearly as possible so the appropriate OpenAI teams can separate and investigate the remaining issues.
Current environment
- Plan: ChatGPT Pro
- Model: GPT-5.6 Sol
- Reasoning settings affected: High and Extra High
- Surface: ChatGPT web
- Device: Apple iPad
- Operating system: iPadOS 26.6.1 (23G83)
- Browser: Google Chrome for iPad
- Chrome version: 152.0.7977.64
- Workflow: large long-running creative-writing/project workflow
- Typical workload: very long governing prompts, uploaded predecessor text files, exact continuity recovery, source hierarchy rules, research, multi-step reasoning, and approximately 20,000 words of final prose
- Variants of these problems have occurred in new conversations, not only older long-running chats.
Before the recent regression period, this general workflow was substantially more reliable.
For approximately seven days, I have mostly been unable to use it normally.
NEW AUGUST 26 FAILURE — GPT-5.6 Extra High now sits at “Thinking” and does not appear to progress
This is the newest failure.
Today I attempted my workflow again in a completely new ChatGPT conversation.
I:
- created a fresh conversation;
- uploaded the required predecessor text file;
- supplied the governing prompt;
- selected GPT-5.6 Sol Extra High;
- submitted the task normally.
Instead of progressing through file reading, continuity analysis, web research, reasoning, and generation, ChatGPT simply remained at:
“Thinking”
It did not visibly progress into the task.
I recorded the occurrence because OpenAI Support specifically asked me this morning to provide a screen recording from prompt submission through the point where the failure occurs if I encountered the problem again during normal use.
I have now done that.
This is different from the earlier failure pattern.
Previously, one common problem was that High or Extra High would sometimes blaze through an extremely complex task far too quickly and then return an incomplete or broken response.
Now I am seeing the opposite:
Extra High can simply remain stuck at “Thinking” without visibly performing the requested work.
So during this seven-day regression period I have now experienced both extremes:
- reasoning that appears abnormally fast and incomplete;
- and reasoning that appears to stall before meaningful execution begins.
The Activity / Thinking sidebar is also inaccessible while this happens
The new stalled-Thinking behavior is made much harder to diagnose by another UI regression.
Previously, while ChatGPT was working, I could open the right-side Activity / Thinking sidebar.
That panel showed information such as:
- Thinking stages;
- web searches;
- file operations;
- Python/tool activity;
- continuity work;
- and other visible execution steps.
I have older screenshots showing this working normally.
Now, on Chrome web on my iPad, when GPT-5.6 sits at Thinking, I frequently cannot pull up that sidebar at all.
The interface simply shows:
Thinking
with no accessible Activity panel.
That means I cannot determine from the user interface whether ChatGPT is:
- parsing the prompt;
- reading the uploaded file;
- waiting for retrieval;
- waiting for an execution worker;
- performing hidden reasoning;
- retrying an operation;
- stalled in a queue;
- or failing internally before execution begins.
I would appreciate confirmation from OpenAI whether the missing Activity / Thinking panel is:
- an intentional UI change;
- an iPad/Chrome mobile-web bug;
- a Thinking-mode UI regression;
- or a symptom of the underlying execution process failing to create an Activity stream.
Full seven-day regression history
The newest stalled-Thinking failure is only the latest problem.
Below is the broader set of issues I have documented during the last seven days.
1. GPT-5.6 High / Extra High sometimes reasons far too quickly for complex tasks
Earlier in this regression period, very complex prompts that previously required substantial processing would sometimes complete extremely quickly.
The problem was not simply that the model was fast.
Those unusually fast runs frequently correlated with:
- instructions being missed;
- context being ignored;
- files supposedly being unavailable;
- continuity being lost;
- requested execution not happening;
- and simplified or broken final responses.
One particularly clear example involved a High request finishing in approximately 18 seconds and then incorrectly claiming that the required predecessor story file was unavailable.
2. OpenAI confirmed an unintended GPT-5.6 → GPT-5.5-mini routing regression
One issue users had been documenting has now received direct OpenAI acknowledgment.
OpenAI identified a regression that was causing approximately 3% of Pro and Thinking turns to unintentionally move to GPT-5.5-mini.
OpenAI stated that the regression had been fixed.
I appreciate that acknowledgment because it confirms that the routing discrepancy users were reporting was real.
However, I want to be precise here:
I am not claiming that today’s stalled-Thinking behavior proves the GPT-5.6 → GPT-5.5-mini routing fix itself failed.
What it does demonstrate is that the routing regression was not the only issue affecting the broader workflow.
Even after that fix was announced, the long-context, execution, file, UI, and Thinking problems have continued.
So the remaining regression cluster still needs investigation independently of the acknowledged mini-routing problem.
3. High / Extra High Thinking behavior remains inconsistent
Across these seven days I have now experienced:
- High/Extra High completing complex tasks far too quickly;
- High/Extra High producing degraded or incomplete results;
- High/Extra High switching into planning instead of execution;
- and now Extra High apparently remaining stuck at Thinking without progressing.
This makes the behavior unpredictable.
For a reasoning setting specifically intended for difficult tasks, consistency matters as much as raw speed.
4. Long prompts appear to be incompletely processed or applied
My prompts are intentionally detailed because the workflow requires strict continuity.
They can contain:
- source hierarchy;
- exact predecessor requirements;
- continuity locks;
- character states;
- location states;
- relationship states;
- research requirements;
- formatting requirements;
- explicit instructions about which files must be read;
- explicit instructions about what must not be invented;
- and requirements for the final output.
During this regression period, ChatGPT has sometimes appeared to understand those instructions initially and then behave as though portions of them were never supplied.
This can look like:
- instructions disappearing;
- current continuity being ignored;
- older information being substituted;
- the task being treated as a fresh standalone prompt;
- or ChatGPT explaining what it should do rather than executing the instructions.
5. Long-context continuity has become unreliable
This workflow depends on ChatGPT correctly carrying information across:
prompt → file retrieval → reasoning → research → execution → final generation
The failure does not always appear to happen at the same stage.
Sometimes the correct context is recognized during Thinking.
Then the final execution behaves as though that context has disappeared.
That suggests engineering should investigate not only initial context ingestion, but also whether context and tool state are being preserved across later stages of execution.
6. Uploaded files have been falsely reported as missing
This remains one of the most damaging problems.
I have had ChatGPT tell me that a required predecessor file was unavailable and that I needed to upload it again.
However, the supposedly missing source was later successfully accessed.
That means the statement:
“The file is missing.”
has not always reflected the actual state of the conversation.
This creates a serious reliability problem because the user cannot know whether:
- the file is genuinely missing;
- retrieval temporarily failed;
- the model lost the retrieval state;
- context ingestion failed;
- or ChatGPT simply generated an incorrect missing-file claim.
7. The same file can be available in one execution and unavailable in another
I have seen contradictory behavior where:
- a file is successfully located;
- the file is opened;
- its contents are read;
- its length is verified;
- the correct story continuity is recovered;
and then another attempt claims that the same required material is unavailable.
This suggests the problem may involve more than initial upload availability.
Please investigate the propagation of file state through:
retrieval → reasoning → execution → final generation
8. Successful file retrieval does not always survive into final execution
In some runs, the Thinking/Activity process clearly showed that ChatGPT had already accessed the appropriate file.
It could even describe the file correctly.
Yet the later response behaved inconsistently with that successful retrieval.
That raises the possibility of state loss between internal stages.
9. Verification / planning responses have replaced the requested output
One of the clearest failures happened during a requested 20,000-word story continuation.
GPT-5.6 worked for approximately:
25 minutes and 54 seconds
During that run it correctly:
- recovered the controlling sources;
- identified the correct predecessor continuity;
- performed research;
- analyzed the continuation;
- and apparently constructed the requested story.
The final response then claimed:
- a complete prose draft had been constructed;
- it was exactly 20,000 words;
- it contained approximately 694 paragraphs;
- paragraph-length analysis had been performed;
- duplicate checks had been performed;
- and additional verification had taken place.
But the requested story itself was never delivered.
Instead, I received a verification report describing the supposed result.
That is not the requested output.
The verification process should support execution.
It should not replace execution.
10. Planning/explanation mode sometimes replaces execution
The same broader issue appears in less extreme forms.
Instead of performing the requested task, ChatGPT may:
- restate the assignment;
- explain what it intends to do;
- explain what sources it needs;
- describe what the final result should contain;
- provide a verification report;
- or say that work has been completed;
without actually producing the requested result.
This is particularly disruptive for complex workflows because substantial time can be spent processing before the user discovers that the execution itself never happened.
11. Long-running tasks appear to terminate before the work is complete
The 25m54s failure raises a separate runtime question.
A difficult request can:
- begin normally;
- read files;
- research;
- analyze;
- plan;
- verify;
- process for approximately 25–26 minutes;
and then terminate without producing the required final output.
Other Community users have also been investigating similar long-running behavior.
This deserves separate examination even when the request is genuinely running GPT-5.6.
Potential areas worth examining include:
- foreground execution;
- worker assignment;
- worker handoff;
- orchestration;
- execution ceilings;
- task cancellation;
- final-generation handoff;
- and long-running Chat versus Work execution paths.
I cannot determine the internal cause from outside OpenAI.
I am only reporting the observable behavior.
12. “Connection interrupted. Waiting for the complete answer”
I have repeatedly encountered:
“Connection interrupted. Waiting for the complete answer”
during active processing.
These failures have occurred after work had already begun.
In at least one case:
- the uploaded file had already been successfully opened;
- the file had already been inspected;
- processing was underway;
- and then the response stream interrupted.
This raises questions about whether:
- server-side work survives a stream interruption;
- file/context state survives reconnect;
- execution continues after the client temporarily loses the stream;
- and the final result can still be delivered correctly.
13. Response-stream failures can happen after substantial work has already occurred
This is especially frustrating because the user may wait while ChatGPT performs significant processing and then lose the result near the end.
That is very different from a request simply failing immediately.
14. Context can be recovered correctly during Thinking and then lost before final generation
I have also observed cases where the intermediate reasoning correctly identifies:
- the source material;
- current continuity;
- locations;
- characters;
- rules;
- and what the requested continuation should accomplish;
but the final result either:
- does not happen;
- contradicts that reasoning;
- claims required information is unavailable;
- or produces a meta/verification response instead.
Again, the important engineering question may be state continuity between internal phases.
15. Existing long-running workflows can suddenly be treated like unrelated new prompts
Another regression is that established workflows can suddenly behave as though they have no prior structure.
Examples include:
- asking for material that is already supplied;
- explaining already-established instructions;
- ignoring current source hierarchy;
- relying on incomplete continuity;
- or behaving like a generic assistant rather than continuing the established workflow.
16. Conversation / Project reliability has become inconsistent
The problems have affected more than one conversation.
I have seen:
- long-chat reliability problems;
- inconsistent application of Project instructions;
- conversation-state loss;
- context suddenly appearing unavailable;
- and behavior changing between executions.
The fact that today’s new stuck-at-Thinking failure occurred in a brand-new conversation is important.
This is not solely an old-chat context-window issue.
17. Right-side Activity / Thinking UI regression
As described at the beginning of this update, the live Activity/Thinking sidebar is no longer reliably accessible on my current Chrome/iPad environment.
This is a new regression compared with how the interface worked previously.
18. Right-side conversation / prompt navigation has also regressed
Separate from the live Activity panel, there have also been problems involving the right-side navigation used in long conversations.
Observed behavior has included:
- conversation/prompt navigation disappearing;
- older messages loading only progressively;
- navigation controls becoming inaccessible;
- and long conversations becoming much harder to navigate than before.
Other users have reported similar UI behavior.
19. Older-message/history loading behavior changed
Long chats now behave differently when attempting to access older material.
I understand that front-end loading behavior may be separate from what context is actually provided to the model.
I am therefore not claiming that progressive UI loading proves the model is only receiving part of the conversation.
I am reporting it as a separate UI/history regression occurring during the same general period.
20. Memory / state reliability has also been inconsistent
There have also been problems during this broader period involving Memory or longer-term state not always updating or behaving consistently.
This may be a separate subsystem, but I am including it for completeness because reliable long-running workflows depend on stable state across multiple layers of ChatGPT.
21. Large pasted prompts / composer integrity has been another concern
There have also been earlier problems involving large pasted prompts and the paste-to-attachment / “Show in text field” behavior.
For a workflow that depends on large exact prompts, any input-layer corruption can compound downstream context failures.
Issues worth monitoring include:
- missing sections;
- altered sections;
- merged formatting;
- fragmented text;
- and whether the exact prompt submitted is the exact prompt received by the model-serving pipeline.
Timeline
The severe behavior became especially noticeable around the August 19–20 service problems.
OpenAI’s own status history included:
- ChatGPT availability/login problems;
- an officially acknowledged Thinking-mode elevated-error incident on August 20;
- subsequent web-session/logout problems;
- and other service instability during the broader period.
The official Thinking incident was marked resolved.
However, the wider combination of:
- long-context problems;
- false missing-file claims;
- verification replacing execution;
- execution/runtime failures;
- connection interruptions;
- abnormal High/Extra High behavior;
- UI regressions;
- and now Extra High becoming stuck at Thinking
has continued beyond that incident.
Support is now reviewing screen-recorded evidence
I have contacted OpenAI Support repeatedly and supplied extensive screenshots and technical information.
My current technical case is:
Case #13727694
There are also related technical cases containing earlier evidence.
This morning, Support acknowledged that I had already spent substantial time troubleshooting and explicitly said they would not ask me to repeat the basic troubleshooting I had already completed.
They asked that if the issue happened again during normal use, I provide a screen recording from the moment I submit the prompt through the point where the problem occurs.
Today’s stuck-at-Thinking failure happened naturally while I was attempting to use ChatGPT again.
I screen-recorded it and sent the evidence to Support.
So OpenAI now has:
- earlier screenshots;
- file-access contradictions;
- long-context examples;
- the 18-second false missing-file example;
- the 25m54s verification-without-output example;
- connection interruption examples;
- UI/sidebar examples;
- and now a screen recording of a fresh GPT-5.6 Extra High request that appears to stall at Thinking.
What appears to have changed over seven days
The regression has not remained static.
The failure pattern has evolved.
Earlier:
High/Extra High could blaze through a complex task far too quickly and return a broken or incomplete result.
Then:
Files could be falsely reported missing, context could disappear, or execution could be replaced by verification/planning.
Then:
Long-running tasks could process extensively and still fail to deliver the requested output.
Alongside that:
Connection interruptions and UI/navigation regressions appeared.
Now:
A fresh Extra High request can apparently stall at “Thinking” and fail to visibly enter meaningful execution at all.
That progression is why I am continuing to report the issue.
What I am NOT claiming
For clarity:
I am not claiming every issue above has one single cause.
I am not claiming the new stalled-Thinking failure proves that the previously acknowledged 5.6 → 5.5-mini routing fix itself failed.
I am not claiming that progressive conversation-history loading proves the model receives incomplete context.
I am not claiming to know OpenAI’s internal architecture or exact root cause.
Those are engineering questions.
What I can document is the observable behavior.
What I hope OpenAI investigates next
I would appreciate the appropriate teams examining the remaining problems across these areas:
GPT-5.6 reasoning
- High/Extra High consistency
- abnormally fast reasoning
- stalled Thinking
- genuine GPT-5.6 execution reliability
Routing
- post-fix routing stability
- selected/requested versus resolved model
- unexpected fallback
- whether the August 25 fix has fully propagated
Long context
- prompt ingestion
- compaction
- context prioritization
- instruction retention
- state continuity between reasoning and final generation
Files
- false missing-file claims
- contradictory retrieval
- successful retrieval followed by state loss
- file state surviving later execution stages
Execution/runtime
- worker assignment
- worker handoff
- long-running execution ceilings
- ~25–26 minute unfinished-task behavior
- planning/verification replacing execution
- final-generation handoff
Streaming/session reliability
- “Connection interrupted”
- reconnect behavior
- stream termination
- preservation of server-side work after client interruptions
ChatGPT UI
- missing Activity / Thinking sidebar
- missing conversation/prompt navigator
- progressive older-message loading
- missing navigation/version controls
- iPad Chrome mobile-web behavior
Composer / Memory / Projects
- large-prompt text integrity
- persistent state
- Project instruction reliability
- memory/state consistency
Why this matters
I am a ChatGPT Pro subscriber, and I use Pro specifically because my workflow requires difficult long-context reasoning and long-running execution.
For approximately seven days, I have been unable to rely on ChatGPT for that workflow.
At this point the problem is no longer simply:
“The response quality seems worse.”
I have documented concrete failures involving:
- routing;
- Thinking behavior;
- long context;
- file retrieval;
- execution;
- final-output delivery;
- connection stability;
- Project/conversation state;
- and the user interface.
And today’s new failure is even more basic:
GPT-5.6 Extra High can now simply sit at “Thinking” without visibly doing the task.
I hope the routing regression acknowledgment was the beginning of a broader investigation rather than the end of it.
I appreciate the OpenAI staff and Support representatives who have started taking the technical evidence seriously.
I am continuing to provide this information because I would like to see GPT-5.6 return to the reliable complex-work behavior it had before this regression period.
If other users are currently seeing GPT-5.6 High or Extra High stuck indefinitely at “Thinking,” especially in fresh conversations, it would be useful if they could add their environment and reproduction details here so OpenAI can determine how widespread this newest failure mode is.
