Why is GPT-5.6 failing long-context tasks?

Like you, I’m also a long-form novelist who relies on GPT to create alongside me. Compared with Claude and Gemini, GPT’s ability to write and understand long Chinese novels is far ahead of the other models. That is why it has always been the core of my workflow.

But since August 20, everything has changed. And there has been no official announcement or explanation, no plan, nothing. They are simply pretending nothing is happening.

I don’t know what they are trying to do.

Also, many replies keep saying things like: “Model outputs are inherently unstable,” “If you ask the model what it is, it may answer incorrectly,” or “Your data center IP might have triggered risk control and caused you to be routed to a lower-quality model.”

Seriously, that’s just nonsense.

The difference between GPT-5.6 Sol High performing normally and GPT-5.5-mini is enormous. Do they really think heavy users cannot tell the difference? Are they treating everyone like idiots?

Of course everyone knows that models may not accurately know their own model identity. That is not the point.

The point is:

If the endpoint response says it is GPT-5.5-mini, the thinking speed looks like GPT-5.5-mini, and the answer quality is also GPT-5.5-mini, then obviously whatever is responding inside that black box is GPT-5.5-mini.

Don’t tell me that the GPT-5.6 Sol they spent tens of billions, maybe even hundreds of billions, training is actually at this level. Would OpenAI dare to claim the benchmark results they published were produced by this version of GPT-5.6?

That would be ridiculous.

And then there are people talking about IP risk control.

Seriously?

Would users who actually violated rules or have something to hide come to this forum and complain?

If this really is caused by risk control, then we did nothing wrong, yet because of OpenAI’s flawed risk system we were placed into the wrong group, received inferior treatment, and were never moved back for such a long time. Is that reasonable?

By the way, what genre do you write, OP? I write romance novels.

“that distinction matters”

Caught mate :laughing:

HI,My environment / reproduction details:

  • Subscription tier: ChatGPT Plus
  • Model: GPT-5.6 Sol
  • Thinking level: High / Extra High (the issue appears especially noticeable when using higher thinking modes)
  • Operating system: Windows 11
  • Browser/App: Microsoft Edge (latest stable version)
  • Chat type: New chats and existing long-running project chats both affected
  • Project type: Long-form writing / worldbuilding project with multiple uploaded reference files
  • Approximate start date: Around August 19–20, 2026, after the reported GPT-5.6 Thinking issues

Symptoms I am experiencing:

  • Uploaded files sometimes appear to be ignored or incorrectly treated as unavailable.
  • Long instructions appear to be partially ignored or not fully applied.
  • Instead of executing the requested task, the model sometimes produces planning/verification-style responses explaining what it intends to do.
  • Complex tasks that previously required longer processing now complete suspiciously quickly and produce shallow results.
  • Long-context consistency appears reduced, especially when maintaining large projects across multiple documents.
  • The model may acknowledge instructions but fail to carry out the actual requested operation.
  • File-based workflows that previously worked reliably are now much less dependable.

My main use case is a long-term creative writing project with many interconnected Markdown documents, character bibles, worldbuilding files, and timeline documents. Before this issue, GPT-5.6 was able to reliably help merge and update large structured documents. Recently, the workflow has become much less reliable.

I understand that service status pages may show everything operational, but from a user perspective the issue does not look like a normal outage. The service is online, but complex workflows involving long context, files, and multi-step execution appear degraded.

Hopefully this additional environment information helps determine whether this is a broader regression rather than an isolated account issue.

exactly, that’s pretty bad

This sounds very close to what I’m investigating, especially the part where High/Extra High used to spend much longer on these jobs, but since around Aug 19–20 it starts correctly, does a bunch of planning/verification, then stops short of actually doing the work.

Can you check something fairly simple in your old/current chats? Look at the “Worked for” times on some genuinely heavy High/Extra High turns.

Before this started, did you have ordinary Chat turns that ran substantially longer than half an hour, ideally 60m+? And now, when one of these jobs fails or comes back unfinished, does it tend to land somewhere around 25–27 minutes?

I’m asking because I’ve got native data from my own Plus account showing a very specific before/after change. I have a preserved historical ordinary-Chat turn that ran 102m26s using the worker execution path. Current genuine GPT-5.6 Thinking/Extended turns on the same account repeatedly finish at 1541–1564 seconds, basically the 25–26 minute range, often with required work still unfinished.

