I am posting this because what initially looked like an isolated GPT-5.6 behavior issue has now turned into a broader reliability problem affecting multiple parts of ChatGPT on my paid account.
The problems started suddenly around August 31 / September 1, 2026.
I have already contacted OpenAI Support, completed the standard troubleshooting steps, and had the case escalated. Support later confirmed that there was a platform outage during the timeframe I reported and stated that the outage had been resolved.
However, the problems described below continued after the public outage was marked resolved.
This is why I do not believe this can be explained only by a browser, cache, network, VPN, or session problem.
1. GPT-5.6 Sol in regular Chat suddenly behaves like an Instant/fallback model
This was the first and most obvious regression.
Before this issue started, complex requests in regular Chat with GPT-5.6 Sol would visibly take more time, perform deeper analysis, use tools when necessary, and produce substantially more complete results.
Since around August 31 / September 1, the behavior changed suddenly.
Typical symptoms:
-
GPT-5.6 Sol is selected in the UI.
-
Complex tasks receive extremely fast responses.
-
The response often appears to skip deeper reasoning entirely.
-
Instructions that previously required substantial analysis are completed superficially.
-
Details are ignored more frequently.
-
Repeated prompting to analyze more carefully often does not restore the previous behavior.
-
Tasks that previously took meaningful processing time can suddenly return almost instantly with much poorer results.
This feels very different from a normal variation in answer quality.
There are also multiple community reports describing GPT-5.6 Sol or High/Thinking sessions apparently resolving to lower-tier/Instant-like behavior, including reports where users inspected request metadata and claimed to see GPT-5.5-mini or similar fallback behavior.
I cannot independently verify OpenAI’s internal routing on my own account, so I am not claiming that every affected request is definitely being routed to Mini.
What I can say with confidence is that the behavioral change is immediate, substantial, reproducible, and started suddenly.
2. Regular Chat and Work behave very differently on the same account
This is one of the strongest indicators that something is wrong beyond simple prompt quality.
I tested similar tasks using the same account.
In regular Chat:
-
reasoning quality is reduced,
-
file handling is unreliable,
-
PDF analysis can fail,
-
code/file-generation workflows can fail,
-
tool-heavy tasks often stop or behave superficially.
In Work mode:
-
the same or similar tasks often work substantially better,
-
files are processed more reliably,
-
multi-step execution is more capable,
-
document generation that failed in regular Chat has succeeded in Work.
So this is not simply “GPT-5.6 became worse everywhere.”
The product experience itself appears to be routing or executing these tasks differently.
This difference between regular Chat and Work has also been discussed by other community users.
3. PDF and file analysis became unreliable
Another major regression is file handling.
Before this problem started, I could upload PDFs and ask ChatGPT to inspect their contents.
After the regression, I began seeing behavior where ChatGPT appeared to know that a PDF/file was attached, but its answers suggested that it had not reliably processed the actual contents.
In some cases it appeared to infer or guess instead of grounding the answer in the document.
This is especially concerning because there may be no obvious upload error shown to the user.
From the UI perspective, the file appears to be present.
But downstream file processing may not be happening correctly.
Other users have reported very similar behavior involving attachments that exist in the conversation but fail to materialize correctly into the execution environment or /mnt/data.
There have also been community reports involving:
-
PDFs
-
ZIP files
-
CSV/XLSX files
-
source files
-
multi-file uploads
-
intermittent sandbox access failures
This makes the problem much broader than one particular file format.
4. Python / container / file generation is also unreliable
I also encountered failures while trying to perform very simple file-generation tasks.
For example, I used straightforward ReportLab code to create a PDF:
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer
from reportlab.lib.styles import getSampleStyleSheet
path = "/mnt/data/Balcony_Design_Trend_Book_2027_Vol01_Rebuild_Start.pdf"
doc = SimpleDocTemplate(path)
styles = getSampleStyleSheet()
story = []
content = """
Balcony Design Trend Book 2027
Volume 01 — The New Outdoor Room
"""
for line in content.split("\n"):
story.append(Paragraph(line, styles["BodyText"]))
story.append(Spacer(1, 8))
doc.build(story)
path
This is not a complicated workload.
It does not require an external API or complex computation.
Yet regular Chat struggled with execution/file generation in ways that had not happened previously.
Similar reports in the community mention:
-
/mnt/datafiles not being available, -
caas.internal.errors.ClientError, -
uploaded files not appearing inside the container,
-
container/Python failures even before meaningful file processing begins.
Again, similar workflows have worked better for me in Work mode.
5. Deep Research is now also failing
More recently, Deep Research has become another affected feature.
The failure mode is especially concerning:
Deep Research starts as if it is performing research, but it does not actually appear to search the web.
Symptoms include:
-
no visible web searches,
-
no meaningful source retrieval activity,
-
no citations,
-
no external sources,
-
a final “research” report that appears to be generated without actual research.
In other words, the Deep Research UI can appear to run while the core research/tool chain is apparently not executing.
This makes the feature effectively unusable for tasks that require current external information.
I have also seen other users report the same pattern: Deep Research spending several minutes running but ultimately showing zero searches and zero citations.
This is especially problematic if a Deep Research usage/credit is still consumed even when no actual source research occurred.
6. This started during a real platform incident — but did not end when the incident ended
OpenAI Support told me:
“At the timeline you mentioned, our system experienced a platform outage that caused higher-than-usual error rates. This issue has now been resolved.”
This confirms that there was a real platform-side incident at the time the behavior changed.
However, that explanation does not resolve the current problem.
The public outage was marked resolved, but the degraded behavior continued afterward.
Since then, OpenAI has also had additional incidents involving ChatGPT, Work, file uploads, Codex, Responses API latency, and other services.
So there has clearly been broader infrastructure instability during this period.
But the persistent regressions described here appear to extend beyond a single resolved outage.
7. OpenAI has also acknowledged temporary model/feature availability restrictions
OpenAI staff/moderation responses in related community threads have stated that:
-
access to certain models or features may temporarily be limited,
-
this can happen even with an active paid subscription,
-
limitations can be based on account activity,
-
OpenAI cannot provide details about those checks,
-
access is automatically reassessed.
This creates an additional question:
Are some of these regressions caused by an account-level availability/routing system rather than only infrastructure failures?
If so, users need much better visibility into what is happening.
A paying user should not select GPT-5.6 Sol while unknowingly receiving dramatically reduced reasoning/tool capability without any indication in the interface.
8. Troubleshooting already performed
I have already tried the standard troubleshooting steps suggested by Support:
-
completely new chats,
-
hard refresh,
-
signing out and back in,
-
logging out all active sessions,
-
incognito/private browsing,
-
extensions disabled,
-
content blockers disabled,
-
VPN/proxy disabled,
-
different browsers,
-
different devices,
-
different networks,
-
Lockdown Mode confirmed OFF.
The behavior persisted.
There are also no consistent upload/download error banners explaining the file failures.
This is why repeating generic browser troubleshooting is no longer useful.
9. Support case
I contacted OpenAI Support and explained the issue in detail.
The initial AI-assisted support repeatedly suggested browser/session/network troubleshooting.
After I confirmed those steps had already been completed, the case was escalated to a support specialist.
A human support response later confirmed the platform outage mentioned above but again suggested local troubleshooting after stating that the outage was resolved.
I replied explaining that the issue continued after the outage and that regular Chat and Work still behaved differently.
At this point I am still waiting for a substantive backend/account-level explanation.
Meanwhile, my paid subscription time continues to be consumed while several of the features I subscribed to are unreliable or unusable.
10. Why I am opening this bug report
I am not posting this to complain about one bad answer.
There appears to be a cluster of regressions affecting:
-
GPT-5.6 Sol reasoning behavior
-
model/routing consistency
-
regular Chat execution
-
file/PDF access
-
/mnt/data/ attachment materialization -
Python/container execution
-
generated file workflows
-
long or multi-step tasks
-
Deep Research web search
-
Deep Research citations/source retrieval
Multiple community users have reported overlapping symptoms during the same period.
OpenAI has already shipped some remediation/fixes for attachment access and has acknowledged that model/feature access can be temporarily restricted, but the overall problem does not appear to be fully resolved.
Expected behavior
If I explicitly select GPT-5.6 Sol on a paid account:
-
the requested model/reasoning experience should actually be delivered,
-
if a fallback or restriction occurs, the UI should clearly disclose it,
-
uploaded files should reliably be available to the analysis/execution environment,
-
PDF analysis should be grounded in the actual file contents,
-
Python/container execution should reliably access required files,
-
Deep Research should actually perform searches and retrieve sources,
-
Deep Research should not complete with zero research activity while presenting itself as a research result.
Actual behavior
Instead, I am intermittently seeing:
-
extremely fast, shallow responses,
-
reduced or absent reasoning,
-
failures to execute complex tasks,
-
files visible in the UI but unreliable during actual processing,
-
Python/file-generation failures,
-
differences between regular Chat and Work,
-
Deep Research completing without searches or sources.
What I am asking OpenAI to investigate
Please investigate this as a broader backend reliability/routing issue rather than another browser troubleshooting case.
Specifically:
-
Is GPT-5.6 Sol currently being silently routed or degraded for some paid users?
-
Are account-activity availability checks reducing reasoning or tool access?
-
Is regular Chat using a different execution/routing path from Work that is currently degraded?
-
Is attachment materialization into
/mnt/datastill unreliable? -
Are Python/container provisioning failures still occurring?
-
Is Deep Research currently experiencing failures where the research/search tool chain is not invoked?
-
Can users be informed when a selected model or feature is unavailable instead of silently receiving degraded behavior?
-
Can affected paid users receive restoration of lost usage/credits or subscription time when features were unusable?
If other users are experiencing the same symptoms, please add your platform, subscription tier, affected model, approximate date/time, and whether the same task behaves differently in Chat vs Work.
The more reproducible examples we collect, the easier it should be to distinguish local issues from backend regressions.