I want to raise this respectfully because I want OpenAI and ChatGPT to succeed, and because I believe this deserves engineering attention before Astra is broadly released.
I am a ChatGPT Pro subscriber, and I renewed my Pro membership on September 3 even after spending roughly the last two weeks dealing with serious reliability problems.
I still believe OpenAI can fix these issues.
I want Astra to be great.
But I think there is an important point that needs to be said clearly:
It does not matter how capable the next model is if users cannot reliably use those capabilities in the actual ChatGPT product.
A model can have extraordinary benchmark performance, reasoning ability, long-horizon capability, coding ability, creative ability, or intelligence, but those capabilities become much less useful if the surrounding product cannot reliably ingest the user’s context, retrieve their files, preserve state, reason for the selected amount of time, execute the requested task, stream the result, and actually deliver the final answer.
That is the concern behind this post.
I am not claiming to know what is happening inside OpenAI’s backend.
I cannot see OpenAI’s routing systems, context-management systems, worker infrastructure, file-retrieval pipeline, reasoning-budget allocation, safety/classifier pipeline, session infrastructure, or generation systems.
What I can document is what has changed from the user side.
For me, this became consistently serious around August 19–20, 2026.
Before that period, my normal GPT-5.6 Sol workflow was substantially more reliable.
My workflow is demanding, but it is not new.
I use ChatGPT Pro for complex long-form creative writing and world-building involving:
- very large governing prompts and detailed instructions;
- long-running conversations;
- multiple uploaded text files;
- exact predecessor-file retrieval;
- source hierarchies;
- continuity tracking;
- character and world-state tracking;
- research;
- High and Extra High reasoning;
- multi-stage analysis and execution;
- and long-form outputs that can reach approximately 20,000 words.
GPT-5.6 Sol handled this type of workflow much more reliably before the recent regression period.
For roughly the past two weeks, however, I have experienced a cluster of failures that has made this kind of work extremely difficult to trust.
My current environment is:
Subscription: ChatGPT Pro
Device: Apple iPad
Operating system: iPadOS 26.6.1 (23G83)
Browser: Chrome for iOS
Current Chrome version: 153.0.8010.24
Primary model: GPT-5.6 Sol
Reasoning levels affected: High and Extra High
I have also tested different combinations of:
- ordinary Chat;
- Projects;
- ChatGPT Work;
- the ChatGPT application;
- Chrome;
- Safari;
- fresh conversations;
- existing conversations;
- High;
- and Extra High.
Different manifestations have appeared across those surfaces, so I do not believe this can be reduced to one bad browser tab or one corrupted conversation.
1. High and Extra High sometimes race through complex tasks
One of the earliest changes I noticed was that difficult requests that previously required substantial reasoning began sometimes returning unusually quickly.
The issue is not simply that GPT-5.6 became faster.
The unusually fast responses often correlate with worse execution.
I have seen them:
- ignore important instructions;
- use only part of the available context;
- miss continuity requirements;
- skip expected file work;
- give short or generic responses;
- incorrectly claim required information is unavailable;
- and fail to perform the actual requested task.
High or Extra High can still be visibly selected in the UI, yet some affected runs do not resemble the sustained reasoning behavior I was previously receiving.
There is now a separate Developer Community thread describing essentially the same symptom:
“GPT-5.6 Sol High Reasoning Appears Broken — Instant Replies, No Deep Thinking, File Workflows Failing”
That report comes from a software-development workflow rather than my creative-writing workflow, which is important.
The other user describes GPT-5.6 Sol High replying almost instantly, failing to properly analyze uploaded files, failing long-context work, stopping before multi-step execution, and giving short generic answers.
That does not prove both users have the same backend problem.
But it does show that this type of behavior is not limited to one creative-writing project.
2. Long prompts sometimes behave as though they were truncated or incompletely ingested
My prompts can be very large because they govern complicated long-running projects.
During the recent regression, information that is visibly present in the submitted prompt may later behave as though it was never received.
The model can sometimes correctly acknowledge a rule during Thinking and then ignore or contradict that same rule during execution.
From the user side, it becomes impossible to know whether the entire prompt was:
- received;
- ingested;
- retained;
- prioritized;
- propagated through the reasoning process;
- or made available to final generation.
This creates a serious trust problem for any complex workflow.
3. Long-context continuity has become unreliable
I have also experienced established instructions and project state disappearing or being replaced by older information.
Examples include:
- current continuity being replaced with obsolete continuity;
- source hierarchies being ignored;
- an established workflow suddenly being treated like a brand-new request;
- previously active rules disappearing;
- information clearly understood during Thinking not reaching final generation;
- and conversation or Project state behaving inconsistently.
For continuity-sensitive work, this can make the model functionally unusable even if its raw intelligence remains excellent.
4. Uploaded files can be falsely reported as missing
This has been one of the clearest failures I have documented.
I have had an uploaded predecessor story file visibly present in the conversation, yet GPT-5.6 responded that the required source was unavailable and told me to upload it.
In one especially clear example, GPT-5.6 High worked for approximately 18 seconds before telling me that the required predecessor story was unavailable.
The problem was that the predecessor had already been uploaded.
In another attempt, ChatGPT was able to directly open that exact file and read it successfully.
The file itself contained the complete source.
So the issue was not simply that I forgot to upload it.
5. File availability and execution state can contradict each other
This is even stranger.
I have seen ChatGPT successfully:
locate a file → open it → read it → verify it → recover the correct continuity
and later behave as though the same source is unavailable.
That makes me wonder whether the problem is not only initial file retrieval.
Engineering may need to inspect the full chain:
prompt ingestion → retrieval → reasoning → state preservation → execution → final generation → streaming → delivery
A source can apparently be available at one stage and fail to influence a later stage.
I do not know why.
That is exactly why this needs engineering investigation rather than users guessing about the backend.
6. Planning and verification sometimes replace actual execution
This has been one of the most disruptive symptoms.
I requested a complete approximately 20,000-word story continuation.
GPT-5.6 worked for approximately:
25 minutes and 54 seconds.
During the run it appeared to:
- retrieve the required files;
- recover the correct predecessor seam;
- perform web research;
- analyze continuity;
- construct the continuation;
- count the words;
- analyze paragraph structure;
- perform repetition checks;
- and perform additional verification.
The final response then told me:
“A complete prose draft was constructed…”
It said the supposed draft contained:
exactly 20,000 words
and approximately:
694 paragraphs
and then discussed verification details.
But the actual story was never delivered.
Instead of the requested output, I received a report describing the supposedly completed output.
That is not a subjective complaint about writing quality.
It is an execution failure.
If a system spends almost 26 minutes constructing an answer but the answer never reaches the user, then the task has not successfully completed.
7. Long tasks have appeared to encounter an approximately 25–26-minute failure boundary
Because of the example above and other behavior I have observed, I think engineering should examine whether long-running ChatGPT tasks are encountering some kind of execution or final-delivery problem.
Possible areas worth investigating could include:
- runtime limits;
- worker assignment;
- worker handoff;
- foreground/background execution;
- orchestration;
- cancellation;
- reasoning budgets;
- queue state;
- and final-generation delivery.
I want to emphasize again that I am not claiming one of these is definitely the cause.
Those are engineering questions.
From outside OpenAI, users cannot inspect those systems.
8. Connection interruptions occur after substantial processing
I have repeatedly received:
“Connection interrupted. Waiting for the complete answer.”
In some cases this happened after file retrieval, tool execution, or reasoning activity was already visible.
That raises an important engineering question:
When a response stream disconnects, does the backend preserve the successfully recovered:
- file state;
- conversation state;
- reasoning state;
- tool results;
- generated output;
- and task state?
Or can some of that work be lost during reconnect or final delivery?
Again, users cannot inspect this.
9. GPT-5.6 routing already had a confirmed OpenAI-side regression
During this broader period, users documented situations where GPT-5.6 was selected while request-level metadata indicated GPT-5.5-mini.
OpenAI subsequently acknowledged that some Pro and Thinking requests were unintentionally moved to GPT-5.5-mini and said a fix had been deployed.
I mention this for an important reason.
It demonstrates why unusual GPT-5.6 behavior should not automatically be dismissed as:
- user error;
- prompt design;
- browser problems;
- an old conversation;
- or account-specific behavior.
At least one strange behavior during this period turned out to have an actual OpenAI-side technical explanation.
That does not mean every problem listed here is caused by routing.
It means further investigation is warranted.
10. Extra High can also freeze completely at “Thinking”
The failure has sometimes gone from one extreme to the other.
Instead of reasoning unusually quickly, Extra High can remain indefinitely at:
“Thinking”
with no meaningful visible progress.
No visible research.
No visible file access.
No visible tools.
No answer.
That is the opposite of the instant-response problem, but both prevent complex work from being completed reliably.
11. Frozen conversations can become questionable after reload
In at least one test, a long complex request froze during Thinking.
After reloading, the conversation was no longer where I expected it to be.
That raises another question about whether conversation and submitted-request state are reliably persisted before and during long-running execution.
12. The Activity / Thinking sidebar can become inaccessible during failures
Normally the Activity panel is very useful.
It can show:
- searches;
- uploaded-file operations;
- Python/tool activity;
- reasoning stages;
- and execution progress.
During some frozen-Thinking failures, I have been unable to open that panel.
That means the user cannot even tell whether the request is:
- queued;
- reasoning;
- waiting for a worker;
- retrieving files;
- retrying;
- stalled;
- or failing.
For debugging and user confidence, that UI is important.
13. Conversation history and navigation have also behaved inconsistently
During the same broader instability period I have seen:
- missing or inaccessible right-side navigation;
- missing prior-prompt/version navigation;
- changes in how older messages load;
- controls disappearing;
- and long-conversation history behaving inconsistently.
Those may be separate UI issues.
I am not assuming all of these failures share one root cause.
14. Project and conversation state have become inconsistent
Previously established Project instructions or conversation context have not always propagated reliably.
This matters because complex workflows depend on ChatGPT preserving the state users have already established rather than requiring them to rebuild that state every turn.
15. Memory and large-prompt/composer reliability have also been problematic
During the broader instability period, I have also experienced:
- Memory not appearing to save or update reliably;
- and large-prompt/composer behavior becoming inconsistent.
Again, I think OpenAI should keep these as separate technical categories unless engineering determines that they are connected.
16. Generic “Something went wrong” execution failures have also appeared
I have also reproduced requests that simply return:
“Hmm… something seems to have gone wrong. Retry.”
That adds another failure mode on top of:
- fast/shallow reasoning;
- frozen reasoning;
- context loss;
- file-state problems;
- execution failures;
- and streaming problems.
17. These problems have reproduced across multiple surfaces
During this regression period I have tested combinations of:
- ordinary Chat;
- Projects;
- ChatGPT Work;
- the ChatGPT application;
- Chrome;
- Safari;
- fresh conversations;
- existing conversations;
- High;
- and Extra High.
Different manifestations have appeared across different surfaces.
My primary workflow is still ordinary ChatGPT Chat.
That distinction matters.
If OpenAI fixes a problem specific to Work or Workspace Agents, that does not automatically establish that ordinary Chat has recovered.
Other Developer Community users are reporting overlapping symptoms
Another relevant thread is:
“Why is GPT-5.6 failing long-context tasks?”
That discussion includes reports involving combinations of:
- long-context degradation;
- file/context problems;
- High/Extra High reasoning changes;
- unusually fast reasoning;
- verification/planning replacing execution;
- connection problems;
- and continuity/instruction-following regressions.
I want to be careful with how I characterize community evidence.
Community reports are not proof of a specific root cause.
Multiple users may experience superficially similar problems for different reasons.
But multiple independent reports are still useful signals that engineering can investigate.
OpenAI’s own status history also shows that real incidents have occurred during this period
OpenAI’s status history has documented incidents affecting ChatGPT and Thinking during the broader period in which users have been reporting these problems.
There was also another official “Elevated errors across ChatGPT and Codex” incident on September 3.
I am not claiming that one status incident explains this entire two-week regression.
It probably does not.
But it reinforces an important point:
A green status page at one particular moment is not proof that every model, tier, reasoning mode, file workflow, or long-context workflow is operating normally.
OpenAI’s own status page says its availability metrics are aggregate and that individual availability can vary depending on subscription tier, model, and specific features.
That is especially relevant when the reports concern a particular combination like:
ChatGPT Pro + GPT-5.6 Sol + High/Extra High + large context + files + long-running execution.
I have already done extensive client-side troubleshooting
I have spent roughly two weeks trying to eliminate ordinary client-side causes.
I have:
- restarted sessions;
- tried fresh conversations;
- tried existing conversations;
- tested High;
- tested Extra High;
- tested ordinary Chat;
- tested Projects;
- tested Work;
- tested the ChatGPT application;
- tested Chrome;
- tested Safari;
- uninstalled and reinstalled Chrome;
- re-uploaded files;
- supplied screenshots;
- supplied screen recordings;
- recorded timestamps;
- documented browser and OS versions;
- and repeatedly reproduced different failure modes.
At some point, if the issue involves routing, context reconstruction, file state, worker orchestration, model serving, streaming, or another backend subsystem, the user cannot repair it by clearing a browser cache again.
Users cannot:
- restart a model-serving cluster;
- inspect a routing decision;
- restore dropped context;
- reset server-side state;
- change a worker assignment;
- fix file retrieval;
- repair streaming infrastructure;
- or inspect reasoning-budget allocation.
That requires OpenAI.
Why this matters more with Astra approaching
OpenAI published “Path to Astra: critical capabilities and frontier safeguards” on September 1.
OpenAI says Astra will be made available soon.
Axios has also reported on Astra’s upcoming release and the fact that OpenAI considers it the first model to reach its Critical cybersecurity capability threshold.
https://www.axios.com/2026/09/01/openai-astras-cyber-critical
This obviously represents a major technical achievement.
I am excited to see what Astra can do.
But I strongly hope OpenAI does not treat model capability and product reliability as separate priorities.
Astra could be the most intelligent model OpenAI has ever released.
But for ordinary paying users, its practical value still depends on whether ChatGPT can reliably:
- receive the prompt;
- preserve the context;
- retrieve the files;
- retain the retrieved information;
- perform the selected reasoning;
- execute the task;
- remain connected;
- preserve the conversation;
- and deliver the final result.
If those layers are unreliable, extraordinary model intelligence cannot fully reach the customer.
Capability and reliability have to exist together.
I renewed ChatGPT Pro because I still believe OpenAI can fix this
After roughly two weeks of not being able to rely on ChatGPT for my primary workflow, I still renewed Pro.
I am still willing to pay approximately $100 per month because I want access to OpenAI’s strongest models and I believe the product can be excellent.
But instead of using that subscription for my projects, I have spent much of the last two weeks:
- reproducing failures;
- collecting screenshots;
- recording failed sessions;
- documenting timestamps;
- comparing browsers;
- testing ChatGPT surfaces;
- checking file state;
- talking to Support;
- posting Developer Community reports;
- and trying to determine when the platform is reliable enough to resume my work.
I do not think this is the experience OpenAI wants paying users to have.
Astra and future models should also treat adult users like adults
There is another issue I hope OpenAI continues addressing as Astra approaches.
OpenAI has itself used the principle that age-aware protections can help the company:
“treat adults like adults”
while still providing additional protections for teens.
I strongly support that principle.
I am an adult user.
I am not asking OpenAI to remove safety safeguards.
I am not asking OpenAI to remove protections involving minors, exploitation, genuinely dangerous real-world activity, or other areas where strong boundaries are necessary.
I am asking for:
proportionality, contextual understanding, consistency, and fair treatment of adult users.
My primary ChatGPT use is complex creative writing and world-building.
Fiction can contain the same themes that appear throughout literature, film, television, games, comics, and other media:
- dark themes;
- fantasy;
- realism;
- warfare;
- violence;
- blood;
- trauma;
- political consequences;
- morally complicated situations;
- action;
- romance;
- relationships;
- and intense sexual intimacy between fictional consenting adults, including ordinary anatomical terminology when appropriate to the writing.
The existence of those themes does not automatically make a piece of fiction harmful.
A story containing war does not mean its author supports war.
A story containing violence does not mean its author advocates violence.
A political plot does not automatically imply political wrongdoing.
Fantasy blended with realism is still fiction.
And mature intimacy between fictional consenting adults should be evaluated in context rather than automatically treated as malicious simply because mature subject matter or anatomical terminology appears.
The inconsistency is what causes the most frustration.
Sometimes ChatGPT correctly understands the literary context.
Other times a similar request can be heavily sanitized, moralized about, or broadly refused.
For adult creative work, that unpredictability is disruptive.
Again, my argument is not “remove safety.”
My argument is:
apply safety intelligently and contextually, while treating adults as adults within legitimate boundaries.
Where one narrow element of a larger request is genuinely outside a permitted boundary, I also think the better behavior is to make the smallest necessary adjustment rather than unnecessarily suppressing the rest of a legitimate creative request.
Art and storytelling have always explored difficult subjects:
violence, love, sex, war, tragedy, politics, trauma, death, morality, intimacy, fear, fantasy, conflict, and human relationships.
A capable creative model should be able to distinguish depicting a mature theme in fiction from endorsing real-world harm.
Reliability and adult-user treatment both matter competitively
Users are naturally comparing frontier models.
I have also been watching discussion around competing systems such as Fable 5.1, including third-party user-review roundups discussing long-horizon reasoning and complex-task performance.
I do not consider third-party reviews definitive benchmarks.
That is not my point.
The point is that users compare the complete experience.
They compare:
- reasoning quality;
- long-context reliability;
- file handling;
- successful task completion;
- creative flexibility;
- consistency;
- latency;
- and how often the model becomes an obstacle to legitimate work.
I want OpenAI and Astra to be the best option.
But an extraordinarily intelligent model can still feel less capable in practice if:
- the product cannot reliably deliver its output;
- long context disappears;
- files fail;
- reasoning stops prematurely;
- long tasks do not complete;
- or legitimate adult creativity repeatedly triggers unnecessary friction.
Safety and capability should not have to be opposites.
Neither should intelligence and reliability.
This also feels familiar from the period before GPT-5.6
I want to mention this carefully because I do not want to turn a user observation into a conspiracy claim.
Before GPT-5.6 Sol was released, I personally experienced a period where GPT-5.5 and ChatGPT became substantially less reliable.
Then GPT-5.6 arrived.
The current two-week period feels familiar to me as a user.
I am not claiming this proves a deliberate cycle.
I am not claiming I know that Astra preparation is causing the current regressions.
I have no evidence that lets me make that claim.
I am simply saying that, because Astra is now approaching, I hope OpenAI will make sure the existing ChatGPT platform is stabilized instead of allowing current users to experience weeks of degradation while the next model is being prepared.
Please fix the current product as well as preparing the next one.
What I hope OpenAI will acknowledge
I am not asking OpenAI to immediately disclose proprietary infrastructure details or provide a speculative root cause.
What I think paying users reasonably need is acknowledgment and clarity.
I would like OpenAI to clarify whether engineering is actively investigating the broader cluster involving:
-
GPT-5.6 Sol High/Extra High reasoning sometimes becoming abnormally fast or shallow.
-
Extra High sometimes freezing indefinitely at Thinking.
-
Long prompts apparently being incompletely ingested or applied.
-
Long-context instructions and continuity failing to propagate reliably.
-
Uploaded files being falsely reported as missing.
-
Successful file retrieval followed by apparent state loss later in execution.
-
Planning/verification responses replacing the requested final output.
-
Long-running tasks failing to complete or deliver after approximately 25–26 minutes.
-
Connection interruptions after substantial processing.
-
Conversation/request persistence problems after reload.
-
Activity/Thinking sidebar failures.
-
Conversation history/navigation regressions.
-
Project and ordinary-Chat state inconsistencies.
-
Memory reliability problems.
-
Large-prompt/composer integrity problems.
-
Generic “Something went wrong” execution failures.
-
Whether any routing regressions remain after the previously acknowledged GPT-5.6 → GPT-5.5-mini problem was addressed.
-
Whether ordinary Chat is being investigated separately from Work-specific incidents and fixes.
I am not saying these must all have one root cause.
They may represent several different regressions.
That is precisely why I think they should not be collapsed into one generic “try another browser” explanation.
What I hope OpenAI prioritizes before Astra’s broader release
I would strongly encourage OpenAI to test Astra and the ChatGPT serving stack not only for headline benchmark performance but for real demanding user workflows involving:
- huge prompts;
- long-running context;
- multiple uploaded files;
- state propagation between tools and final generation;
- long reasoning runs;
- High/Extra High behavior;
- sustained execution;
- conversation persistence;
- streaming stability;
- final-output delivery;
- Projects;
- ordinary Chat;
- mobile/web parity;
- Memory;
- composer integrity;
- UI state;
- and mature adult creative-writing consistency.
A model is not only its weights.
For users, the product is the entire pipeline.
Prompt → context → files → retrieval → reasoning → tools → execution → streaming → final answer.
Every link in that chain matters.
My request is constructive
I am writing this because I want the product to improve.
I renewed Pro because I still believe it will.
I want Astra to launch successfully.
I want GPT-5.6 to remain reliable while that happens.
I want Plus and Pro customers to be able to use the capabilities they are paying for.
And I want adult users doing legitimate creative work to be treated like adults while OpenAI continues maintaining necessary safety boundaries.
What I am asking for is:
reliability, acknowledgment, proportionality, contextual understanding, consistency, transparency, and fair treatment of paying users.
If OpenAI staff are reading the Developer Community, I would appreciate any acknowledgment that the broader GPT-5.6 / long-context / file / Thinking / execution / streaming / UI regression cluster is being investigated.
Even a response such as:
“We are aware of these reports and engineering is investigating them”
would give users much more confidence than continued uncertainty.
And if OpenAI has already identified or fixed parts of this cluster, I hope the company can communicate which categories are covered so users know what is genuinely safe to test again.
I do not expect every difficult engineering problem to be solved overnight.
I do hope the existing product can be stabilized before the next major model becomes the focus.
Astra may be extremely capable.
I sincerely hope it is.
But those capabilities will matter most if the ChatGPT platform underneath them is reliable enough for users to actually benefit from them.
Thank you to anyone from OpenAI who reads this, and to other users providing reproducible technical information rather than speculation.
Relevant references:
OpenAI Developer Community — “Why is GPT-5.6 failing long-context tasks?”
OpenAI Developer Community — “GPT-5.6 Sol High Reasoning Appears Broken — Instant Replies, No Deep Thinking, File Workflows Failing”
OpenAI — “Path to Astra: critical capabilities and frontier safeguards”
Axios — reporting on Astra and its Critical cybersecurity capability designation
https://www.axios.com/2026/09/01/openai-astras-cyber-critical
OpenAI — “Our approach to age prediction,” including the principle of treating adults like adults within safety boundaries
OpenAI Status
well at least its thinking I can’t say the same for 5.6
5.6 was pretty good too astra not even available in regular chat yet so I’m testing it in work but honestly I don’t know how I feel about astra