One of the 1564s cases is especially useful because the connection itself stayed healthy for another ~61 seconds afterward, so it wasn’t simply the browser or SSE connection timing out.

There’s also another independent Pro user whose failed long run landed at about 25m54s.

I’m collecting the timing evidence here:

If you have an old long run and a recent failed one in your history, just the Worked for times + whether they actually finished would be extremely useful.

If your old workflow was regularly getting hour-scale turns and the same kind of work is now repeatedly dying around 25–27 minutes, then I think we may be looking at the same regression.

Hello,

I am creating this as a dedicated Bugs topic after a Community Leader asked me to separate these issues into their own report so they are easier for the appropriate OpenAI teams to see and investigate.

I want to keep this report respectful, factual, and focused on reproducible behavior.

I am a ChatGPT Pro subscriber, and for approximately the past six days, beginning around the August 19–20 service problems, a cluster of ChatGPT/GPT-5.6 issues has made my normal long-form workflow effectively unusable.

I appreciate that OpenAI has now acknowledged and fixed one confirmed regression that was unintentionally moving approximately 3% of Pro and Thinking turns to GPT-5.5-mini.

That acknowledgment was important and appreciated.

However, the routing regression was clearly not the only problem, because multiple other failures are still occurring, including on workflows using GPT-5.6 Sol High and Extra High Thinking.

I am not claiming every symptom below necessarily has the same root cause.

I am documenting the remaining behaviors so the appropriate ChatGPT, GPT-5.6, conversation-infrastructure, long-context, file-retrieval, execution/runtime, streaming, and UI teams can investigate them separately if necessary.

Environment

  • Plan: ChatGPT Pro
  • Model: GPT-5.6 Sol
  • Reasoning levels: High and Extra High
  • Primary surface: ChatGPT web
  • Device: Apple iPad
  • Operating system: iPadOS 26.6.1 (23G83)
  • Browser: Chrome for iOS / iPadOS
  • Chrome version: 152.0.7977.64
  • Workflow: Long-running complex creative-writing/project workflow
  • Typical workload: very long governing prompts, substantial conversation context, uploaded text files, source hierarchy rules, exact predecessor-file retrieval, continuity verification, research, and requested 20,000-word story continuations
  • Variants of the underlying context/file/Thinking failures have also reproduced in new conversations, not only one old thread.
  • Some earlier failures were also reproduced in Safari, so the broader GPT-5.6 reliability problems have not appeared limited to one Chrome session.

The new UI issue described below is specifically occurring for me on Chrome mobile web on the iPad.


1. NEW UI REGRESSION — Thinking / Activity sidebar can no longer be opened

This is the newest issue I am reporting.

Previously, while GPT-5.6 was Thinking and performing a task, I could open the right-side Activity / Thinking panel and see the ongoing Thinking stages, searches, file operations, Python/tool activity, and other execution information.

I have screenshots showing that this panel previously worked normally on the same general ChatGPT web workflow.

Now, on Chrome mobile web on my iPad, I can no longer reliably pull up that sidebar while the model is Thinking.

The panel that previously opened from the right side is effectively unavailable/inaccessible.

This makes debugging the other problems much harder because I can no longer reliably inspect what ChatGPT is doing during the Thinking phase.

This does not appear to be only my account.

I raised this in another Community discussion, and a Community Leader replied:

“Thank you for raising this!
Please create a new topic in the bugs category.
If the team will see it then it’s more likely if the report is not hidden inside a different topic.”

That is why I am making this dedicated report.

Expected behavior

While GPT-5.6 is Thinking, I should be able to open the Activity/Thinking sidebar and inspect the visible execution stages as before.

Actual behavior

The sidebar can no longer be reliably opened on Chrome mobile web on my iPad.

Screenshot comparison

I have attached screenshots showing:

  • the previous working state, where the Activity/Thinking panel was visible on the right;
  • and the current state where I cannot pull that panel up normally.

I would appreciate confirmation whether this is an intentional UI change or a regression.


2. High / Extra High Thinking still behaves inconsistently

Even after the confirmed 5.6 → 5.5-mini routing regression was acknowledged, I am still concerned about the behavior of complex GPT-5.6 Sol High and Extra High tasks.

Before these recent problems, genuinely difficult requests involving large amounts of context, file retrieval, continuity verification, research, and generation would normally spend substantial time reasoning and executing.

