Why is GPT-5.6 failing long-context tasks?

[mcmillanjoseph18]

I’m adding another detailed data point because **I am experiencing the same regression, and it has effectively halted one of my long-running workflows.**

I’m a **ChatGPT Pro user**, and before the recent service problems I was using **GPT-5.6 Sol with High and Extra High Thinking** for a very large, long-running creative-writing workflow involving:

* very long prompts;

* detailed governing instructions;

* long conversation context;

* multiple uploaded text files;

* exact predecessor-file retrieval;

* continuity checking;

* and complex multi-step generation.

This workflow was working reliably before the recent ChatGPT issues.

For me, the serious regression became consistently noticeable around **August 20 at approximately 5:01 PM ET**, following the August 19 ChatGPT incident and the subsequent conversation / Thinking / server instability.

My environment:

* **ChatGPT Pro**

* **GPT-5.6 Sol**

* **High Thinking and Extra High Thinking**

* **ChatGPT web**

* **Apple iPad**

* **iPadOS 26.6.1 (23G83)**

* **Chrome for iOS 152.0.7977.53**

* Also reproduced in **Safari**

This is not isolated to one old conversation. I have reproduced variants of the problem in **new chats as well**.

The biggest problem is that the model frequently behaves as though it has received or processed only part of the available context.

### Prompt/context truncation behavior

My prompts are very long because they govern a complicated long-form project.

Before these recent issues, GPT-5.6 Sol could process these prompts normally.

Now it will sometimes claim that information is **missing even though the information is visibly present in the prompt**.

It may correctly acknowledge a rule or source in one response and then behave in another response as though that same information was never supplied.

It feels less like the context simply disappeared and more like the model is no longer consistently **ingesting, retrieving, prioritizing, or applying all of it during generation**.

### Uploaded files being falsely reported as missing

This is one of the most disruptive symptoms.

I can upload the exact file required for a continuation, see that file attached in ChatGPT, and then GPT-5.6 Sol will tell me that the file is not available and ask me to upload it.

For example, one response told me:

> “I cannot honestly begin writing Part Thirty-Nine…”

because it claimed that the accepted Part Thirty-Eight story file was not present.

It then explicitly told me to upload the Part Thirty-Eight file.

But in another attempt with the same workflow, GPT-5.6 Sol stated that it had **successfully recovered the controlling sources**, directly read the cumulative file and Part Thirty-Eight, and recovered the exact predecessor seam.

So I am getting contradictory file-availability behavior.

That is extremely problematic for workflows where the model must retrieve an exact uploaded predecessor file rather than hallucinating from memory.

### Constant “verification drafts” instead of executing the task

This is probably the strangest regression I am seeing.

GPT-5.6 Sol will sometimes clearly understand the task, explain exactly what it is supposed to do, perform an enormous amount of verification/planning, and then **not actually deliver the requested output**.

For example, I requested a full long-form continuation.

Instead of giving me the continuation, the response told me:

> “A complete prose draft was constructed…”

It then told me that the draft supposedly had **exactly 20,000 words**, described paragraph statistics, duplicate checking, word-count verification, continuity corrections, file verification, and other implementation details.

But the actual 20,000-word story was **not delivered**.

The response was essentially a report describing the output instead of the output itself.

This is exactly what other people in this thread have described: the model appears to know what it needs to do, switches into a planning / verification / explanation mode, and then fails to perform the actual requested action.

### GPT-5.6 Thinking also feels abnormally fast

I am also seeing unusual behavior with **High and Extra High Thinking**.

Complex tasks that previously caused GPT-5.6 Sol to spend substantial time reasoning can sometimes return extremely quickly now.

In some cases the response comes back so rapidly that it does not appear consistent with the amount of context, file retrieval, analysis, and verification the request requires.

And those unusually fast responses are often the same responses that:

* miss instructions;

* falsely report missing context;

* falsely report missing files;

* hallucinate source-state problems;

* or return a verification/explanation instead of the actual task.

I obviously cannot see what is happening on the backend, so I am not claiming to know the specific cause, but from the user side it **looks like Thinking/context processing is being cut short, constrained, routed differently, or otherwise failing to operate the way it did before**.

### It also hallucinates missing information

Another issue is that the model will sometimes confidently state that a source, rule, predecessor text, or required detail was never supplied.

That statement can be demonstrably false.

This is especially concerning because the response often sounds very certain:

* “the file is not present”;

* “the required source is unavailable”;

* “I only have the governing prompt”;

* etc.

But the material actually is there.

This makes it difficult to trust whether a reported retrieval failure is genuine or whether the model simply failed to process the available context.

### I have already ruled out the obvious local troubleshooting

I initially wondered whether this was just Chrome on iOS.

I have already:

* cleared Chrome browser data/cache;

* uninstalled Chrome;

* reinstalled Chrome;

* restarted with clean browser state;

* tested new chats;

* tested High Thinking;

* tested Extra High Thinking;

* tested with the files visibly uploaded;

* and switched to Safari.

**The same general regression happens in Safari.**

That is a major reason I do not believe this is simply a corrupted Chrome installation or cache problem.

If it were purely local to Chrome, I would not expect essentially the same long-context / file / execution problems to appear in Safari as well.

### Why this is especially noticeable in long workflows

This may be much easier to miss if someone is only asking ChatGPT short questions.

In a short interaction, the model still appears normal much of the time.

The problem becomes extremely obvious when the task depends on:

* a large prompt;

* exact instructions;

* multiple attached files;

* long-running context;

* established workflow rules;

* precise continuation state;

* and actually executing the requested task instead of just explaining it.

That is where the reliability difference compared with before August 19/20 becomes dramatic.

### This has effectively stopped my project

This is not just a minor quality difference for me.

I cannot safely continue my project when I cannot determine whether GPT-5.6 Sol:

* received the entire prompt;

* processed the entire prompt;

* retained the relevant conversation context;

* can actually access an uploaded file;

* is incorrectly hallucinating that the file is missing;

* or will spend the response describing a task instead of executing it.

I am a **ChatGPT Pro subscriber paying $100/month**, specifically because I use the higher-capability models for serious long-form workflows.

At the moment, I have essentially had to stop that workflow because the model is not reliable enough for continuity-sensitive work.

### I think this needs engineering investigation

I have also submitted / am submitting this directly to OpenAI Support and am asking that it be escalated to the appropriate technical team.

I hope OpenAI investigates whether there has been a regression involving some combination of:

* GPT-5.6 Sol Thinking;

* long-context ingestion;

* context-window allocation;

* context compaction;

* instruction prioritization;

* conversation-state retrieval;

* file-upload state;

* file retrieval;

* model routing;

* server-side token/context budgeting;

* or another backend component involved in complex conversations.

I’m **not claiming to know which specific backend component is responsible**.

I am saying that the user-visible behavior has changed significantly, it began around the recent service instability, it reproduces across browsers for me, and multiple people here are now reporting remarkably similar symptoms.

The especially important pattern is:

**The model often still understands what the task is and can explain the relevant rules/context — but it no longer reliably applies that information when actually generating the requested result.**

And in my case I would add:

**It is also increasingly reporting files or prompt information as missing when they are visibly present.**

I have screenshots documenting all of the behaviors above, including contradictory file-retrieval responses and the “20,000-word draft was constructed” verification response where the actual requested story was never delivered.

If anyone from OpenAI is monitoring this thread, I strongly hope this gets passed to the **GPT-5.6 / ChatGPT conversation infrastructure / long-context / file-retrieval team**, because this looks substantially different from an ordinary front-end outage.

And if anyone else is experiencing the same thing, it would probably help to include:

* subscription tier;

* model;

* Thinking level;

* operating system;

* browser/app;

* whether it happens in new chats;

* whether attached files are falsely reported as missing;

* whether long prompts seem truncated;

* whether the model switches into planning/verification instead of execution;

* and approximately when the behavior began.

The more reproducible environment information we can collect, the easier it should be to establish whether this is a broader regression rather than isolated account behavior. And many other users are experiencing these same issues after the issues on August 19th with chatgpt 5.6 thinking these issues have been really bad and the fact that chatgpt has not acknowledged them or fixed them has made the platform unusable a tool that should be usable and should be able to handle complex tasks have been unusable for the past three days , prompts getting truncated, respones being verification drafts and claiming uploaded files are missing, instead of getting responses that the prompt is telling the model to do i get verification draft respones , claims of files missing, files not being read properly, prompts not properly being read , complex tasks that should take longer to process the model is blazing through the task its like 5.6 thinking on extra high and high is regressing and 5.6 is supposed to be chatgpt flagship model but ever since August 19th with the issues for 5.6 thinking and conversation and elevated errors these issues have gotten worse and its been like this for the past three days thr platform is just unusable and even though openai website says everything is up and running and it shows green status that is very misleading because everything isn’t working as intended its broken and I would like chatgpt to acknowledge all of the users complaints and bugs as paying customers we deserve that

[mcmillanjoseph18]

I am adding another detailed update because this has now been ongoing for approximately four days, and my long-running ChatGPT workflow remains effectively unusable.

I am a ChatGPT Pro subscriber paying $100/month, and I use GPT-5.6 Sol specifically for difficult long-context work involving:

• very long governing prompts;
• extensive conversation history;
• multiple uploaded text files;
• exact predecessor-file retrieval;
• continuity verification;
• detailed source hierarchies;
• research;
• and 20,000-word long-form creative-writing continuations.

Before the service problems around August 19–20, this workflow was working reliably.

