Affected feature and model, if relevant: 5.6 SOL Extra High Reasoning
Bug
I prompted instructions into my ongoing work threads and what did not happen was instruction following. What did not happen was task completion. I said fix X and it went into the project and moved Y, moved Z, and in fact did not fix X. It scaled everything wrong with global scaling. -----> When it happened (with timezone) and how often: It started with the Astra rollout and it is still broken now.
Reproduction
Every Prompt is not being followed. This is not a “Prompt Engineering Problem” it is a “DO X” Problem, and it doesn’t do that. Instead it breaks/ruins already completed work in that environment.
Diagnostics
Exact error or screenshot:
When it happened (with timezone) and how often:I am not putting my project in here. Every prompt in to 5.6 SOL Extra High output is incorrect. It is not following instructions.
The [object Object] part is actually a useful clue because that is not just “the model misunderstood my instruction.” It suggests some structured value/state made it all the way to the UI or prompt surface and was rendered incorrectly as a string.
I would keep three symptoms separate in the report:
Instruction/scope failure — you ask for one narrow fix and Work changes unrelated things.
State/context failure — established hierarchy/context is missing or the expected Work state is not present.
UI/serialization failure — literal output such as [object Object] appears where a meaningful value should be.
Those can happen together without necessarily having one cause.
You do not need to post your private project to make this useful. If it reproduces again, the highest-value public details would be:
exact timestamp + timezone;
whether it was an existing Work thread or a fresh one;
whether the visible Work-state/status UI was present before sending and missing afterward;
the exact literal [object Object] text or screenshot;
whether the same narrow instruction behaves normally in a fresh ordinary-Chat control;
whether the bad Work turn actually modified files/state, or only said that it had.
I am tracking a separate long-run reliability problem where frontend state can diverge from what the backend worker is actually doing, so I would not let Support collapse this into generic “prompt engineering” unless they can explain the missing state and serialization symptom too.
The scope-change problem is especially important for Work because “task completed” is not enough if unrelated previously-correct state was mutated in the process.
Yep — exactly that nonsense. And this screenshot is actually much more useful than just describing it.
It shows a real Work turn, it visibly ran for 42 seconds, and the final rendered assistant message is literally:
The immediate job is to fix[object Object]
So this is not just “the model misunderstood what I wanted.” A structured object/value has leaked into the user-facing response as JavaScript-style stringification. That makes the serialization/state side of the bug independently visible.
It also means there are at least two concrete failures in the same turn:
the answer is semantically incomplete — it never tells you what the actual job is;
the UI/final-message path rendered [object Object] where meaningful state/content should have been.
If this happens again, please preserve the exact chat export and, if you are comfortable doing it, a DevTools HAR with Preserve log enabled. You do not need to expose your project files publicly. The valuable engineering question is what payload/state existed immediately before this final message was rendered.
If you can also reproduce the same simple “what do I need to do?” question in a fresh Work thread versus ordinary Chat, that would be a very clean control.
But yes: this screenshot is exactly the kind of evidence I meant. It makes the [object Object] symptom objective instead of anecdotal.
Right Now in this exact thread I am reduced to singular fix/repair.
multi-change instructions are causing collateral mutations, while single-change instructions are currently surviving better. So instead of “move A, add B, preserve C through H,” I am stuck in instructing do A, inspect, B, inspect, C, inspect. At this rate, a large interface becomes hundreds of repair turns instead of my actual development.
I had none of these problems August 23rd thru September 2nd 2026.
This has been a slog the last week + and it keeps getting worse, then a smidge better, then completely bad, then a smidge better. It is ridiculous for a “shipped state”.
Overall, I feel OAI adds too many things at once and has forgotten the gaming industry already learned these lessons decades ago.
Pre-Alpha testing → Fix Things → Alpha testing → Fix Things → Pre Beta testing → Fix Things → Beta Testing → Fix Things → Open Beta Testing → Fix Things → Launch.
OAI needs to learn this exact sequence between different feature launches.
If single-change instructions survive better in the same thread/project, while multi-change instructions cause collateral mutations, that is much more specific than “5.6 is worse lately.” It gives engineering something they can try to reproduce.
The clean version would be:
A only → inspect diff
B only → inspect diff
A + B + explicit “preserve C through H” → inspect diff
If A and B each work alone but the combined instruction starts touching C-H, that points toward a planning/decomposition or state-application failure rather than the individual edits simply being too difficult.
I would keep the [object Object] symptom separate for now. It may be related to the same broken state path, but we do not have enough evidence to claim that yet.
The other useful part of your report is the onset window: you say this workflow was behaving normally from Aug 23 through Sep 2, then became unstable during the following week. That is worth preserving exactly.
If one of these multi-change turns causes collateral edits again, the strongest evidence would be the before/after file diff plus the chat export (and HAR if practical). You can redact the actual project content. What matters is proving: requested files/regions vs files/regions actually mutated.
Having to turn one normal development request into A → inspect → B → inspect → C → inspect is not a viable workaround for a system whose whole purpose is supposed to be multi-step execution.
I am not entirely sure but I asked for a handover audit of the thread with Astra 6 and apparently some things are disabled for no reason, I know of. I need a complete audit of the thread as I have decided the degradation loop is unrecoverable with 5.6 sol extra high reasoning.
Now all my downloads are failing while using Astra GPT 6 inside of ChatGPT Work. I asked it for a thread audit in a Word Doc and every single word document fails to download and the preview doesn’t produce anything. This is just bad at this point.
This is worth separating from the earlier [object Object] and instruction-following failures, because file creation and file delivery are not necessarily the same layer.
For the next failed Word document, the useful question is: did Work fail to create the artifact, or did it create something that the preview/download path can no longer deliver?
A few details would narrow that quickly:
exact timestamp + timezone;
browser/app and version;
whether the DOCX appears as a normal file/card in the turn;
whether Preview is blank, errors, or never opens;
what Download does exactly: HTTP error, access denied JSON, expired/missing file, or nothing;
whether the same simple DOCX request works in a fresh Work thread at the same time;
if practical, whether another format such as PDF/TXT fails in the same old thread;
chat export/HAR kept private if you capture one, because raw network logs can contain session material.
There is one separate report that makes the delivery distinction interesting: in the long-running-unit-test thread, another user reported that long-running threads near their UI limit started producing download links that returned access denied as JSON. I am not saying this is the same cause, but the symptom is close enough that the exact download response here matters:
A very clean control would be:
old affected Work thread → generate tiny DOCX → preview/download
versus
fresh Work thread → same tiny DOCX → preview/download
If the fresh thread succeeds while the old thread consistently fails, that would point away from the DOCX generator itself and more toward thread/artifact state, authorization, or delivery binding.
I would also keep the Astra/5.6 model comparison separate unless the same file request is tested under both. The visible symptom is now objective enough that we do not need to guess which model change caused it.
yes - started happening approx… 24 hours ago. clicking on the web ui link goes 100% to an “access denied” with a bit of json wrapping. the app does not - at least on Android - have the same problem [for me].
the workaround i came up with whilst OpenAI sort that out is: ask ChatGPT to email the file to yourself as an attachment on gmail. you can then download it or ask another thread (again, in Android app this works) to get the raw message and decode its base64 and attachments for you.
A second user getting the same web-side access denied JSON, including from a less-busy web thread, while Android still downloads for you, makes this look much less like “the document was never generated” and more like a web delivery / authorization-path problem. It still does not tell us whether the fault is client-side or server-side.
If it happens again, the highest-value small capture would be:
exact HTTP status + the JSON error text, with tokens/IDs redacted;
timestamp + browser version;
whether the same artifact card/file can be opened from Android at that same time;
whether a newly generated tiny TXT/PDF/DOCX shows the same response.
Please don’t post a raw signed download URL or HAR publicly; those can carry private authorization material.
That would let us distinguish artifact exists but web authorization/delivery rejects it from a generic Work generation failure. The “dev team scrambling” part is plausible speculation, but the web-vs-Android A/B is the part we can actually preserve as evidence.
I mainly use ChatGPT for research and for drafting articles and summaries based on the material I’ve researched. GPT-5.6 Sol on High worked extremely well for me until Astra was introduced. Since then, both Sol and Astra have become practically unusable for my work.
I now have to correct almost every sentence. When the model makes a correction, it doesn’t consider the surrounding text or the document as a whole, so it often breaks parts that were previously fine. Fixing one issue creates another, and I end up repeating instructions and restoring information that should never have been removed.
In its current state, ChatGPT makes my workflow almost impossible. I spend so much time supervising and correcting it that it would often be easier and faster to do the entire job myself.
5.6 thinking on extra high and high are still pretty still erratic , and there are still connection interruption when some project chats or normal chats go past 25 minutes thinking on top of i tried using 5.6 sol high with a long prompt and instead of doing the task it gave me a verification draft of what it should be doing for the task , this is why I use 5.6 thinking on extra high but for one task it took hours to get it completed because 5.6 thinking on extra high would either get hit with a connection interruption at 25 minutes or get hit with a freezing in thinking at 35 minutes which in turns me a connection interruption after hours of failed attempts I got the task done but it shows 5.6 thinking on extra high and high are pretty still unreliable I dont ever remember 5.6 being this bad its like it got nerfed or water down to make astra look good , look here is my thing instead of coming out with a new model every few months make sure that the platform issues are fixed , and make sure the current model is still working properly, and what is worse is that im a chatgpt pro member and astra isnt even available to use in normal chats or project chats, its only available to use in work chat but I mainly use project chats and normal chats so 5.6 is what I use but I noticed a serious regression in 5.6 sol thinking on high and extra high, connection interruptions at 25 minutes, freezing during thinking at 35 minutes, hallucinating, not following prompt instructions ans ignoring prompt rules one day 5.6 can be fine the next day its broken and unreliable