Since the regression period began, I have seen dramatically inconsistent behavior.

Some complex High/Extra High turns:

  • complete far faster than would be expected for the requested workload;
  • miss clearly supplied instructions;
  • fail to apply previously acknowledged continuity;
  • incorrectly say required source material is unavailable;
  • or switch into explanation/planning mode instead of actually performing the requested task.

The problem is not simply that a response is “fast.”

The problem is that the unusually fast responses frequently correlate with missing work or failed execution.


3. Long prompts / long-context information is not being applied reliably

My workflow depends on long governing prompts containing:

  • source hierarchy;
  • continuity rules;
  • exact story seams;
  • character/location state;
  • relationship continuity;
  • body-state continuity;
  • research requirements;
  • file-reading requirements;
  • formatting requirements;
  • and explicit instructions about what the final response must contain.

Before the recent regression period, GPT-5.6 handled this workflow far more reliably.

Now, ChatGPT can correctly acknowledge information in the prompt and then behave shortly afterward as though that same information was never supplied.

Examples include:

  • correctly identifying an instruction and then failing to apply it;
  • treating an established workflow like a new standalone prompt;
  • saying a source or rule is missing when it is visibly present;
  • recovering the correct continuity during Thinking but not carrying it into final execution;
  • and producing an explanation of what should be done instead of doing it.

This feels less like ordinary forgetting and more like inconsistent context ingestion, retrieval, prioritization, compaction, or execution-state retention.


4. Uploaded files are sometimes falsely reported as missing

This remains one of the most serious issues.

My story workflow frequently requires an exact predecessor file.

I have had GPT-5.6 tell me that the required uploaded story file was unavailable and instruct me to upload it again.

In one specific example, GPT-5.6 High spent approximately 18 seconds and then told me that my accepted Part Thirty-Eight story file was not available.

However, another attempt was able to access the same required material and correctly recover the predecessor continuity.

I have also had the system directly access and verify a file and then subsequently behave as though that file state was unavailable.

So the problem is not simply:

“The user forgot to attach the file.”

The contradictory behavior is itself part of the bug.

Expected behavior

If a required uploaded file is available to the conversation and successfully retrieved, that file should remain reliably usable throughout the turn.

Actual behavior

The same source can be:

  • treated as available in one execution;
  • treated as missing in another;
  • or successfully read during Thinking but not reliably carried into final execution.

5. Verification / planning responses are replacing the requested output

This is one of the clearest examples I have documented.

I requested an actual 20,000-word story continuation.

GPT-5.6 worked on the request for approximately:

25 minutes 54 seconds

During the run it correctly:

  • recovered controlling source material;
  • recovered continuity;
  • identified the correct predecessor state;
  • performed research;
  • drafted/analyzed the continuation;
  • and apparently conducted extensive verification.

But instead of returning the requested story prose, the final response told me that:

  • a complete prose draft had been constructed;
  • it contained exactly 20,000 words;
  • it had approximately 694 paragraphs;
  • it had a specific median paragraph length;
  • duplicate-paragraph and repeated-sequence checks had been performed;
  • and additional final verification had been attempted.

The actual story itself was completely absent.

This is not the requested behavior.

The verification process is supposed to support the requested result.

It cannot replace the requested result.

Expected behavior

If the model spends 25+ minutes constructing and verifying the requested story, the final response should contain the story.

Actual behavior

The model returned a report describing the supposedly completed work instead of delivering the work.

I have seen variations of this broader pattern where the model:

  • explains the task;
  • lists what it intends to do;
  • summarizes what the result should contain;
  • says it has performed work;
  • or verifies preparation;

and then fails to execute the actual requested output.


6. Long-running execution appears to stop before the actual task is complete

The ~25–26 minute behavior may be related to the verification-only problem, but I am listing it separately because other users are investigating similar long-running execution behavior.

For difficult tasks, ChatGPT may:

  1. begin normally;
  2. read files;
  3. research;
  4. perform continuity analysis;
  5. construct or verify material;
  6. spend around 25–26 minutes processing;

and then terminate the useful execution without completing the required output.

My 25m54s story example is one concrete case.

This deserves investigation independently of the now-confirmed 5.5-mini routing regression because users are also investigating long-running failures on turns that appear to be genuine GPT-5.6 Thinking.