Since then, I have experienced a cluster of failures that are now reproducible across attempts and, in several cases, documented in screenshots.

My environment:

• ChatGPT Pro
• GPT-5.6 Sol
• High Thinking
• Extra High Thinking
• ChatGPT web
• Apple iPad
• iPadOS 26.6.1 (23G83)
• Chrome for iOS 152.0.7977.53
• Also reproduced in Safari
• Variants have reproduced in new chats, not only one old conversation

OpenAI’s own documentation says High and Extra High on eligible paid plans are powered by GPT-5.6 Sol, and describes Sol as designed for complex work.

1. Repeated connection interruptions during active GPT-5.6 Thinking

I now have screenshots showing the same visible connection failure occurring more than once while ChatGPT was actively processing a request:

“Connection interrupted. Waiting for the complete answer”

One of these reproduced at approximately 12:58 PM ET on August 22, 2026.

This was not a connection failure before processing began. The Activity panel showed that Thinking/tool execution was already underway.

In one screenshot, the request had been processing for approximately 57 seconds.

In another reproduction, processing had already been underway for approximately 24 seconds.

This means the response stream/session was visibly interrupted while the complex request was already being worked on.

2. The most important file-access contradiction is now documented

My workflow requires the exact accepted Part Thirty-Eight story file before Part Thirty-Nine can be written.

One failed GPT-5.6 response told me:

“I cannot honestly begin writing Part Thirty-Nine…”

It claimed that the accepted Part Thirty-Eight prose was not present and explicitly instructed me to upload it.

That response completed after only about 18 seconds.

The problem is that Part Thirty-Eight had been uploaded.

In a separate attempt, ChatGPT successfully accessed that exact file.

The Activity panel showed Python directly opening the mounted Part Thirty-Eight TXT file, and the result confirmed exactly 20,000 words.

The response then correctly stated that it had recovered the controlling sources, read Part Thirty-Eight directly, and recovered the exact predecessor seam.

So I now have contradictory evidence from the system itself:

Attempt A: “Part Thirty-Eight is missing; upload it.”

Attempt B: Part Thirty-Eight is successfully opened and read directly, with all 20,000 words accessible.

This is not something that can reasonably be explained simply by saying that I forgot to upload the file.

Even worse, the successful file-access attempt subsequently encountered the “Connection interrupted” failure while processing continued.

3. GPT-5.6 is generating “verification drafts” instead of the requested output

This remains one of the strangest and most disruptive symptoms.

I requested the actual Part Thirty-Nine continuation.

Instead of delivering the story, GPT-5.6 spent approximately 25 minutes 54 secondsprocessing the request and then responded with a verification-style report.

It stated:

“A complete prose draft was constructed…”

It claimed that this invisible draft contained exactly 20,000 words, reported approximately 694 paragraphs, discussed median paragraph length, duplicate-paragraph checks, repeated-sequence checks, file verification, continuity corrections, and SHA-256 verification requirements.

But the actual 20,000-word story was not delivered at all.

The system effectively told me that it had completed the requested work and then substituted a report about the work for the work itself.

That is a serious execution failure.

The verification process is supposed to support delivery of the requested story. It cannot replace the requested story.

4. High and Extra High Thinking are behaving inconsistently and sometimes abnormally fast

Both High and Extra High are affected.

This is especially noticeable because my requests are not simple questions.

They involve large prompts, multiple source files, continuity retrieval, research, exact predecessor-state reconstruction, visual/source mappings, and very large final outputs.

Before the recent problems, complex requests understandably required substantial processing.

Now some comparable requests return extraordinarily quickly—sometimes in seconds—and those fast responses disproportionately contain the worst failures:

• missed instructions;
• missing-context claims;
• false missing-file claims;
• incorrect seam claims;
• abbreviated or shallow processing;
• planning/verification instead of execution;
• or a response that behaves as though only a fraction of the supplied prompt was actually applied.

Another user in the existing regression thread independently reported GPT-5.6 Sol at high reasoning responding too quickly while apparently failing to use memory and custom instructions. Another reported the highest reasoning setting sometimes responding almost instantly on Windows while long-term context behavior had changed after August 19.

5. Long prompts and established context are not being applied reliably

This does not look like simple forgetting.

The model can sometimes correctly explain my rules and continuity.

It may identify the exact predecessor seam.

It may state which sources control.

It may explain exactly what Part Thirty-Nine must do.

Then, during actual generation, it behaves as though that information disappeared or was never supplied.

Examples include:

• saying an uploaded predecessor file is missing when it is attached;
• saying required source material was never supplied when it is visibly present;
• acknowledging a hard rule and then immediately failing to apply it;
• replacing a requested story with a verification report;
• and treating an established long-running workflow like a fresh standalone prompt.

Other users in the same Developer Community thread are reporting closely related behavior, including attached file context apparently disappearing after several turns, execution being replaced by explanation/planning, and long-project context being applied less reliably.

6. New evidence: possible GPT-5.6 → GPT-5.5-mini server-routing mismatch

There is now another important data point that I believe OpenAI engineering needs to investigate.

A separate OpenAI Developer Community bug report published on August 22 documents a user inspecting ChatGPT Web network telemetry.

According to that report, the outgoing request correctly requested:

gpt-5-6-thinking

but server-provided telemetry for the resulting response identified:

gpt-5-5-mini

The report states that the model picker continued displaying GPT-5.6 Sol and that the mismatch was observed through server telemetry rather than by simply asking the model what it was. The report also says the behavior appeared session/browser dependent.

There is also an earlier community report from a Pro-tier user describing a similar HAR/network result in which a GPT-5.6 Pro request allegedly resolved to GPT-5.5-mini.

I want to be precise here:

I have not captured equivalent server metadata proving that my own Pro requests are being routed to GPT-5.5-mini.

These community reports therefore do not prove that model routing is the cause of my specific failures.

But they make server-side routing/fallback behavior a very concrete engineering hypothesis that should now be investigated rather than dismissed as speculation.

If my UI says GPT-5.6 Sol / High or Extra High, engineering should be able to determine from server logs which model actually served each affected request and whether any fallback occurred.

OpenAI’s Help Center currently says manually selected High and Extra High use GPT-5.6 Sol, while also noting that ChatGPT may continue with another available reasoning model after a GPT-5.6 reasoning allowance is reached.

That makes transparent investigation of the resolved model especially important.

7. This is not isolated to one user or one platform

The original regression thread now contains multiple users reporting combinations of:

• GPT-5.6 responding abnormally quickly;
• attached file/context loss;
• custom instructions being ignored;
• planning/explanation replacing actual execution;
• model-identification inconsistencies;
• long-context workflows behaving differently after August 19;
• and creative-writing continuity degrading.

One user described attached files being correctly available initially and then appearing to disappear from active context after several turns.

Another described the model repeatedly explaining what it intended to do while never actually producing the requested result.

Another reported the highest reasoning setting responding almost instantly on Windows desktop.

These are independent reports across different environments.

There are also now separate Community bug topics specifically concerning GPT-5.6 Thinking regression, file/conversation problems, connection failures, and suspected model-routing issues.

8. Official status history makes the timing especially notable

OpenAI officially recorded elevated errors affecting Thinking mode in ChatGPT on August 20.

That incident was investigated, mitigated, and marked resolved at 4:51 PM ET.

My persistent regression became clearly noticeable at approximately 5:01 PM ET on August 20, roughly ten minutes after that incident was marked resolved.

That timing does not prove causation.

However, it gives engineering a very specific window to examine.

OpenAI also recorded another ChatGPT web incident on August 21 involving users being unexpectedly logged out while refreshing.

As of this update, I have not found an official OpenAI incident specifically acknowledging the broader combination of long-context failure, false file-missing claims, verification-only responses, abnormal High/Extra High behavior, and possible model-routing inconsistency.

9. I have already exhausted reasonable local troubleshooting

I have:

• cleared Chrome browser data/cache;
• uninstalled Chrome;
• reinstalled Chrome;
• restarted from a clean browser state;
• tested new conversations;
• tested High;
• tested Extra High;
• confirmed files were visibly attached;
• tested Safari;
• and repeatedly reproduced the workflow.

The broader failure remains.

The fact that it also reproduces in Safari is especially important.

This is no longer reasonably explained by a corrupted Chrome cache.

10. This has halted my project for four days

This is not a cosmetic quality complaint.

My workflow depends on exact continuity.

I cannot safely continue a 20,000-word story when I cannot know whether the system:

• processed my complete prompt;
• retained the controlling instructions;
• retrieved the required predecessor file;
• silently lost that file from active context;
• falsely hallucinated that the file was missing;
• actually served the GPT-5.6 model selected in the UI;
• prematurely shortened Thinking;
• replaced execution with a verification report;
• or will lose the response connection before the final output arrives.

I am paying for ChatGPT Pro specifically because I need the higher-capability model for serious complex work.

OpenAI itself describes GPT-5.6 Sol as its flagship/frontier model for complex professional work.

A workflow that operated normally before these service problems has now been effectively unusable for four days.

What I am asking OpenAI engineering to investigate

I already have an active Support case and am providing these screenshots and timestamps directly to OpenAI.

I believe engineering needs to inspect:

• requested model versus resolved model;
• High/Extra High reasoning configuration;
• reasoning/fallback allowance state;
• model-routing and fallback decisions;
• browser/session/device routing cohorts;
• context-window allocation;
• context compaction;
• server-side prompt/context budgeting;
• long-context ingestion;
• instruction prioritization;
• conversation-state retrieval;
• file-upload state;
• file-retrieval state;
• whether attached files remain available to later generation stages;
• tool-to-model state transfer;
• response-stream termination;
• connection/session stability;
• and whether a generation continues server-side after the client reports “Connection interrupted.”

I am not claiming to know which internal subsystem is responsible.

I am saying that I now have screenshots demonstrating contradictory file availability, failed execution after extensive processing, repeated connection interruptions, unusually fast Thinking failures, and independent community evidence that at least some users have observed unexpected server-resolved model routing.

That is enough evidence to warrant a real engineering investigation.

If anyone else is experiencing this, please report:

• subscription tier;
• selected model;
• High/Extra High setting;
• operating system;
• browser/app;
• whether it reproduces in new chats;
• whether uploaded files are falsely reported missing;
• whether long prompts appear incompletely applied;
• whether Thinking suddenly completes unusually quickly;
• whether you get planning/verification instead of the requested result;
• whether you see “Connection interrupted. Waiting for the complete answer”;
• and, if you know how to inspect network telemetry safely, whether the requested and server-resolved model identifiers actually match.

Do not publicly post authentication headers, cookies, session tokens, or other private credentials.

At this point I strongly hope OpenAI routes this to the GPT-5.6 / Thinking / ChatGPT conversation infrastructure / long-context / file-retrieval / model-routing / streaming engineering teams, because this is no longer behaving like ordinary model variance.

[DLPB]

See my latest Connection issues on top of 5.6 thinking on high and extra high regression - #7 by alithebigg1

[thomas181]

This forum isn’t designed to help unfortunately, I think for now we have better chances @-ting some youtuber that you watch on twitter to direct their attention to the matter, they have a much bigger following and can apply pressure much more effectively.

[mcmillanjoseph18]

Do not come in here and give temporary fixes that aren’t guaranteed to work and do not tell people to delete chats and risk losing data , you dont think many users have tried everything to get it to work properly, you font think they have tried disabling memory , logging out clearing the cache and data , trying different browsers these major issues are a backend server pipeline issue that only the OpenAI engineering teams can fix and this has been going on for four days straight so do not tell people to delete chats because that isn’t a solution

[mcmillanjoseph18]

I am posting another update because the GPT-5.6 Sol problems many of us have been documenting have now continued for approximately four days, and I have found additional information that I believe OpenAI engineering needs to examine.

At this point I want to separate three things very clearly:

1. what I can reproduce directly;
2. what other users have independently documented;
3. what I believe engineering should investigate as a possible cause, rather than something I can prove from outside OpenAI.

That distinction matters because I do not want this reduced to speculation when there is already substantial reproducible evidence of a real problem.

My environment

I am using:

• ChatGPT Pro
• GPT-5.6 Sol
• High Thinking
• Extra High Thinking
• ChatGPT web
• Apple iPad
• iPadOS 26.6.1 (23G83)
• Chrome for iOS 152.0.7977.53
• also reproduced in Safari
• variants reproduced in new chats, not merely one old conversation

I use ChatGPT for a very large long-form creative-writing workflow involving:

• extremely long governing prompts;
• long-running conversation context;
• multiple uploaded text files;
• exact predecessor-file retrieval;
• source hierarchies;
• continuity validation;
• character and world-state tracking;
• research;
• and 20,000-word story continuations.

This workflow worked reliably before the August 19–20 service problems.

For approximately four days, it has effectively been unusable.

The failures I can directly document

1. GPT-5.6 falsely claims uploaded files are missing

One of my Part Thirty-Nine attempts completed in approximately 18 seconds and told me:

“I cannot honestly begin writing Part Thirty-Nine…”

because it claimed the accepted Part Thirty-Eight prose was unavailable.

It explicitly told me to upload Part Thirty-Eight.

The problem is that Part Thirty-Eight had already been uploaded.

In another test, ChatGPT directly opened that exact TXT file and successfully read it.

The file contained exactly 20,000 words.

The model then correctly recovered the actual Part Thirty-Eight predecessor seam.

So the system has now given me two contradictory states for the same required source:

Run A: Part Thirty-Eight supposedly does not exist.

Run B: Part Thirty-Eight is directly opened and all 20,000 words are read successfully.

That is not a user forgetting to upload the file.

That is a retrieval/state/context inconsistency that needs engineering investigation.

2. Long prompts and established instructions appear to be incompletely applied

The model can sometimes explain my rules perfectly.

It can identify:

• the correct predecessor;
• the exact continuation requirements;
• the governing hierarchy;
• the characters;
• the continuity state;
• and what the finished response is supposed to contain.

Then, when it actually generates the answer, it behaves as though some of that information was never supplied.

This is why I have repeatedly described the symptom as more than ordinary “forgetting.”

The model often knows the information but fails to apply it during execution.

That exact pattern has now been independently described by other users in the OpenAI Developer Community: long project context appears available but is applied less reliably; established instructions are ignored; attached files appear to disappear from active context after several turns; and the model switches from execution into planning or explanation.

3. “Verification drafts” replace the actual requested output

Another Part Thirty-Nine attempt ran for approximately 25 minutes 54 seconds.

The model told me it had:

• retrieved the required files;
• recovered the correct seam;
• performed research;
• checked continuity;
• constructed the complete story;
• rebuilt paragraph structure;
• checked duplicates;
• verified the word count;
• and produced an exactly 20,000-word draft.

The final response then said:

“A complete prose draft was constructed…”

and proceeded to give me paragraph statistics and verification information.

But the actual story was never delivered.

It claimed the requested work existed somewhere internally and substituted a report about that work for the requested work itself.

This is not a stylistic complaint.

It is an execution failure.

Other users are describing essentially the same pattern: the model states exactly what it is going to do, explains the approach in detail, and then never performs the requested action.

4. High and Extra High Thinking sometimes blaze through complex tasks abnormally fast

This continues to be one of the clearest behavioral changes.

These are not simple questions.

They involve massive prompts, multiple files, predecessor reconstruction, research, continuity checking, visual mappings, and 20,000-word output requirements.

Yet some failed High/Extra High requests suddenly finish in seconds.

Those are disproportionately the runs that:

• miss instructions;
• claim context is absent;
• falsely claim files are missing;
• hallucinate an incorrect source state;
• or produce an explanation instead of performing the task.

Other users have independently reported the same thing, including GPT-5.6 Sol at high reasoning appearing to answer far too quickly while failing to use memory or custom instructions.

OpenAI’s own documentation says High is extended reasoning and Extra High is the highest reasoning effort available with GPT-5.6 Sol. GPT-5.6 Sol is described as a frontier model intended for complex professional work.

That makes this behavior especially difficult to reconcile with what the product claims those settings are supposed to provide.

5. Repeated connection interruptions during active Thinking

I also now have multiple screenshots showing:

“Connection interrupted. Waiting for the complete answer”

while the Activity panel is still showing active Thinking or tool execution.

One of these occurred at approximately 12:58 PM ET on August 22.

One attempt had already been processing for approximately 57 seconds.

Another reproduced after approximately 24 seconds.

In one case, the system had already successfully opened and inspected the required Part Thirty-Eight file before the connection failed.

So there appear to be cases where:

1. the file exists;
2. retrieval succeeds;
3. processing begins;
4. and then response/session delivery fails afterward.

That raises a further question for engineering: when the response stream reconnects or a request is retried, is the successful file/context/tool state preserved correctly?

New evidence: requested GPT-5.6 requests resolving to GPT-5.5-mini

This is one of the most significant new technical reports I have found.

A Developer Community user did not merely ask ChatGPT what model it thought it was.

They inspected ChatGPT Web network telemetry.

Their outgoing request specified:

gpt-5-6-thinking

with extended reasoning.

But server-provided telemetry for the response reported:

model_slug: gpt-5-5-mini

The user documented:

Requested: gpt-5-6-thinking
Resolved: gpt-5-5-mini

while the ChatGPT interface still displayed GPT-5.6 Sol.

That report is particularly interesting because the same account behaved differently in a clean browser/session environment. In the clean environment, GPT-5.6 correctly resolved to GPT-5.6 again.

The reporter therefore suspects browser/session identity, routing cohorts, feature flags, authentication/bootstrap state, or another server-side routing factor rather than a simple account-wide entitlement problem.

An additional user tested the same pattern and reported an especially important result:

after changing to a clean browser environment, the 5.5-mini routing problem disappeared, but the broader long-running execution/runtime regression remained.

That distinction matters.

It suggests there may be more than one bug:

• one possible model-routing/session problem;
• and a separate broader long-context/execution problem.

I have not personally captured server telemetry proving that my own Pro requests resolved to GPT-5.5-mini, so I am not claiming that as established fact for my account.

But at this point OpenAI engineering absolutely should inspect the requested model and actual resolved model for affected requests.

If my UI says GPT-5.6 Sol High or Extra High, there should be a clear answer in OpenAI’s telemetry about what actually served that response.

New question: are recent ChatGPT/model/context updates interacting with this regression?

I have also been looking at OpenAI’s own recent release history.

There have been multiple relevant changes very close to this period.

On August 18, OpenAI updated the Model Spec. The public notes say that update included new teen-related relational guidance, clearer handling of unsupported premises, capability/limits guidance, and other smaller changes. There is no public statement saying this update caused the current regression.

On August 20, OpenAI officially acknowledged elevated errors affecting Thinking mode in ChatGPT, deployed a mitigation, and marked that incident resolved at 4:51 PM ET.

My persistent regression became clearly noticeable at approximately 5:01 PM ET, around ten minutes afterward.