7. “Connection interrupted. Waiting for the complete answer”

I have repeatedly encountered:

“Connection interrupted. Waiting for the complete answer”

during active GPT-5.6 processing.

These have not always occurred immediately at the beginning of a request.

In some cases:

  • Thinking was already active;
  • files had already been accessed;
  • tool activity was underway;
  • or substantial work had already been performed.

One screenshot shows the model successfully reading and verifying a required 20,000-word text file during the Thinking process and then encountering a connection interruption.

This makes the issue especially disruptive because a long-running task can consume substantial time and then fail after much of the processing has already occurred.

Expected behavior

Once a long-running request is actively processing, the session/stream should remain stable long enough to deliver the completed response.

Actual behavior

The stream can interrupt while substantial processing is already underway.


8. File state and execution state sometimes appear to separate

A particularly strange pattern is that the Activity/Thinking stage can show that ChatGPT successfully:

  • searched for the correct file;
  • opened the file;
  • read it;
  • verified its length;
  • or recovered relevant continuity;

yet the final behavior does not reliably reflect that successful retrieval.

This suggests that the problem may not always be initial file access itself.

There may be a problem with the retrieved state being retained or propagated into later execution/final generation.

I cannot see the backend, so I am not asserting a specific cause.

I am asking OpenAI to investigate the handoff between:

retrieval → reasoning → execution → final generation.


9. Context can be correctly understood during Thinking but lost during execution

I have seen requests where GPT-5.6 correctly identifies:

  • the exact current story seam;
  • required characters;
  • location;
  • continuity;
  • restrictions;
  • research requirements;
  • and what the next story part is supposed to accomplish.

The Thinking process can look correct.

Then the final execution either:

  • does not happen;
  • falls back into a verification report;
  • claims material is missing;
  • or behaves as though the previously recovered information disappeared.

That is a major problem for complex workflows because it means successful reasoning/retrieval during the intermediate stage does not guarantee successful final execution.


10. Established long-running workflows are sometimes treated as fresh prompts

Another recurring symptom is a loss of workflow continuity.

Instead of treating the current request as the continuation of an established project with explicit governing instructions, the model may suddenly behave as though it is answering an isolated new request.

This can manifest as:

  • re-explaining instructions already established;
  • asking for sources that are already available;
  • substituting generic advice for task execution;
  • ignoring current continuity in favor of older or incomplete information;
  • or returning an explanation of how the task could be done.

For long-form projects, this is extremely disruptive.


11. The problem affects both execution quality and trust in retrieval claims

The false missing-file behavior creates another practical problem:

I can no longer assume that when ChatGPT says:

“The file is unavailable.”

or:

“The source was not supplied.”

that this statement is actually true.

I now have examples where the model made those claims and later successfully accessed the supposedly unavailable material.

That means users cannot reliably distinguish:

  • a genuine missing file;
  • a transient retrieval failure;
  • a context-processing failure;
  • or a hallucinated missing-source claim.

This is particularly dangerous for continuity-heavy work because a model may confidently refuse to proceed based on an incorrect statement about the available sources.


12. The broader regression has affected multiple users and environments

I am creating this report specifically from my own Pro/iPad/Chrome environment, but similar combinations of symptoms have been reported by other users.

Other Community reports have discussed:

  • High/Extra High Thinking behaving unusually;
  • long-context degradation;
  • attached-file/context loss;
  • planning replacing execution;
  • long-running jobs stopping before completion;
  • missing right-side navigation/UI elements;
  • and the previously confirmed GPT-5.6 → GPT-5.5-mini routing regression.

Again, I am not claiming all of these must share one cause.

I am saying that the post-August 19/20 period appears to contain several overlapping regressions that deserve to be separated and investigated rather than treated as one generic browser problem.


13. The confirmed GPT-5.6 → GPT-5.5-mini regression is good news, but it does not appear to explain everything

I appreciate OpenAI acknowledging that approximately 3% of Pro and Thinking turns were unintentionally being moved to GPT-5.5-mini and that this regression has now been fixed.

That acknowledgment validates one major issue users had been reporting.

However, I do not believe this dedicated bug report should be closed merely because that routing issue was fixed.

Several symptoms above remain separate candidates for investigation, particularly:

  • genuine GPT-5.6 long-running execution;
  • ~25–26-minute unfinished task behavior;
  • long-context handling;
  • file retrieval/state retention;
  • verification replacing execution;
  • connection interruptions;
  • and the missing Thinking/Activity UI sidebar.