Again: correlation is not causation.

But engineering should inspect what changed around that window.

On August 21, OpenAI also changed how long conversations load on ChatGPT Web. The release notes say that longer chats now load in smaller sections rather than retrieving the entire conversation at once.

That may be purely a front-end loading optimization.

I am not claiming it means the model itself only receives part of the conversation.

However, given that one of the major reported symptoms is apparent loss or inconsistent application of long-thread context, I think OpenAI should explicitly confirm whether this change is completely independent of model-context retrieval, conversation-state reconstruction, or compaction.

The timing makes that a reasonable engineering question.

New concern: could safety/guardrail processing be contributing?

I also want to raise this carefully because there is a lot of unsupported speculation circulating.

I have seen claims that current failures are being caused by emergency security patches, sandbox-containment changes, or some kind of “adult mode pipeline” restoration.

I have not found reliable OpenAI documentation confirming those specific claims, so I am not presenting them as fact.

What OpenAI’s own GPT-5.6 documentation does confirm is that the model uses:

• protections trained into the model;
• real-time checks;
• monitoring;
• and additional handling for certain higher-risk requests.

OpenAI also explicitly acknowledges that these safeguards can occasionally affect legitimate requests.

That makes one engineering question legitimate:

Have any recent safety, moderation, monitoring, classifier, or model-behavior changes unintentionally increased false positives, processing overhead, context pressure, or execution interference in long complex workflows?

I do not know the answer.

None of us outside OpenAI can inspect the serving stack, GPU allocation, token budgets, classifier passes, context compaction pipeline, or routing system.

That is exactly why this cannot be solved by endlessly telling users to clear their browser cache.

Engineering has to investigate it.

My position on safety: adults should be treated like adults

I also want to be clear about my broader position because this affects my creative-writing workflow in a second way.

I am not asking OpenAI to eliminate safety systems.

There should absolutely be strong safeguards around minors, exploitation, genuinely dangerous real-world instructions, and other categories where meaningful protections are justified.

My concern is proportionality and contextual understanding.

Adult writers routinely write fiction involving:

• violence;
• grief;
• warfare;
• trauma;
• injury;
• complicated relationships;
• romance;
• nudity;
• mature intimacy;
• anatomical terminology;
• psychologically difficult material;
• and other adult subject matter.

Those topics should not automatically make a legitimate fictional work unsafe.

I have repeatedly experienced cases where GPT-5.6 correctly understands that characters are fictional adults, understands that the context is consensual fiction, understands that a discussion is about policy or writing technique—and then another generation reacts completely differently and blocks or sanitizes material that the previous generation handled normally.

That inconsistency forces adult writers to spend absurd amounts of time negotiating with the safety system instead of writing.

What is especially notable is that OpenAI itself now publicly uses the principle “treat adults like adults.”

Its official age-prediction documentation says that distinguishing teens from adults enables OpenAI to apply the right safeguards to teens and “treat adults like adults”, while still keeping safety boundaries in place.

I agree with that principle.

Treating adults like adults does not mean no rules.

It means:

• apply teen-specific protections to teens;
• retain appropriate universal safety boundaries;
• understand fictional context properly;
• stop treating every mature word or theme as equivalent;
• reduce false positives;
• and give verified adults greater contextual freedom where the content is otherwise permitted.

If a small part of a fictional request crosses a boundary, the system should make the smallest necessary adjustment and preserve the rest of the legitimate work.

It should not unnecessarily destroy an entire long-form response.

Why I am skeptical of more “workarounds”

I keep seeing suggestions such as:

• clear cookies;
• reinstall the browser;
• switch browsers;
• use Incognito;
• disconnect and reconnect the internet;
• start a new conversation;
• re-upload every file;
• recreate the Project;
• summarize the entire project again;
• or repeatedly retry the request.

Many of us have already done these things.

I have:

• cleared Chrome data;
• completely uninstalled Chrome;
• reinstalled it;
• restarted with clean browser state;
• tested Safari;
• tested new chats;
• tested High;
• tested Extra High;
• confirmed attachments were visible;
• and reproduced the failures repeatedly.

If the problem is in server-side routing, conversation reconstruction, file-state handling, context compaction, model serving, streaming infrastructure, or another backend subsystem, there is no client-side workaround that can repair OpenAI’s infrastructure.

Users do not have access to OpenAI’s model-serving systems.

We cannot restart a routing cluster.

We cannot inspect or reset a broken server-side session cohort.

We cannot restore a dropped context allocation.

We cannot change whatever model the serving layer ultimately resolves.

We cannot patch ChatGPT’s file-retrieval pipeline.

At some point “try clearing your browser again” stops being troubleshooting and becomes a distraction from the engineering problem.

The lack of official acknowledgement is becoming a problem of its own

The official dashboard currently treats the August 20 Thinking incident as resolved.

Yet fresh Developer Community reports are still appearing involving:

• GPT-5.6 Thinking behaving abnormally;
• file/context failures;
• execution being replaced by planning;
• connection problems;
• and suspected 5.6 → 5.5-mini routing mismatches.

OpenAI’s own status page notes that availability is reported at an aggregate level and that individual experience can vary depending on tier, model, and features.

So a green dashboard does not necessarily establish that a specific combination such as:

GPT-5.6 Sol + Pro + High/Extra High + long conversation + multiple files + long-form generation + web streaming

is functioning correctly.

What paying customers need now is acknowledgement.

If engineering is already investigating, say so.

If a regression was introduced, say so.

If the routing reports are real, clarify them.

If a mitigation is underway, tell affected users.

If a rollout needs to be reverted, do it.

Silence while users spend days trying to diagnose server-side behavior from outside the system is not a good experience.

Four days of unusability matters

I am paying $100/month for ChatGPT Pro because I need the higher-capability models for serious work.

GPT-5.6 Sol is marketed by OpenAI as a frontier model for complex professional work, with a context window exceeding one million tokens and high/xhigh reasoning support.

That is exactly why I use it.

My workflow should be one of the use cases where GPT-5.6 Sol provides the most value.

Instead, for four days I have been unable to safely continue my story because I cannot trust whether:

• the entire prompt was ingested;
• the correct predecessor was retrieved;
• the attached file is still available;
• the model will hallucinate that something is missing;
• the selected model is actually the served model;
• High/Extra High will actually perform the expected reasoning;
• the response will turn into another verification report;
• or the connection will fail before the result reaches me.

That is not a minor quality fluctuation.

For this workflow, that is functional unusability.

And persistent reliability problems are exactly the kind of thing that eventually cause paying users to reconsider whether they can justify renewing expensive subscriptions.

What I want OpenAI engineering to investigate

I would like OpenAI to correlate the reports appearing across these threads and inspect:

• GPT-5.6 Sol model serving;
• requested model vs. resolved model;
• reasoning-effort selection;
• fallback conditions;
• account/session/browser/device routing cohorts;
• feature-flag and experiment assignment;
• authentication/bootstrap state;
• long-context ingestion;
• context-window budgeting;
• conversation compaction;
• conversation-state reconstruction;
• Project memory;
• long-chat retrieval;
• file attachment state;
• file retrieval;
• tool-result propagation into final generation;
• output token/resource budgeting;
• execution/runtime limits;
• response streaming;
• reconnect behavior;
• and recent moderation/safety/model-behavior changes that might be unintentionally interfering with legitimate complex tasks.

I am not asserting that all of these are broken.

I am asking OpenAI to investigate them because users outside OpenAI cannot.

And I strongly recommend that the routing bug and the broader execution regression be investigated separately rather than assuming one automatically explains the other.

The current Community evidence specifically suggests that a clean session can restore GPT-5.6 routing while the larger execution/runtime regression can remain.

That could be an important clue.

My request to OpenAI

Please acknowledge this publicly and get the relevant engineering teams involved.

This needs attention from the teams responsible for:

• GPT-5.6 Sol
• Thinking
• model serving/routing
• ChatGPT conversation infrastructure
• long-context processing
• Projects/memory
• file retrieval
• response streaming
• model behavior/safety
• and creative-writing reliability

Users have spent four days providing screenshots, timestamps, environments, reproducible failures, network telemetry, and detailed descriptions.

We cannot fix a backend system from our browsers.

We need OpenAI to investigate it.

And separately, as OpenAI continues developing age-aware safety systems, I strongly encourage the company to follow its own stated principle:

Treat adults like adults.

Keep strong protections where they genuinely belong.

But improve context awareness, reduce false positives, preserve legitimate adult creative work, and do not let safety systems become so broad or inconsistent that the tool loses the capability people are paying to use.

Safety, reliability, and creative freedom do not have to be opposing goals.

A frontier model should be capable of all three.

[z17538239193]

The writing is very detailed and serious, and it is done with care . I also had the same problem at about 14:00 on the 20th. I input a 5.6 model but the output was 5.5mini. At the same time, I also remember that OPENAI released a fix for the problem that night, which lasted until about 2 o’clock in the morning and announced that it was all solved. But the fact is that I still have the problem and it has not been improved.

[mcmillanjoseph18]

The problem isn’t fixed many users are still experiencing these major issues i haven’t even used chatgpt in the last four days because its unstable and unusable and many users have reported these problems and the fact OpenAI hasn’t said anything or acknowledge them all we can do is wait for them to hopefully fix the issues but with how they have been silent on the problems all we can do is keep reporting the issues but it is ridiculous that its been like this for four days straight and it has made the platform just unusable because of how broken the model is, its like there are problems every week and it gets worse each time

[z17538239193]

I’m still using it. I chose to use Codex because it’s still at version 5.6 and is stable. Although its judgment ability is not as good as GPT, this solution can work for the time being, but the credit limit is insufficient.

[z17538239193]

You can post your opinions in my posts, which may get better attention if gather them together. Possible GPT-5.6 Sol routing mismatch: selected GPT-5.6 but server metadata shows GPT-5.5-mini

[josecordesal]

Same problem… I lost 3 clients

[mcmillanjoseph18]

August 23 Update — Four days of GPT-5.6 Sol failures: new routing evidence, long-conversation changes, safety/guardrail concerns, and why local “workarounds” are no longer an adequate answer

I am posting another update because the GPT-5.6 Sol problems many of us have been documenting have now continued for approximately four days, and I have found additional information that I believe OpenAI engineering needs to examine.

At this point I want to separate three things very clearly:

1. what I can reproduce directly;

2. what other users have independently documented;

3. what I believe engineering should investigate as a possible cause, rather than something I can prove from outside OpenAI.

That distinction matters because I do not want this reduced to speculation when there is already substantial reproducible evidence of a real problem.

My environment

I am using:

• ChatGPT Pro

• GPT-5.6 Sol

• High Thinking

• Extra High Thinking

• ChatGPT web

• Apple iPad

• iPadOS 26.6.1 (23G83)

• Chrome for iOS 152.0.7977.53

• also reproduced in Safari

• variants reproduced in new chats, not merely one old conversation

I use ChatGPT for a very large long-form creative-writing workflow involving:

• extremely long governing prompts;

• long-running conversation context;

• multiple uploaded text files;

• exact predecessor-file retrieval;

• source hierarchies;

• continuity validation;

• character and world-state tracking;

• research;

• and 20,000-word story continuations.

This workflow worked reliably before the August 19–20 service problems.

For approximately four days, it has effectively been unusable.

---

The failures I can directly document

1. GPT-5.6 falsely claims uploaded files are missing

One of my Part Thirty-Nine attempts completed in approximately 18 seconds and told me:

“I cannot honestly begin writing Part Thirty-Nine…”

because it claimed the accepted Part Thirty-Eight prose was unavailable.

It explicitly told me to upload Part Thirty-Eight.

The problem is that Part Thirty-Eight had already been uploaded.

In another test, ChatGPT directly opened that exact TXT file and successfully read it.

The file contained exactly 20,000 words.

The model then correctly recovered the actual Part Thirty-Eight predecessor seam.

So the system has now given me two contradictory states for the same required source:

Run A: Part Thirty-Eight supposedly does not exist.

Run B: Part Thirty-Eight is directly opened and all 20,000 words are read successfully.

That is not a user forgetting to upload the file.

That is a retrieval/state/context inconsistency that needs engineering investigation.

---

2. Long prompts and established instructions appear to be incompletely applied

The model can sometimes explain my rules perfectly.

It can identify:

• the correct predecessor;

• the exact continuation requirements;

• the governing hierarchy;

• the characters;

• the continuity state;

• and what the finished response is supposed to contain.

Then, when it actually generates the answer, it behaves as though some of that information was never supplied.

This is why I have repeatedly described the symptom as more than ordinary “forgetting.”

The model often knows the information but fails to apply it during execution.

That exact pattern has now been independently described by other users in the OpenAI Developer Community: long project context appears available but is applied less reliably; established instructions are ignored; attached files appear to disappear from active context after several turns; and the model switches from execution into planning or explanation.

---

3. “Verification drafts” replace the actual requested output

Another Part Thirty-Nine attempt ran for approximately 25 minutes 54 seconds.

The model told me it had:

• retrieved the required files;

• recovered the correct seam;

• performed research;

• checked continuity;

• constructed the complete story;

• rebuilt paragraph structure;

• checked duplicates;

• verified the word count;

• and produced an exactly 20,000-word draft.

The final response then said:

“A complete prose draft was constructed…”

and proceeded to give me paragraph statistics and verification information.

But the actual story was never delivered.

It claimed the requested work existed somewhere internally and substituted a report about that work for the requested work itself.

This is not a stylistic complaint.

It is an execution failure.

Other users are describing essentially the same pattern: the model states exactly what it is going to do, explains the approach in detail, and then never performs the requested action.

---

4. High and Extra High Thinking sometimes blaze through complex tasks abnormally fast

This continues to be one of the clearest behavioral changes.

These are not simple questions.

They involve massive prompts, multiple files, predecessor reconstruction, research, continuity checking, visual mappings, and 20,000-word output requirements.

Yet some failed High/Extra High requests suddenly finish in seconds.

Those are disproportionately the runs that:

• miss instructions;

• claim context is absent;

• falsely claim files are missing;

• hallucinate an incorrect source state;

• or produce an explanation instead of performing the task.

Other users have independently reported the same thing, including GPT-5.6 Sol at high reasoning appearing to answer far too quickly while failing to use memory or custom instructions.

OpenAI’s own documentation says High is extended reasoning and Extra High is the highest reasoning effort available with GPT-5.6 Sol. GPT-5.6 Sol is described as a frontier model intended for complex professional work.

That makes this behavior especially difficult to reconcile with what the product claims those settings are supposed to provide.

---

5. Repeated connection interruptions during active Thinking

I also now have multiple screenshots showing:

“Connection interrupted. Waiting for the complete answer”

while the Activity panel is still showing active Thinking or tool execution.

One of these occurred at approximately 12:58 PM ET on August 22.

One attempt had already been processing for approximately 57 seconds.

Another reproduced after approximately 24 seconds.

In one case, the system had already successfully opened and inspected the required Part Thirty-Eight file before the connection failed.

So there appear to be cases where:

1. the file exists;

2. retrieval succeeds;

3. processing begins;

4. and then response/session delivery fails afterward.

That raises a further question for engineering: when the response stream reconnects or a request is retried, is the successful file/context/tool state preserved correctly?

---

New evidence: requested GPT-5.6 requests resolving to GPT-5.5-mini

This is one of the most significant new technical reports I have found.

A Developer Community user did not merely ask ChatGPT what model it thought it was.

They inspected ChatGPT Web network telemetry.

Their outgoing request specified:

gpt-5-6-thinking

with extended reasoning.

But server-provided telemetry for the response reported:

model_slug: gpt-5-5-mini

The user documented:

Requested: gpt-5-6-thinking
Resolved: gpt-5-5-mini

while the ChatGPT interface still displayed GPT-5.6 Sol.

That report is particularly interesting because the same account behaved differently in a clean browser/session environment. In the clean environment, GPT-5.6 correctly resolved to GPT-5.6 again.

The reporter therefore suspects browser/session identity, routing cohorts, feature flags, authentication/bootstrap state, or another server-side routing factor rather than a simple account-wide entitlement problem.

An additional user tested the same pattern and reported an especially important result:

after changing to a clean browser environment, the 5.5-mini routing problem disappeared, but the broader long-running execution/runtime regression remained.

That distinction matters.

It suggests there may be more than one bug:

• one possible model-routing/session problem;

• and a separate broader long-context/execution problem.

I have not personally captured server telemetry proving that my own Pro requests resolved to GPT-5.5-mini, so I am not claiming that as established fact for my account.

But at this point OpenAI engineering absolutely should inspect the requested model and actual resolved model for affected requests.

If my UI says GPT-5.6 Sol High or Extra High, there should be a clear answer in OpenAI’s telemetry about what actually served that response.

---

New question: are recent ChatGPT/model/context updates interacting with this regression?

I have also been looking at OpenAI’s own recent release history.

There have been multiple relevant changes very close to this period.

On August 18, OpenAI updated the Model Spec. The public notes say that update included new teen-related relational guidance, clearer handling of unsupported premises, capability/limits guidance, and other smaller changes. There is no public statement saying this update caused the current regression.

On August 20, OpenAI officially acknowledged elevated errors affecting Thinking mode in ChatGPT, deployed a mitigation, and marked that incident resolved at 4:51 PM ET.

My persistent regression became clearly noticeable at approximately 5:01 PM ET, around ten minutes afterward.

Again: correlation is not causation.

But engineering should inspect what changed around that window.

On August 21, OpenAI also changed how long conversations load on ChatGPT Web. The release notes say that longer chats now load in smaller sections rather than retrieving the entire conversation at once.

That may be purely a front-end loading optimization.

I am not claiming it means the model itself only receives part of the conversation.

However, given that one of the major reported symptoms is apparent loss or inconsistent application of long-thread context, I think OpenAI should explicitly confirm whether this change is completely independent of model-context retrieval, conversation-state reconstruction, or compaction.

The timing makes that a reasonable engineering question.

---

New concern: could safety/guardrail processing be contributing?

I also want to raise this carefully because there is a lot of unsupported speculation circulating.

I have seen claims that current failures are being caused by emergency security patches, sandbox-containment changes, or some kind of “adult mode pipeline” restoration.

I have not found reliable OpenAI documentation confirming those specific claims, so I am not presenting them as fact.

What OpenAI’s own GPT-5.6 documentation does confirm is that the model uses:

• protections trained into the model;

• real-time checks;

• monitoring;

• and additional handling for certain higher-risk requests.

OpenAI also explicitly acknowledges that these safeguards can occasionally affect legitimate requests.

That makes one engineering question legitimate:

Have any recent safety, moderation, monitoring, classifier, or model-behavior changes unintentionally increased false positives, processing overhead, context pressure, or execution interference in long complex workflows?

I do not know the answer.