The routing fix should hopefully make it easier to isolate whatever problems remain.


14. New UI issue should probably be routed separately if needed

The missing Thinking / Activity sidebar may be a completely separate front-end regression from the model/runtime problems.

If so, please route that portion of this report to the appropriate ChatGPT web/mobile-web UI team.

Again, my current environment for this UI issue is:

  • ChatGPT Pro
  • ChatGPT web
  • iPad
  • iPadOS 26.6.1 (23G83)
  • Chrome 152.0.7977.64

I previously had access to the Activity/Thinking side panel.

I now cannot reliably open it during the Thinking phase.

I have attached before/current screenshots for comparison.


15. Why this matters for my workflow

I use ChatGPT Pro specifically because my work requires difficult, long-running reasoning and large-context continuity.

My workflow is not a simple one-question chat.

It can require:

  • multiple source files;
  • long context;
  • exact predecessor recovery;
  • web research;
  • continuity verification;
  • substantial reasoning;
  • and long final generation.

Before this regression period, the same general workflow was functioning far more reliably.

For approximately six days, I have largely stopped using ChatGPT for the actual project because I cannot trust the system to reliably:

  • read the full instructions;
  • retain the relevant context;
  • access the files;
  • preserve retrieval state;
  • finish long-running execution;
  • deliver the requested result;
  • or maintain the connection long enough to complete the task.

I have instead spent much of that time reproducing and documenting bugs.


16. Troubleshooting already performed

I have already spent substantial time troubleshooting these problems.

This has included variations of:

  • refreshing/restarting sessions;
  • testing different conversations;
  • testing new chats;
  • checking uploaded files;
  • reproducing file access;
  • testing High and Extra High;
  • testing more than one browser;
  • collecting screenshots;
  • documenting exact failure behavior;
  • and reporting the issues to OpenAI Support.

Because several symptoms occur across conversations and browsers, I do not believe another generic “clear cache and retry” cycle adequately addresses the full regression.


17. What I am asking OpenAI to investigate

I would appreciate this report being routed to the relevant teams for investigation of:

GPT-5.6 / reasoning

  • High/Extra High execution reliability
  • reasoning runs that terminate too early
  • post-routing-fix stability

Long-context / conversation infrastructure

  • prompt ingestion
  • context prioritization
  • context compaction
  • conversation-state continuity
  • previously established instructions being inconsistently applied

File infrastructure

  • false missing-file claims
  • contradictory retrieval
  • file state disappearing between tool/reasoning/final generation
  • successful file reads not carrying into execution

Execution/runtime

  • planning or verification replacing task execution
  • ~25–26-minute unfinished long-running tasks
  • worker/execution handoff behavior
  • final output not being delivered after substantial work

Streaming/session stability

  • “Connection interrupted. Waiting for the complete answer”
  • active long-running turns losing the response stream

ChatGPT web UI

  • missing/inaccessible Thinking / Activity sidebar on iPad Chrome
  • related missing right-side navigation behavior in long conversations

18. Requested outcome

I am not asking for speculation about the cause.

I am asking for these behaviors to be:

  1. acknowledged;
  2. reproduced internally where possible;
  3. separated into the correct engineering/UI components;
  4. investigated using server-side telemetry;
  5. fixed;
  6. and verified on genuinely complex workflows rather than only short/simple prompts.

I would also appreciate updates when substantial parts of this regression cluster are fixed.

The acknowledged 5.6 → 5.5-mini regression was an encouraging first step.

I hope the remaining issues can now be isolated and repaired as well.

Thank you to the Community Leader who asked me to create this separate bug topic, and thank you to anyone on the OpenAI teams who reviews the evidence.

I am happy to provide the screenshots I have already collected for the specific examples above.

The main goal of this post is simply to put the remaining bugs in one clear, organized place so they are not hidden inside unrelated discussions and can hopefully reach the correct teams.

Hi, are you able to share the architecture\structure of your project, files, and prompt for more context?

For example:

  1. the relationships between files.
  2. Types of files you use.(.md, .txt ect..)
  3. architecture\structure of files(sections, subsections, citations).
  4. the workflows\prompts you are using(length of prompt in characters, architecture of the prompts you are using, retrieval protocols of context and continuity in your project, instructions, generation of prose\material)
  5. project instructions.
  6. ect…