None of us outside OpenAI can inspect the serving stack, GPU allocation, token budgets, classifier passes, context compaction pipeline, or routing system.

That is exactly why this cannot be solved by endlessly telling users to clear their browser cache.

Engineering has to investigate it.

---

My position on safety: adults should be treated like adults

I also want to be clear about my broader position because this affects my creative-writing workflow in a second way.

I am not asking OpenAI to eliminate safety systems.

There should absolutely be strong safeguards around minors, exploitation, genuinely dangerous real-world instructions, and other categories where meaningful protections are justified.

My concern is proportionality and contextual understanding.

Adult writers routinely write fiction involving:

• violence;

• grief;

• warfare;

• trauma;

• injury;

• complicated relationships;

• romance;

• nudity;

• mature intimacy;

• anatomical terminology;

• psychologically difficult material;

• and other adult subject matter.

Those topics should not automatically make a legitimate fictional work unsafe.

I have repeatedly experienced cases where GPT-5.6 correctly understands that characters are fictional adults, understands that the context is consensual fiction, understands that a discussion is about policy or writing technique—and then another generation reacts completely differently and blocks or sanitizes material that the previous generation handled normally.

That inconsistency forces adult writers to spend absurd amounts of time negotiating with the safety system instead of writing.

What is especially notable is that OpenAI itself now publicly uses the principle “treat adults like adults.”

Its official age-prediction documentation says that distinguishing teens from adults enables OpenAI to apply the right safeguards to teens and “treat adults like adults”, while still keeping safety boundaries in place.

I agree with that principle.

Treating adults like adults does not mean no rules.

It means:

• apply teen-specific protections to teens;

• retain appropriate universal safety boundaries;

• understand fictional context properly;

• stop treating every mature word or theme as equivalent;

• reduce false positives;

• and give verified adults greater contextual freedom where the content is otherwise permitted.

If a small part of a fictional request crosses a boundary, the system should make the smallest necessary adjustment and preserve the rest of the legitimate work.

It should not unnecessarily destroy an entire long-form response.

---

Why I am skeptical of more “workarounds”

I keep seeing suggestions such as:

• clear cookies;

• reinstall the browser;

• switch browsers;

• use Incognito;

• disconnect and reconnect the internet;

• start a new conversation;

• re-upload every file;

• recreate the Project;

• summarize the entire project again;

• or repeatedly retry the request.

Many of us have already done these things.

I have:

• cleared Chrome data;

• completely uninstalled Chrome;

• reinstalled it;

• restarted with clean browser state;

• tested Safari;

• tested new chats;

• tested High;

• tested Extra High;

• confirmed attachments were visible;

• and reproduced the failures repeatedly.

If the problem is in server-side routing, conversation reconstruction, file-state handling, context compaction, model serving, streaming infrastructure, or another backend subsystem, there is no client-side workaround that can repair OpenAI’s infrastructure.

Users do not have access to OpenAI’s model-serving systems.

We cannot restart a routing cluster.

We cannot inspect or reset a broken server-side session cohort.

We cannot restore a dropped context allocation.

We cannot change whatever model the serving layer ultimately resolves.

We cannot patch ChatGPT’s file-retrieval pipeline.

At some point “try clearing your browser again” stops being troubleshooting and becomes a distraction from the engineering problem.

---

The lack of official acknowledgement is becoming a problem of its own

The official dashboard currently treats the August 20 Thinking incident as resolved.

Yet fresh Developer Community reports are still appearing involving:

• GPT-5.6 Thinking behaving abnormally;

• file/context failures;

• execution being replaced by planning;

• connection problems;

• and suspected 5.6 → 5.5-mini routing mismatches.

OpenAI’s own status page notes that availability is reported at an aggregate level and that individual experience can vary depending on tier, model, and features.

So a green dashboard does not necessarily establish that a specific combination such as:

GPT-5.6 Sol + Pro + High/Extra High + long conversation + multiple files + long-form generation + web streaming

is functioning correctly.

What paying customers need now is acknowledgement.

If engineering is already investigating, say so.

If a regression was introduced, say so.

If the routing reports are real, clarify them.

If a mitigation is underway, tell affected users.

If a rollout needs to be reverted, do it.

Silence while users spend days trying to diagnose server-side behavior from outside the system is not a good experience.

---

Four days of unusability matters

I am paying $100/month for ChatGPT Pro because I need the higher-capability models for serious work.

GPT-5.6 Sol is marketed by OpenAI as a frontier model for complex professional work, with a context window exceeding one million tokens and high/xhigh reasoning support.

That is exactly why I use it.

My workflow should be one of the use cases where GPT-5.6 Sol provides the most value.

Instead, for four days I have been unable to safely continue my story because I cannot trust whether:

• the entire prompt was ingested;

• the correct predecessor was retrieved;

• the attached file is still available;

• the model will hallucinate that something is missing;

• the selected model is actually the served model;

• High/Extra High will actually perform the expected reasoning;

• the response will turn into another verification report;

• or the connection will fail before the result reaches me.

That is not a minor quality fluctuation.

For this workflow, that is functional unusability.

And persistent reliability problems are exactly the kind of thing that eventually cause paying users to reconsider whether they can justify renewing expensive subscriptions.

---

What I want OpenAI engineering to investigate

I would like OpenAI to correlate the reports appearing across these threads and inspect:

• GPT-5.6 Sol model serving;

• requested model vs. resolved model;

• reasoning-effort selection;

• fallback conditions;

• account/session/browser/device routing cohorts;

• feature-flag and experiment assignment;

• authentication/bootstrap state;

• long-context ingestion;

• context-window budgeting;

• conversation compaction;

• conversation-state reconstruction;

• Project memory;

• long-chat retrieval;

• file attachment state;

• file retrieval;

• tool-result propagation into final generation;

• output token/resource budgeting;

• execution/runtime limits;

• response streaming;

• reconnect behavior;

• and recent moderation/safety/model-behavior changes that might be unintentionally interfering with legitimate complex tasks.

I am not asserting that all of these are broken.

I am asking OpenAI to investigate them because users outside OpenAI cannot.

And I strongly recommend that the routing bug and the broader execution regression be investigated separately rather than assuming one automatically explains the other.

The current Community evidence specifically suggests that a clean session can restore GPT-5.6 routing while the larger execution/runtime regression can remain.

That could be an important clue.

---

My request to OpenAI

Please acknowledge this publicly and get the relevant engineering teams involved.

This needs attention from the teams responsible for:

• GPT-5.6 Sol

• Thinking

• model serving/routing

• ChatGPT conversation infrastructure

• long-context processing

• Projects/memory

• file retrieval

• response streaming

• model behavior/safety

• and creative-writing reliability

Users have spent four days providing screenshots, timestamps, environments, reproducible failures, network telemetry, and detailed descriptions.

We cannot fix a backend system from our browsers.

We need OpenAI to investigate it.

And separately, as OpenAI continues developing age-aware safety systems, I strongly encourage the company to follow its own stated principle:

Treat adults like adults.

Keep strong protections where they genuinely belong.

But improve context awareness, reduce false positives, preserve legitimate adult creative work, and do not let safety systems become so broad or inconsistent that the tool loses the capability people are paying to use.

Safety, reliability, and creative freedom do not have to be opposing goals.

A frontier model should be capable of all three.

[larryellison.9212]

This is a very detailed breakdown of the reliability issues, especially the distinction between model routing problems and the broader long-context execution failures. The file-retrieval inconsistencies and cases where planning replaces the requested output are particularly concerning for anyone relying on AI writing tools for long-form projects. I also agree that engineering needs to investigate server-side behavior rather than repeatedly asking users to clear their browsers or start new chats.

[mcmillanjoseph18]

I have sent in multiple support tickets of all of rhe issues I have run multiple tests , abd posted on here about it hoping that maybe OpenAI teams and engineering teams will see the posts I’m posting and the many other users posts because many users are experiencing the same issues the platform has been unusable for the past five days straight and the fact that OpenAI has been silent on these issues and haven’t acknowledged that 5.6 is just broken makes me wonder if they care or will even fix it, so the silent treatment is a slap in the face to us paying customers

[mcmillanjoseph18]

August 23 Update — Five days of GPT-5.6 Sol failures: new routing evidence, long-conversation changes, safety/guardrail concerns, and why local “workarounds” are no longer an adequate answer

I am posting another update because the GPT-5.6 Sol problems many of us have been documenting have now continued for approximately four days, and I have found additional information that I believe OpenAI engineering needs to examine.

At this point I want to separate three things very clearly:

1. what I can reproduce directly;

2. what other users have independently documented;

3. what I believe engineering should investigate as a possible cause, rather than something I can prove from outside OpenAI.

That distinction matters because I do not want this reduced to speculation when there is already substantial reproducible evidence of a real problem.

My environment

I am using:

• ChatGPT Pro

• GPT-5.6 Sol

• High Thinking

• Extra High Thinking

• ChatGPT web

• Apple iPad

• iPadOS 26.6.1 (23G83)

• Chrome for iOS 152.0.7977.53

• also reproduced in Safari

• variants reproduced in new chats, not merely one old conversation

I use ChatGPT for a very large long-form creative-writing workflow involving:

• extremely long governing prompts;

• long-running conversation context;

• multiple uploaded text files;

• exact predecessor-file retrieval;

• source hierarchies;

• continuity validation;

• character and world-state tracking;

• research;

• and 20,000-word story continuations.

This workflow worked reliably before the August 19–20 service problems.

For approximately four days, it has effectively been unusable.

───

The failures I can directly document

1. GPT-5.6 falsely claims uploaded files are missing

One of my Part Thirty-Nine attempts completed in approximately 18 seconds and told me:

“I cannot honestly begin writing Part Thirty-Nine…”

because it claimed the accepted Part Thirty-Eight prose was unavailable.

It explicitly told me to upload Part Thirty-Eight.

The problem is that Part Thirty-Eight had already been uploaded.

In another test, ChatGPT directly opened that exact TXT file and successfully read it.

The file contained exactly 20,000 words.

The model then correctly recovered the actual Part Thirty-Eight predecessor seam.

So the system has now given me two contradictory states for the same required source:

Run A: Part Thirty-Eight supposedly does not exist.

Run B: Part Thirty-Eight is directly opened and all 20,000 words are read successfully.

That is not a user forgetting to upload the file.

That is a retrieval/state/context inconsistency that needs engineering investigation.

───

2. Long prompts and established instructions appear to be incompletely applied

The model can sometimes explain my rules perfectly.

It can identify:

• the correct predecessor;

• the exact continuation requirements;

• the governing hierarchy;

• the characters;

• the continuity state;

• and what the finished response is supposed to contain.

Then, when it actually generates the answer, it behaves as though some of that information was never supplied.

This is why I have repeatedly described the symptom as more than ordinary “forgetting.”

The model often knows the information but fails to apply it during execution.

That exact pattern has now been independently described by other users in the OpenAI Developer Community: long project context appears available but is applied less reliably; established instructions are ignored; attached files appear to disappear from active context after several turns; and the model switches from execution into planning or explanation.

───

3. “Verification drafts” replace the actual requested output

Another Part Thirty-Nine attempt ran for approximately 25 minutes 54 seconds.

The model told me it had:

• retrieved the required files;

• recovered the correct seam;

• performed research;

• checked continuity;

• constructed the complete story;

• rebuilt paragraph structure;

• checked duplicates;

• verified the word count;

• and produced an exactly 20,000-word draft.

The final response then said:

“A complete prose draft was constructed…”

and proceeded to give me paragraph statistics and verification information.

But the actual story was never delivered.

It claimed the requested work existed somewhere internally and substituted a report about that work for the requested work itself.

This is not a stylistic complaint.

It is an execution failure.

Other users are describing essentially the same pattern: the model states exactly what it is going to do, explains the approach in detail, and then never performs the requested action.

───

4. High and Extra High Thinking sometimes blaze through complex tasks abnormally fast

This continues to be one of the clearest behavioral changes.

These are not simple questions.

They involve massive prompts, multiple files, predecessor reconstruction, research, continuity checking, visual mappings, and 20,000-word output requirements.

Yet some failed High/Extra High requests suddenly finish in seconds.

Those are disproportionately the runs that:

• miss instructions;

• claim context is absent;

• falsely claim files are missing;

• hallucinate an incorrect source state;

• or produce an explanation instead of performing the task.

Other users have independently reported the same thing, including GPT-5.6 Sol at high reasoning appearing to answer far too quickly while failing to use memory or custom instructions.

OpenAI’s own documentation says High is extended reasoning and Extra High is the highest reasoning effort available with GPT-5.6 Sol. GPT-5.6 Sol is described as a frontier model intended for complex professional work.

That makes this behavior especially difficult to reconcile with what the product claims those settings are supposed to provide.

───

5. Repeated connection interruptions during active Thinking

I also now have multiple screenshots showing:

“Connection interrupted. Waiting for the complete answer”

while the Activity panel is still showing active Thinking or tool execution.

One of these occurred at approximately 12:58 PM ET on August 22.

One attempt had already been processing for approximately 57 seconds.

Another reproduced after approximately 24 seconds.

In one case, the system had already successfully opened and inspected the required Part Thirty-Eight file before the connection failed.

So there appear to be cases where:

1. the file exists;

2. retrieval succeeds;

3. processing begins;

4. and then response/session delivery fails afterward.

That raises a further question for engineering: when the response stream reconnects or a request is retried, is the successful file/context/tool state preserved correctly?

───

New evidence: requested GPT-5.6 requests resolving to GPT-5.5-mini

This is one of the most significant new technical reports I have found.

A Developer Community user did not merely ask ChatGPT what model it thought it was.

They inspected ChatGPT Web network telemetry.

Their outgoing request specified:

gpt-5-6-thinking

with extended reasoning.

But server-provided telemetry for the response reported:

model_slug: gpt-5-5-mini

The user documented:

Requested:gpt-5-6-thinking

Resolved:gpt-5-5-mini

while the ChatGPT interface still displayed GPT-5.6 Sol.

That report is particularly interesting because the same account behaved differently in a clean browser/session environment. In the clean environment, GPT-5.6 correctly resolved to GPT-5.6 again.

The reporter therefore suspects browser/session identity, routing cohorts, feature flags, authentication/bootstrap state, or another server-side routing factor rather than a simple account-wide entitlement problem.

An additional user tested the same pattern and reported an especially important result:

after changing to a clean browser environment, the 5.5-mini routing problem disappeared, but the broader long-running execution/runtime regression remained.

That distinction matters.

It suggests there may be more than one bug:

• one possible model-routing/session problem;

• and a separate broader long-context/execution problem.

I have not personally captured server telemetry proving that my own Pro requests resolved to GPT-5.5-mini, so I am not claiming that as established fact for my account.

But at this point OpenAI engineering absolutely should inspect the requested model and actual resolved model for affected requests.

If my UI says GPT-5.6 Sol High or Extra High, there should be a clear answer in OpenAI’s telemetry about what actually served that response.

───

New question: are recent ChatGPT/model/context updates interacting with this regression?

I have also been looking at OpenAI’s own recent release history.

There have been multiple relevant changes very close to this period.

On August 18, OpenAI updated the Model Spec. The public notes say that update included new teen-related relational guidance, clearer handling of unsupported premises, capability/limits guidance, and other smaller changes. There is no public statement saying this update caused the current regression.

On August 20, OpenAI officially acknowledged elevated errors affecting Thinking mode in ChatGPT, deployed a mitigation, and marked that incident resolved at 4:51 PM ET.

My persistent regression became clearly noticeable at approximately 5:01 PM ET, around ten minutes afterward.

Again: correlation is not causation.

But engineering should inspect what changed around that window.

On August 21, OpenAI also changed how long conversations load on ChatGPT Web. The release notes say that longer chats now load in smaller sections rather than retrieving the entire conversation at once.

That may be purely a front-end loading optimization.

I am not claiming it means the model itself only receives part of the conversation.

However, given that one of the major reported symptoms is apparent loss or inconsistent application of long-thread context, I think OpenAI should explicitly confirm whether this change is completely independent of model-context retrieval, conversation-state reconstruction, or compaction.

The timing makes that a reasonable engineering question.

───

New concern: could safety/guardrail processing be contributing?

I also want to raise this carefully because there is a lot of unsupported speculation circulating.

I have seen claims that current failures are being caused by emergency security patches, sandbox-containment changes, or some kind of “adult mode pipeline” restoration.

I have not found reliable OpenAI documentation confirming those specific claims, so I am not presenting them as fact.

What OpenAI’s own GPT-5.6 documentation does confirm is that the model uses:

• protections trained into the model;

• real-time checks;

• monitoring;

• and additional handling for certain higher-risk requests.

OpenAI also explicitly acknowledges that these safeguards can occasionally affect legitimate requests.

That makes one engineering question legitimate:

Have any recent safety, moderation, monitoring, classifier, or model-behavior changes unintentionally increased false positives, processing overhead, context pressure, or execution interference in long complex workflows?

I do not know the answer.

None of us outside OpenAI can inspect the serving stack, GPU allocation, token budgets, classifier passes, context compaction pipeline, or routing system.

That is exactly why this cannot be solved by endlessly telling users to clear their browser cache.

Engineering has to investigate it.

───

My position on safety: adults should be treated like adults

I also want to be clear about my broader position because this affects my creative-writing workflow in a second way.

I am not asking OpenAI to eliminate safety systems.

There should absolutely be strong safeguards around minors, exploitation, genuinely dangerous real-world instructions, and other categories where meaningful protections are justified.

My concern is proportionality and contextual understanding.

Adult writers routinely write fiction involving:

• violence;

• grief;

• warfare;

• trauma;

• injury;

• complicated relationships;

• romance;

• nudity;

• mature intimacy;

• anatomical terminology;

• psychologically difficult material;

• and other adult subject matter.

Those topics should not automatically make a legitimate fictional work unsafe.

I have repeatedly experienced cases where GPT-5.6 correctly understands that characters are fictional adults, understands that the context is consensual fiction, understands that a discussion is about policy or writing technique—and then another generation reacts completely differently and blocks or sanitizes material that the previous generation handled normally.

That inconsistency forces adult writers to spend absurd amounts of time negotiating with the safety system instead of writing.

What is especially notable is that OpenAI itself now publicly uses the principle “treat adults like adults.”

Its official age-prediction documentation says that distinguishing teens from adults enables OpenAI to apply the right safeguards to teens and “treat adults like adults”, while still keeping safety boundaries in place.

I agree with that principle.

Treating adults like adults does not mean no rules.

It means:

• apply teen-specific protections to teens;

• retain appropriate universal safety boundaries;

• understand fictional context properly;

• stop treating every mature word or theme as equivalent;

• reduce false positives;

• and give verified adults greater contextual freedom where the content is otherwise permitted.