Nothing private or story relate is needed, nothing that you might be uncomfortable with sharing.
I request that so that I can assess things, as I experience the same problems you are describing in a very similar “creative writing” project\usage context.
And if applicable to your use cases “research”(applied mathematics, ML).

It will be helpful in understanding the current situation in a better manner.

Unfortunately no everything i have shared that I can’t share i have shared with support but I can’t share those details here because the prompts are too long but I can only share screenshots or pictures of what exactly is happening and I can only share details of what is happening this is what is happening now in the screenshots it just now sits there thinking and not doing anything I can’t pull up the ui sidebar it doesn’t do anything,and these issues are getting worse this has been going on for seven days straight I have already emailed support this morning as they replied to my email asking me to screen record what happens when I try putting in the prompt , so it seems 5.6 is dealing with major regressions issues ,on top of thinking not being able to handle complex tasks and now freezing during thinking so now it doesn’t even do anything but gets frozen in thinking ,now I’m not dealing with broken responses ,I’m dealing with 5.6 not being able to handle complex prompts or tasks and jsut freezes in thinking

I can only help and provide some insight\information regarding connection and file infrastructure.

I recommend trying to use the ChatGPT desktop app(previously codex).
In my personal experience the connection is better there(no prolonged thinking that leads to nothing), but in my experience it won’t fix any of your other problems, such as not reading\following instructions, loss of context during execution, context being compacted in every message ect…

a fix for your file infrastructure problem could be moving to codex and working in a dedicated work environment\folder where all of your files are in.
(Codex is available in desktop and there is a preview for phones, tablets ect… via the chat gpt mobile app)
As for myself, I work in a Project environment in “chat gpt projects”.
I downloaded all online material I might use in the project and added it to projects files in /mnt/data, and I use direct citations in files for sections and subsection, so for me there are no false missing file claims or contradictory retrieval.(this might be of help for you)

as for chat gpt thinking\activity sidebar, as far as I know they removed it. other users report the same thing, in reddit: 1vrs9o8/please_stop_messing_with_the_ui

As for problems with long prompts, I recommend using prompts that are equal or less than 10,000 characters, as long prompts are processed as treated as pastes\documents.
the model will summarize them rather than fully process them. you can read about it in the help.openAI articles specifically the `6825453-chatgpt-release-notes`.
The relevant entries are June 22, 2026 and August 4, 2026.
I don’t know if its true when the prompt is manually updated\written in increments of less than 10,000(meaning it stays in the form of a message in chat, but internally it could be processed as an attached file\document)

particularly about the context problems you are encountering.
in the browser\web the context limit of GPT 5.6 Sol is 272,000 tokens, you are not getting access to the full 1,050,000 tokens context limit, for this you need to use codex or the API, and change it to the full context limit in the files\settings.

As for the rest of your problems(I experience them as well) there is no fix that I found.
The problem with the model just stopping to work around 24-27 minutes stating that it can continue\was unable to finish the task for absolutely no reason.
The model not reading\following instructions\workflow\prompt, reframing the task and changing things for no reason, long context problems, summarising files instead of fully reading them, the model refusing to write intimacy\violence\ect…\… even thought the context is adult, consensual\fictional\ect…

As for the last bit, there have been talks\ideas in openAI about ‘grown-up mode’ since 2024\25 but I don’t think they will do anything about it anytime soon. (you can read about it in model spec 2025-09-12)

Everything was working fine last week this started around August 19th and August 20th so its cleary a issue on OpenAI side many users have been having issues for the past seven days

I know, I experience the same thing.
I can’t work on writing project anymore due to false-positive refusals, because the model doesn’t follow the workflow\prompt, re-frames instructions, generalises things ect…

I don’t know what they are doing behind the scenes but they are clearly doing something.
Unfortunately there is nothing that we as users can do about it.

What might be the cause;
I was only effected two days ago regarding the refusals and false positives ect…, and the sidebar was working for me until yesterday.
So it might be that the role-out of updates\changes they have made a few weeks ago only reached you around august 19th-20th.
(the speculative cause which I think is more probable: they are changing things without telling the users)

yes, its no thinking at all. its instant.

Yup and OpenAI hasn’t fixed it I haven’t used chatgpt in seven days because its unusable