If a small part of a fictional request crosses a boundary, the system should make the smallest necessary adjustment and preserve the rest of the legitimate work.

It should not unnecessarily destroy an entire long-form response.

───

Why I am skeptical of more “workarounds”

I keep seeing suggestions such as:

• clear cookies;

• reinstall the browser;

• switch browsers;

• use Incognito;

• disconnect and reconnect the internet;

• start a new conversation;

• re-upload every file;

• recreate the Project;

• summarize the entire project again;

• or repeatedly retry the request.

Many of us have already done these things.

I have:

• cleared Chrome data;

• completely uninstalled Chrome;

• reinstalled it;

• restarted with clean browser state;

• tested Safari;

• tested new chats;

• tested High;

• tested Extra High;

• confirmed attachments were visible;

• and reproduced the failures repeatedly.

If the problem is in server-side routing, conversation reconstruction, file-state handling, context compaction, model serving, streaming infrastructure, or another backend subsystem, there is no client-side workaround that can repair OpenAI’s infrastructure.

Users do not have access to OpenAI’s model-serving systems.

We cannot restart a routing cluster.

We cannot inspect or reset a broken server-side session cohort.

We cannot restore a dropped context allocation.

We cannot change whatever model the serving layer ultimately resolves.

We cannot patch ChatGPT’s file-retrieval pipeline.

At some point “try clearing your browser again” stops being troubleshooting and becomes a distraction from the engineering problem.

───

The lack of official acknowledgement is becoming a problem of its own

The official dashboard currently treats the August 20 Thinking incident as resolved.

Yet fresh Developer Community reports are still appearing involving:

• GPT-5.6 Thinking behaving abnormally;

• file/context failures;

• execution being replaced by planning;

• connection problems;

• and suspected 5.6 → 5.5-mini routing mismatches.

OpenAI’s own status page notes that availability is reported at an aggregate level and that individual experience can vary depending on tier, model, and features.

So a green dashboard does not necessarily establish that a specific combination such as:

GPT-5.6 Sol + Pro + High/Extra High + long conversation + multiple files + long-form generation + web streaming

is functioning correctly.

What paying customers need now is acknowledgement.

If engineering is already investigating, say so.

If a regression was introduced, say so.

If the routing reports are real, clarify them.

If a mitigation is underway, tell affected users.

If a rollout needs to be reverted, do it.

Silence while users spend days trying to diagnose server-side behavior from outside the system is not a good experience.

───

Four days of unusability matters

I am paying $100/month for ChatGPT Pro because I need the higher-capability models for serious work.

GPT-5.6 Sol is marketed by OpenAI as a frontier model for complex professional work, with a context window exceeding one million tokens and high/xhigh reasoning support.

That is exactly why I use it.

My workflow should be one of the use cases where GPT-5.6 Sol provides the most value.

Instead, for four days I have been unable to safely continue my story because I cannot trust whether:

• the entire prompt was ingested;

• the correct predecessor was retrieved;

• the attached file is still available;

• the model will hallucinate that something is missing;

• the selected model is actually the served model;

• High/Extra High will actually perform the expected reasoning;

• the response will turn into another verification report;

• or the connection will fail before the result reaches me.

That is not a minor quality fluctuation.

For this workflow, that is functional unusability.

And persistent reliability problems are exactly the kind of thing that eventually cause paying users to reconsider whether they can justify renewing expensive subscriptions.

───

What I want OpenAI engineering to investigate

I would like OpenAI to correlate the reports appearing across these threads and inspect:

• GPT-5.6 Sol model serving;

• requested model vs. resolved model;

• reasoning-effort selection;

• fallback conditions;

• account/session/browser/device routing cohorts;

• feature-flag and experiment assignment;

• authentication/bootstrap state;

• long-context ingestion;

• context-window budgeting;

• conversation compaction;

• conversation-state reconstruction;

• Project memory;

• long-chat retrieval;

• file attachment state;

• file retrieval;

• tool-result propagation into final generation;

• output token/resource budgeting;

• execution/runtime limits;

• response streaming;

• reconnect behavior;

• and recent moderation/safety/model-behavior changes that might be unintentionally interfering with legitimate complex tasks.

I am not asserting that all of these are broken.

I am asking OpenAI to investigate them because users outside OpenAI cannot.

And I strongly recommend that the routing bug and the broader execution regression be investigated separately rather than assuming one automatically explains the other.

The current Community evidence specifically suggests that a clean session can restore GPT-5.6 routing while the larger execution/runtime regression can remain.

That could be an important clue.

───

My request to OpenAI

Please acknowledge this publicly and get the relevant engineering teams involved.

This needs attention from the teams responsible for:

• GPT-5.6 Sol

• Thinking

• model serving/routing

• ChatGPT conversation infrastructure

• long-context processing

• Projects/memory

• file retrieval

• response streaming

• model behavior/safety

• and creative-writing reliability

Users have spent four days providing screenshots, timestamps, environments, reproducible failures, network telemetry, and detailed descriptions.

We cannot fix a backend system from our browsers.

We need OpenAI to investigate it.

And separately, as OpenAI continues developing age-aware safety systems, I strongly encourage the company to follow its own stated principle:

Treat adults like adults.

Keep strong protections where they genuinely belong.

But improve context awareness, reduce false positives, preserve legitimate adult creative work, and do not let safety systems become so broad or inconsistent that the tool loses the capability people are paying to use.

Safety, reliability, and creative freedom do not have to be opposing goals.

A frontier model should be capable of all three.

Do not close or merge this topic with posts that are already closed I’m bringing awareness to these issues that many users have been experiencing the past five days so dont act like this is a small problem when its a major issue that has made the platform unusable for mantra paying customers over the last five days

[mcmillanjoseph18]

If any users are still experiencing these issues I have listed above feel free to share them here because as paying customers our time and money matters the fact that many users are still experiencing these major issues after five days of OpenAI not acknowledging the problem and not fixing these issues is a slap in the face and these issues should be acknowledged by OpenAI

[Seb67110]

I have the issue, the “thinking” doesn’t work and doesn’t do the job for my code. I will check further when I get home but as far as I tested at work it’s not any better yet.

[mcmillanjoseph18]

Five days of this and many users have not been able to use the platform a service that should be reliable has become unreliable and here the thing people say check to see if your account has been flagged, flagged for what no that is tge dumbest thing I have heard , there is nothing we can do but hope OpenAI actually fixes there servers and whatever issues is happening in the pipeline and others are saying 5.5 mini dosen’t exist if it doesn’t exist why does it show many paid plus and pro members being routed from 5.6 thinking on high or extra high to 5.5 mini , why does 5.6 thinking on high and extra high answer blazing fast with broken respones , verification drafts, hallucinating that uploaded files are missing, thinking is broken it dosent actually think for long complex tasks, it rushes through complex tasks with broken answers, it truncate prompts , so clearly something is broken with 5.6 and broken in OpenAI pipeline and servers

[krasnik]

I’m still seeing this as well, and one detail in your report may be more significant than it first appears.

Your failed long GPT-5.6 Sol run lasted approximately 25m54s, which is 1,554 seconds.

I have been independently investigating a long-running ordinary-Chat execution regression with native ChatGPT metadata and HAR captures. My preserved genuine GPT-5.6 Thinking / Extended foreground specimens currently terminate at:

1541, 1549, 1557, 1560, 1564 and 1564 seconds.

So your independent 1554-second run falls directly inside that very narrow cluster.

My strongest 1564s specimen is particularly useful because the network request itself did not fail at 26:04. The same HTTP/2 SSE connection remained healthy for another ~60.9 seconds and completed normally with HTTP 200, while the required workload was objectively unfinished. That substantially localizes the boundary to active execution/reasoning rather than a simple browser/network timeout.

I cannot establish from your public evidence that your 1554s run used the same backend execution class, so I do not want to overclaim that.

But the timing is close enough that I think Engineering should compare them.

There is another important development from today.

Earlier I had a separate browser/session problem where GPT-5.6 Thinking requests were resolving to GPT-5.5-mini. That environment now appears to have recovered sustained GPT-5.6-like behavior.

However, the long-running execution-routing problem remains separate.

Today I captured ordinary Chat and Work on the same Plus account, exact same frontend client build/version and exact same server conversation build.

Ordinary Chat remained on the foreground path with:

• no stream_handoff

• no wfr_ worker identity

• no SAServer source

• no per-turn worker topic

At essentially the same moment, GPT-5.6 Sol (max) in Work received:

temporal_conversation_turn=true
→ stream_handoff
→ exact conversation-turn-* topic
→ wfr_ worker execution
→ SAServer

The second Work worker was actually admitted while the ordinary-Chat foreground request was still running, with approximately 1.54 seconds of overlap.

That means the worker infrastructure was demonstrably available to the same account at the same instant.

So I now think there are at least two separable issues:

1. the reported GPT-5.6 → mini routing problem, which can change with browser/session treatment;

2. a broader ordinary-Chat execution/admission regression where genuine GPT-5.6 remains foreground/non-Temporal while Work still receives worker routing.

I documented the native execution-class evidence separately in my Community topic 1391943.

Your 25m54s / 1554s result is one of the strongest independent timing observations I’ve seen because it lands directly inside the native foreground cluster above.

If OpenAI Engineering investigates these reports, I think the useful comparison is not merely “does GPT-5.6 feel worse?” but whether affected long-running turns are being assigned a different execution/admission class than they were before the Aug 19–20 change.

[mcmillanjoseph18]

I have emailed chatgpt support because this is not right to us as paying customers it is a lack of respect for our time and money