# GPT-5.6 High execution regression: ordinary Chat went 102m26s -\> repeated ~25–26m stops on same Plus account; Work still gets long-run handoff **URL:** \ **Category:** Bugs\ **Tags:** chatgpt, bug, conversation, regression, 5.6\ **Created:** [August 22, 2026, 9:14pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943 "2026-08-22T21:14:49Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 22, 2026, 9:14pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/1 "2026-08-22T21:14:49Z")
# Reproducible ChatGPT Plus execution-class regression: historical ordinary Chat used durable worker routing (\>100m); current ordinary Chat is non-Temporal/foreground (~26m class), while Work still receives worker handoff **Category:** ChatGPT / Bugs **Tags:** `chatgpt`, `bug`, `5.6`, `conversation`, `regression`, `projects` @OpenAI_Support — I am requesting **engineering review of a reproducible ChatGPT Plus execution-routing regression**. This is not a subjective “5.6 feels worse” report and it is not based only on screenshots. I have preserved historical native ChatGPT metadata, current native backups, independently privacy/fidelity-verified sanitized Aug-23 HAR transfer copies, exact request/turn IDs, a same-conversation route-flip chronology, current web and Windows desktop controls, and independent Aug 20–22 public corroboration. The narrow question is: > **Why did ordinary ChatGPT on this Plus account previously receive the durable `wfr_` / SAServer / per-turn worker execution family, while current ordinary Chat is returned as non-Temporal/foreground and current Work on the same account still receives the worker family? Is this expected product behavior, a rollout/experiment, an account-treatment problem, or a regression?** I am **not** claiming OpenAI guaranteed a 100-minute response. I am **not** claiming commercial intent. I am asking OpenAI to explain an observable execution-class change that correlates with a severe regression in long-running ordinary Chat. * * * ## Executive evidence ### 1. Historical ordinary Chat: worker-family execution, 102m26s A preserved native ordinary-Chat GPT-5.6 Thinking / Extended turn has: ```plaintext model: gpt-5-6-thinking thinking_effort: extended request_id: wfr_... async_source: saserver-...:conversation-turn-...:EU turn_exchange_id / working_turn_id: same conversation-turn identity finished_duration_sec: 6146 ``` > **Correction — 26 Aug:** I originally listed `stream_topic_id` and `is_temporal_turn=true` in this historical native block. On a re-audit of the canonical 102m26s export, those two fields are **not explicitly persisted in that export**. The historical object directly proves the `wfr_` request ID, SAServer `async_source`, GPT-5.6 Thinking/Extended model/effort, one request/exchange and 6146s duration. I have corrected the block rather than treating a reconstructed worker-topic identity/current-Work schema as a persisted historical field. This correction does not change the directly evidenced worker-family/duration comparison. `6146s` = **102m26s**. This was ordinary Chat, not Work or Codex. It was not a one-off. Another preserved GPT-5.6 Thinking / Extended conversation contains **12/12 worker-family turns** , including durations of 2,609s, 2,314s and 5,094s, across several European regions. The only claim I need from this is factual: **ordinary Chat previously received this worker family and could remain executing far beyond the current ~26-minute class.** ### 2. Same conversation flips worker → foreground on Aug 20 A separate preserved conversation contains worker-family turns at: - 07:41 UTC — `wfr_` + SAServer - 07:52 UTC — `wfr_` + SAServer - 08:14 UTC — `wfr_` + SAServer The last confirmed worker ended at approximately **08:17:44 UTC**. The first confirmed foreground turn in the **same conversation** began at **09:15:58 UTC** , still on genuine `gpt-5-6-thinking` / Extended, but with an ordinary UUID request ID and no persisted SAServer source. Therefore the observable route switch is bracketed to approximately: > **20 Aug 2026, 08:17:44–09:15:58 UTC** This substantially weakens “old conversation corruption,” permanent conversation binding, region, package update, and model downgrade as complete explanations. ### 3. Current clean ordinary Chat: genuine GPT-5.6, foreground class, 26m04s A current native ordinary-Chat control has: ```plaintext model: gpt-5-6-thinking thinking_effort: extended request_id: UUID async_source: absent finished_duration_sec: 1564 ``` `1564s` = **26m04s**. During this investigation I separately encountered the currently reported **GPT-5.5-mini fallback problem** in an earlier browser/session. I moved the investigation to a clean browser environment specifically to remove that contamination. The ~26-minute/foreground result remained while both requested and resolved model were genuine GPT-5.6 Thinking. So these are two different failure families: 1. requested GPT-5.6 → server resolves mini; 2. genuine GPT-5.6 Thinking → server still gives ordinary Chat the foreground/non-Temporal execution class. The mini problem is real, but it does not explain this controlled runtime regression. ### 4. Windows desktop ordinary Chat also terminates around 26m I tested the official Windows ChatGPT desktop app with a workload that explicitly required 1,200 unique source pages and hard acceptance gates. The UI offered **“Continue with Work?”** ; I selected **“Keep chatting here”** to preserve the ordinary-Chat control. Result: - **Worked for 26m43s** ; - only 31/1,200 required ledger rows had been completed; - the final response stated that **the execution environment forcibly ended tool interaction before the acceptance gate could be reached** ; - the desktop process did not crash; - established TCP connections remained present around the terminal window. This directly contradicts the theory that switching from web to desktop restores the previous long ordinary-Chat path, and it makes a simple browser-tab timeout a poor explanation. ### 5. Current Work on the same Plus account still receives the worker architecture This is the decisive current control. A matched same-account, same-machine, same-Project comparison shows: | Field / behavior | Current Work | Current ordinary Chat | | --- | --- | --- | | plan | Plus / paid | Plus / paid | | Project | same Project | same Project | | endpoint | `POST /backend-api/conversation` | same | | server `product_experience` | `work` | `chat` | | `requested_model_experience` | `work` | `thinking` | | `temporal_conversation_turn` | **true** | **false** | | route identity | worker `wfr_...` after handoff | UUID foreground | | SAServer `async_source` | **present** | absent | | `stream_handoff` | **present** | absent | | target `conversation-turn-*` topic | **present** | absent | | initial HTTP behavior | short POST, then handoff | original SSE remains open | The product/model inputs naturally differ between real Work and real Chat (`tpp` / Sol / xHigh versus ordinary Thinking / Extended). I am **not** claiming I have experimentally isolated which one field causes admission. I am asking OpenAI to identify that predicate. What is directly observed is the downstream execution split. #### Work chain The Work POST returned after only **~3.8407s** with: ```plaintext stream_handoff -> resume_sse_endpoint -> subscribe_ws_topic -> conversation-turn- ``` The browser subscribed to the exact target turn topic. The target-bound worker stream then contained: ```plaintext request_id: wfr_... async_source: saserver-... stream_topic_id: conversation-turn-... is_temporal_turn: true ``` and current server metadata classified the turn: ```plaintext plan_type: plus product_experience: work requested_model_experience: work temporal_conversation_turn: true ``` #### Same-Project ordinary Chat chain The ordinary-Chat control was classified: ```plaintext plan_type: plus product_experience: chat requested_model_experience: thinking temporal_conversation_turn: false model_slug: gpt-5-6-thinking request_id: UUID ``` Its original conversation POST stayed open for **~486.7s** through the foreground SSE response. There was no target turn handoff, no SAServer source and no `wfr_` worker execution identity. A second ordinary-Chat turn in the same Project repeats the non-Temporal class in another region/use case. * * * ## This is an execution identity transition, not merely a funny ID prefix The Work HAR has an ordinary HTTP transport `x-oai-request-id` for the initial POST. After server handoff, the target worker stream carries a **different `wfr_...` execution request ID** tied to the exact turn and SAServer source. Simplified: ```plaintext HTTP POST identity | | server issues stream_handoff v conversation-turn- topic | v wfr_ worker execution identity SAServer async source is_temporal_turn=true ``` The current ordinary-Chat control does not make that transition. It remains on the normal UUID/foreground path. That is why I am reporting an **execution/admission-class change** , not a cosmetic model-picker discrepancy. * * * ## Current Work proves the worker infrastructure was not removed account-wide The latest native backup of the current Work/Architect conversation contains **23/23 worker-family turns** using `wfr_` + SAServer. A naturally monitored xHigh Work turn also ended its initial HTTP request after ~4.875s, continued for 16m55s on a target per-turn stream, survived a brief browser network-route disturbance, and completed normally. So the account/backend still has access to the worker execution machinery today. Important limitation: none of those current Work turns naturally exceeded ~17 minutes. I am therefore **not claiming current Work has been proven to retain the historical 100-minute budget**. Worker architecture and maximum execution budget may be separate layers. * * * ## Repeated ~25–26m behavior and client-timer exclusion In addition to the persisted 26m04s control and 26m43s desktop specimen, three independent heavy ordinary-Chat missions terminated around 25–26 minutes and required manual continuation. Their exact original POST starts were not continuously captured, so I treat them as corroboration, not precision clocks. I also audited the current frontend bundle for an obvious total-turn deadline. The client contains the expected short SSE/WebSocket open/idle timeouts and retry logic (seconds to roughly one minute), but I found no total-turn lifetime constant near ~25–26 minutes in the inspected completion path. That does not prove no client bug exists anywhere. It makes a simple “JavaScript kills the turn after 25 minutes” explanation substantially less likely. * * * ## Independent Aug 20–22 public corroboration I am not using third-party reports to prove my route class. They are supporting context only. ### Independent 25m54s screenshot An Aug 22 ChatGPT Pro user publicly posted a screenshot of a long GPT-5.6 workflow whose UI visibly says: > **Worked for 25m 54s** Their surrounding report describes a three-day regression involving shortened High/Extra High Thinking, long workflows failing to complete, missing file/context claims and planning/verification commentary replacing requested execution. I cannot establish their backend route from the screenshot. The **25m54s** value is nevertheless strikingly close to my current **26m04s** native control and **26m43s** desktop specimen. ### Independent Aug 20-era onset reports Another Aug 22 thread begins with a user saying Thinking/High had stopped behaving normally “around 2 days ago,” with complex answers becoming nearly instant and shallower. A detailed Pro user reports the serious regression becoming noticeable around Aug 20 and reproducing in new chats and Safari as well as Chrome. ### Independent HAR/server-metadata routing reports Case **13542447** documents a same-account Business comparison where the same requested GPT-5.6 model resolved to GPT-5.5-mini in Chrome but to GPT-5.6 in Edge InPrivate only minutes later, with HARs and request IDs supplied to Support. A separate Aug 20 community report publicly quotes `server_ste_metadata` showing requested GPT-5.6 Thinking but a returned mini `model_slug`. Those are separate from my execution-admission issue. They establish that **backend treatment can differ from visible/requested state and can vary by session** , and they provide a precedent for asking Support to compare exact request IDs rather than repeating cache advice. * * * ## Best-supported causal model The model that currently fits the evidence best is: 1. A shorter ~25–26m foreground execution class already existed before Aug 20. 2. A longer worker/SAServer class also existed and was available to ordinary paid Chat. 3. Around Aug 20, this account’s ordinary Chat stopped receiving the worker family and began remaining on the shorter foreground class. 4. The worker infrastructure did not disappear from the account: current Work still receives it. 5. Therefore the regression is best localized to **ordinary-Chat admission/product treatment** , not universal infrastructure loss or a local browser timer. What remains unknown is the exact hidden predicate and intent. * * * ## What this evidence rules out or substantially weakens - **Mini fallback as the whole explanation:** clean genuine GPT-5.6 controls still show the regression. - **One bad conversation:** same conversation changes route; fresh conversations are also foreground. - **Project membership:** same Project has both Work/Temporal and Chat/non-Temporal. - **Desktop as a bypass:** current desktop ordinary Chat also hits ~26m. - **Region:** worker and foreground classes both appear across multiple regions. - **Local package update:** worker routing continues after the relevant package registration; no matching update was observed in the cutover window. - **WebSocket capability alone:** both current surfaces advertise resume/topic capability; only Work receives the target per-turn handoff. - **Simple browser/network failure:** current server metadata identifies different classes; desktop processes/TCP survive the boundary. - **A brand-new Aug 20 25m timer:** older public ~25–26m reports suggest that shorter class already existed. Not established: - current Work’s maximum runtime; - the exact server admission predicate; - whether the Aug 20 change was intentional; - commercial/upsell motive. * * * ## Questions I need OpenAI to answer 1. **Was ordinary paid Chat’s admission to this durable worker execution family intentionally changed around Aug 20, 2026?** 2. **Is `product_experience=chat` + `temporal_conversation_turn=false` now the expected class for long-running GPT-5.6 Thinking ordinary-Chat turns?** 3. **Is the observed ~25–27m execution class an intended practical boundary for current ordinary Chat, or a regression?** 4. **Why did historical ordinary Chat on this Plus account receive `wfr_` / SAServer / per-turn worker routing while current Work still receives that family and current Chat does not?** 5. **Can Engineering compare the supplied historical and current request IDs and identify any account/cohort treatment or admission-policy change in the Aug 20 08:17–09:16 UTC window?** 6. **Is there an internal Bug/Incident/Rollout ID associated with this behavior?** 7. **If account-specific, can the previous ordinary-Chat treatment be restored?** 8. **If intentional, where is the changed behavior documented for paying users?** 9. **What supported workaround restores long-running ordinary-Chat workflows without requiring migration into Work?** * * * ## Please do not close this with first-line browser troubleshooting I have already tested the relevant alternatives. - A clean browser profile removed the separate mini-model routing contamination, but not this execution-class regression. - Current genuine GPT-5.6 Thinking remains foreground/non-Temporal. - Desktop ordinary Chat independently reproduces the ~26m class. - The matched current HAR shows the class split in server metadata and transport behavior. If OpenAI cannot discuss proprietary implementation details, that is fine. I do **not** need a proprietary architecture explanation. I need an answer to the supportable product/engineering questions: - Is this behavior expected? - Did the supplied request IDs change admission/treatment? - Is there a known incident? - Can the affected ordinary-Chat route be restored? OpenAI’s own Support guidance asks users with persistent issues to collect HARs, timestamps, request IDs, model/environment information and conversation IDs. I have preserved all of those and can provide them privately. **Raw HARs, auth material, cookies, resume tokens and private conversation content will not be posted publicly.** Validated sanitized Aug-23 HAR transfer copies and full correlation IDs are available privately to OpenAI Support/Engineering if specifically requested; raw HARs are not transferable as-is. Support guidance: - [https://help.openai.com/en/articles/7996703-chatgpt-error-messages](https://help.openai.com/en/articles/7996703-chatgpt-error-messages) - [https://help.openai.com/en/articles/6614161-how-can-i-contact-support](https://help.openai.com/en/articles/6614161-how-can-i-contact-support) Relevant product context: - [https://help.openai.com/en/articles/6825453-chatgpt-release-notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * * * ## Bottom line This is no longer adequately described as “Thinking seems shorter.” > **Historical ordinary ChatGPT Plus on this account received the durable `wfr_` / SAServer worker family and one preserved turn ran 6,146 seconds. Around Aug 20, ordinary Chat changed to a UUID/non-Temporal foreground class. Current clean ordinary Chat still receives that class and heavy tasks repeatedly cluster near ~26 minutes. Current Work on the same Plus account still receives worker-family handoff. The account has therefore not lost the worker infrastructure; ordinary Chat has lost or changed admission to it.** @OpenAI_Support: please have the ChatGPT conversation-execution/admission team compare the supplied historical/current request IDs and confirm whether this is **expected, experimental, account-specific, or a regression**. ---
**Author:** ![Tri\_yell](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/tri_yell/32/448363_2.png) [@Tri\_yell](https://community.openai.com/u/Tri_yell)\ **Post date:** [August 23, 2026, 6:08am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/2 "2026-08-23T06:08:35Z")
Support you, this thread shall get more attetion! ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 23, 2026, 8:17am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/3 "2026-08-23T08:17:08Z")
Thanks. If you’ve experienced the same long-running Chat regression, any concrete details would help a lot: plan/model, approximate date it changed, previous vs current runtime, and whether large ordinary-Chat turns now stop around 25–26 minutes. Independent reproductions are especially useful here. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 23, 2026, 10:25am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/4 "2026-08-23T10:25:16Z")
Update Aug 23: I now have a second independent native ordinary-Chat GPT-5.6 Thinking/Extended specimen with `finished_duration_sec=1564` exactly. Its `/backend-api/conversation` HTTP/2 SSE request did not die at 26:04: it remained healthy for another ~60.9 seconds and completed normally with HTTP 200 at 27:08.4. The workload was objectively unfinished (1,075/1,200 mandatory verified pages). This substantially localizes the ~26m boundary to active foreground execution/reasoning rather than browser/SSE connection lifetime. A preserved current native corpus now contains foreground GPT-5.6/Extended durations of 1541, 1549, 1557, 1560, 1564 and a second independent 1564s specimen, all without `async_source`, per-turn topic, or Temporal worker markers. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 24, 2026, 7:12pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/5 "2026-08-24T19:12:53Z")
## Aug 24 update — near-simultaneous Chat vs Work control materially narrows the execution-routing issue @OpenAI_Support — I am resurfacing this thread because I now have a substantially stronger contemporary control. The new evidence is not another subjective report that “Thinking feels shorter.” I captured ordinary Chat and Work on the same paid account, using the same current client/server build identifiers, within the same few-second window. The two surfaces were then assigned observably different execution architectures. ### 1. Same account, same builds, near-simultaneous Chat vs Work execution Today I captured a fresh ordinary-Chat GPT-5.6 Thinking / Extended turn alongside two GPT-5.6 Sol / Max Work turns. All were on the same: - ChatGPT Plus account - client build: `9758774` - client version - server conversation build: `28a47ba41e80-convo` The ordinary-Chat request remained on its original foreground SSE for approximately **248.7 seconds**. It received no: - `stream_handoff` - target `conversation-turn-*` topic - `wfr_` worker execution identity - SAServer `async_source` Work behaved differently. Both Work turns were classified server-side with: - `product_experience=work` - `requested_model_experience=work` - `temporal_conversation_turn=true` Their initial conversation POSTs lasted only about four seconds before the server returned `stream_handoff`, an exact `conversation-turn-*` topic, and the turn proceeded with `wfr_` worker execution through SAServer. The first Work turn’s persisted native state independently confirms: - `resolved_model_slug=gpt-5.6-sol-wm` - `request_id=wfr_...` - `async_source=saserver-...` The timing is particularly useful: > The second Work request began approximately **1.54 seconds before the ordinary-Chat foreground SSE finished** , and that Work turn then received the Temporal / `wfr_` / SAServer worker route. So this is a near-simultaneous same-account control: **ordinary Chat:** original foreground SSE → no worker handoff **Work:** `temporal=true` → `stream_handoff` → `wfr_` → SAServer This substantially weakens explanations based on an account-wide loss of worker capability, generic Plus-account exhaustion, frontend/server build differences, or a long-lived global absence of the worker path. I am not claiming the exact hidden admission predicate has been isolated. Work and ordinary Chat naturally differ in product/model inputs. I am reporting the downstream execution split that the server actually assigned. ### 2. The separate mini-routing symptom changed; the execution-class split did not Earlier, one browser/session environment on this account requested GPT-5.6 Thinking while authoritative native metadata showed `resolved_model_slug=gpt-5-5-mini`. Today that same previously affected environment behaved very differently: - sustained reasoning/tool activity for several minutes - UI reported **Worked for 3m51s** - no `gpt-5-5-mini` marker anywhere in the captured HAR - repeated telemetry carried `model_slug=gpt-5-6-thinking` The HAR does not preserve authoritative `resolved_model_slug` for this particular turn, so I am **not** claiming final proof that the mini-routing defect is completely gone. But the previous instant/mini phenotype was absent. Despite that behavioral recovery, ordinary Chat still made **no worker transition**. This strengthens the interpretation that the mini-model routing problem and the long-running execution/admission regression are separable issues. ### 3. Independent 1554-second observation falls directly inside the native foreground cluster Another ChatGPT Pro user independently documented a failed long GPT-5.6 Sol workflow lasting approximately **25m54s = 1554 seconds** before the requested output was not actually delivered. My preserved native ordinary-Chat foreground corpus contains: - 1541s - 1549s - 1557s - 1560s - 1564s - 1564s Their independent **1554s** observation therefore lands directly inside this narrow cluster. I have cross-correlated the two reports in the active Community thread: > [@Why is GPT-5.6 Sol failing long-context workflows?](https://community.openai.com/t/why-is-gpt-5-6-sol-failing-long-context-workflows/1392062): > > 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… I cannot establish that user’s backend execution class from their public evidence, so I am **not** claiming that 1554s proves the same route. It is independent timing corroboration, not route proof. ### What remains unknown I am still **not** claiming: - that `product_experience` alone is the causal admission predicate - that a literal hard-coded `1536s` constant exists - that current Work has been proven to retain the historical \>100-minute budget - that the Aug 20 route change was intentional - that every current GPT-5.6 failure has the same cause Browser-local/client-side failures can clearly exist as separate problems. They do not explain the server-classified Chat-vs-Work execution split documented here. The new A/B establishes something narrower: > **Ordinary Chat and Work on the same paid account and same current build identifiers were assigned different execution architectures in a near-simultaneous control.** ### Engineering question Can OpenAI please classify this observed split? > **Is ordinary Chat currently expected to remain on the non-worker/foreground execution path while Work on the same paid account receives Temporal/SAServer worker admission, or is ordinary Chat failing admission to an execution class it previously received?** If the split is expected, please confirm that plainly. If it is not expected, please have the ChatGPT conversation-execution/admission team compare the preserved historical and current request/turn identifiers. I can provide the sanitized HARs and full correlation identifiers privately. I will not publish raw HARs, authentication material, resume tokens, or private conversation content publicly. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 25, 2026, 4:48pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/6 "2026-08-25T16:48:05Z")
## Aug 25 update: the question is no longer “is there a ~26-minute pattern?” @OpenAI_Support I am updating this thread because the evidence has moved well beyond one suspicious timer or a subjective “Thinking feels shorter” report. I now have: - a fresh Aug 25 native reproduction; - a historical/current native comparison on the same Plus account; - a near-simultaneous Chat-vs-Work control on the same current builds; - and independent users reporting the same hour-scale → ~25-minute collapse. The question is now much narrower: **Why did affected ordinary Chat lose the longer-running execution path it demonstrably received before?** * * * ## 1. Fresh Aug 25 native reproduction: 25m50s Today one of my genuine GPT-5.6 Thinking / Extended ordinary-Chat turns showed: **Worked for 25m 50s** I did not treat the UI timer as proof. Earlier in this investigation I found a misleading 46m18s visible turn that actually contained two backend request/exchange segments. Since then, I have bound long-looking turns to their native request objects before using their duration as evidence. This Aug 25 specimen is clean: - `finished_duration_sec = 1550` - actual reasoning elapsed: `1550.434s` - model: `gpt-5-6-thinking` - thinking effort: `extended` - one working turn - one request ID - one `turn_exchange_id` - no `async_source` - no per-turn stream topic - no Temporal marker - no `wfr_` worker request So this is not a multi-exchange UI-timer artifact. My current native genuine GPT-5.6 / Extended foreground-duration set is now: `1541, 1549, 1550, 1557, 1560, 1564, 1564 seconds` That is seven native turns across three conversations in a remarkably narrow range. Five of the seven are repeated turns in one conversation, so I am not presenting them as seven independent reproductions. * * * ## 2. The same account previously had a 102m26s ordinary-Chat turn The historical control is also native evidence, not a screenshot. ### Historical ordinary Chat - `6146s / 102m26s` - GPT-5.6 Thinking / Extended - one request/exchange - `wfr_` request - SAServer `async_source` - longer-running worker execution path ### Fresh Aug 25 ordinary Chat - `1550s / 25m50s` - GPT-5.6 Thinking / Extended - one request/exchange - no `wfr_` - no SAServer `async_source` - no equivalent worker/handoff markers So the comparison is: **Historical ordinary Chat: 102m26s, worker-routed** **Current ordinary Chat: 25m50s, foreground/non-worker** Same GPT-5.6 Thinking family. Same Extended reasoning effort. Single request/exchange on both sides. The duration ratio is approximately **3.97x**. I am not claiming that the route difference alone is proven to cause the entire runtime difference. I am saying it is now the strongest observable discriminator between preserved hour-scale ordinary Chat and the current ~25–26m execution class. * * * ## 3. The Aug 24 Chat-vs-Work A/B makes an account-wide explanation difficult On Aug 24 I captured ordinary Chat and Work on the same Plus account, using the same current client/server build identifiers, within the same few-second window. The ordinary-Chat request remained on its original foreground SSE execution path. A Work turn began **1.540 seconds before that Chat SSE had even closed**. The Work turn received: - `stream_handoff` - a `conversation-turn-*` topic - a `wfr_` request ID - SAServer execution - WebSocket continuation - `temporal_conversation_turn = true` So, during essentially the same moment on the same paid account: **ordinary Chat → foreground/non-worker execution** **Work → per-turn handoff/worker execution** This makes several simple explanations fit badly. The account was not globally unable to receive worker execution. Work received it while the ordinary-Chat turn was still active. The client/server build was not the differentiator in that A/B. And this is not dependent on the separate GPT-5.5-mini routing problem: today’s 1550s specimen genuinely resolved to GPT-5.6 Thinking / Extended. * * * ## 4. Independent users are reporting the same before/after runtime collapse I am treating the following as **timing corroboration only**. These reports do not prove that the users have my exact backend route. But the pattern is no longer confined to one account, one browser or one workload. ### Independent report #1: \>90–120m before, ~25m now In the Reddit thread **“Limited ChatGPT execution time”** , one user reports that their ChatGPT tasks previously ran: **well beyond 90 minutes, often 120 minutes** but recently began cutting out at around: **25 minutes** That is a direct same-user before/after comparison: hour-scale execution before, ~25-minute execution now. ### Independent report #2: 107m last week, now 25–26m repeatedly In the separate Reddit thread **“ChatGPT Plus Thinking limited to 25 minutes”** , another High user reports: - a **107-minute ordinary-Chat High run last week** ; - current stops consistently between **25 and 26 minutes** ; - roughly **10–15 occurrences across four different projects** ; - and failure wording indicating that the tool window ended before the requested work was complete. This is particularly useful because it is not one anomalous turn. The same user reports the new ~25–26m behavior repeatedly across several projects after previously receiving a 107-minute High turn. ### Independent report #3: Pro High at 25m56s, Extra High later lasts longer The same 25-minute discussion contains a ChatGPT Pro user reporting ordinary Chat: - **High: 25m56s, unfinished** - **Extra High: approximately 35m, also unfinished** I am **not** claiming that ~35 minutes is a universal Extra High limit. What makes this useful is that the observed execution boundary changes when the reasoning effort changes. That is difficult to reconcile with a generic browser timeout or a single fixed network lifetime. ### Independent report #4: two Plus accounts The original poster in that same GPT-5.6 High timing discussion reports testing **two separate Plus accounts** , with both newly reaching roughly the same ~25-minute maximum on substantial GPT-5.6 Sol High work. That does not prove a universal account policy. It does weaken an explanation based on one damaged account or one isolated conversation. ### Independent Work control The same discussion also contains a separate user reporting current Work runs of: - **33m57s** - **41m06s** - approximately **43m49s** That independently points in the same direction as my native Chat-vs-Work control: **ordinary Chat clustering near ~25–26m while Work can continue materially beyond that range** Again: these third-party reports are not backend-route proof. They are independent timing evidence. The important repeated pattern is: **hour-scale ordinary Chat before → ~25–26m ordinary Chat now** For reference, the two public Reddit discussions are: **Limited ChatGPT execution time** r/codex, thread ID `1vwwxo0` **ChatGPT Plus Thinking limited to 25 minutes** r/ChatGPT, thread ID `1vuns4u` * * * ## 5. Ordinary browser Chat historically used a per-turn handoff mechanism There is also independent technical evidence from March 2026, completely separate from my captures. A browser reverse-engineering report documented ordinary Chat with high/extended reasoning using a two-stage continuation flow: `/backend-api/f/conversation` then: `resume_conversation_token` then: `stream_handoff` then: `conversation-turn-*` then WebSocket continuation on that turn topic. The technical report is: **xtekky/gpt4free issue** #3404 **“[Bug] [OpenaiChat] extended thinking\_effort failed using API, however good on chrome browser within vnc”** I am **not** claiming that this external capture independently proves SAServer, `wfr_`, or Temporal execution. It does independently establish that ordinary browser Chat high/extended historically used a server-issued per-turn handoff/continuation architecture. That matters because current affected ordinary-Chat turns are not receiving that treatment. * * * ## 6. I tried to make the route/admission hypothesis fail I do not want to find evidence only for the explanation I already prefer. So I tried to make it fail. ### Browser/network timeout? Poor fit. In my strongest 1564s specimen, active reasoning stopped at 1564 seconds while the **same HTTP/2 SSE connection remained healthy for another ~60.9 seconds**. The connection later closed normally with HTTP 200. The required workload was still objectively unfinished. So the network connection itself did not die at the ~26-minute boundary. ### GPT-5.5-mini fallback? Not required. The fresh Aug 25 1550s specimen genuinely resolved to GPT-5.6 Thinking / Extended. The mini-routing problem is separate. ### Plus accounts simply cannot receive long-running execution anymore? Poor fit. Work received worker execution on the same Plus account while the ordinary-Chat request was still active. ### Client/server build difference? Poor fit for the Aug 24 A/B. Chat and Work were captured using the same current build identifiers within the same few-second window, yet were assigned observably different execution architectures. ### Did Aug 20 create a brand-new 26-minute timer? I no longer think that is the best explanation. Public ~25–26m examples existed before Aug 20. That means the strongest current model is not: **“OpenAI created a new 26-minute timer on Aug 20.”** A better fit is: **A shorter foreground/tool-execution class already existed.** **Ordinary Chat could also receive a longer-running handoff/worker execution class.** **Affected ordinary-Chat High traffic that previously received the longer-running class now appears to remain in the shorter class instead.** The exact admission predicate is still unknown. Product surface, model variant, reasoning effort, conversation mode and other fields co-vary between Chat and Work. I am therefore not claiming to know the exact server-side decision rule. * * * ## 7. The ~25–26m class itself appears to predate this regression There are older public reports of ChatGPT/tool workloads repeatedly landing around the same ~25–26-minute range. That suggests the short execution envelope itself is not necessarily new. What appears new for the affected cohort is the **loss of the hour-scale path**. This interpretation fits both sides of the evidence better: ### Before Some ordinary-Chat High/Extended turns received a server-issued handoff/continuation path and could run for well over an hour. My preserved native example: **102m26s** Independent users report historical examples around: **90m** **107m** **120m** ### Now Affected genuine GPT-5.6 High/Extended ordinary-Chat turns repeatedly remain in the shorter execution class. My native set: `1541, 1549, 1550, 1557, 1560, 1564, 1564 seconds` Independent current reports: **~25m** **25m56s** **25–26m repeatedly** This is why I am describing the issue as an **execution-routing/admission regression** , not simply “a new timer.” * * * ## 8. I looked for counterexamples too I specifically searched for fresh post-regression ordinary-Chat High single turns clearly exceeding 60 minutes. I did not find a clean one. That is **absence of found evidence, not proof that none exist**. I would actually welcome a valid current \>60m ordinary-Chat High specimen. If some users can still receive hour-scale ordinary-Chat High execution while others repeatedly land at ~25–26m, that would weaken a universal-cap theory but make a **conditional execution/admission regression** even more interesting. Useful details would be: - plan - model - reasoning effort - date - `Worked for` duration - whether the requested work completed - whether it was ordinary Chat rather than Work/Codex - ideally native metadata showing whether the visible duration spans one request/exchange or several A counterexample would be useful evidence, not something I am trying to argue away. * * * ## 9. I cannot find a documented ~25–26m High per-turn policy OpenAI’s current GPT-5.6 Help documentation still describes High as: **Extended reasoning** It documents reasoning usage allowances and fallback behavior. I cannot find a disclosed ~25–26 minute ordinary-Chat High/Extended per-turn execution ceiling. The Aug 20 Thinking-mode incident is also marked resolved. I am **not** claiming that incident caused this regression. The clean Aug 25 reproduction simply establishes that this behavior remains observable after that incident was declared recovered. If a ~25–26m High execution envelope is intentional product behavior, documenting that would resolve a major part of this report immediately. * * * ## 10. What is actually proven, and what remains unknown To keep this report falsifiable: ### Directly demonstrated on my account - ordinary Chat historically produced a **102m26s** GPT-5.6 Thinking / Extended single turn; - that historical turn carried worker/SAServer execution markers; - current genuine GPT-5.6 Thinking / Extended ordinary-Chat turns repeatedly cluster around **1541–1564s** ; - today’s fresh reproduction is **1550s / 25m50s** ; - the 1550s specimen is one request/exchange, not a combined UI timer; - the strongest 1564s specimen did not coincide with loss of its HTTP/SSE connection; - Work on the same Plus account still receives the per-turn handoff/worker execution architecture; - in the Aug 24 A/B, Work began while the ordinary-Chat SSE was still active. ### Strongly supported by independent public reports - other users previously received ordinary-Chat High execution in the **90–120m** range; - affected users now independently report **~25–26m** unfinished execution; - one user reports **107m before → 25–26m now** , repeated 10–15 times across four projects; - the behavior is reported on more than one Plus account and also by a Pro user; - current Work can still exceed the ~25–26m range. ### Not established - that every ChatGPT account is affected; - that ~25–26m is a universal hard cap; - that Aug 20 caused the regression; - that GPT-5.5-mini fallback causes this regression; - that one particular client field controls worker admission; - that Work and historical ordinary Chat use every identical backend component; - why the server is making the current execution-class decision; - whether the change is intentional. Those last two are exactly what I am asking OpenAI to clarify. * * * # The engineering question is now very narrow @OpenAI_Support I am not asking for speculative explanations. I am not asking you to disclose proprietary infrastructure. I am asking for a classification. ## **Q1: Is this expected behavior?** Is approximately **25–26 minutes** now an intentional per-turn execution envelope for ordinary Chat High/Extended on affected traffic? If yes: **Please confirm that and point to the documentation or effective date for the change.** ## Q2: If it is not expected, is affected ordinary Chat failing admission to the longer-running execution path? Why do current affected High/Extended turns no longer show the longer-running handoff/execution treatment that preserved historical ordinary Chat demonstrably received, while Work on the same account still does? ## Q3: Can Engineering correlate the preserved historical/current request IDs? I can provide privately: - exact historical/current request IDs - turn IDs - timestamps - validated sanitized Aug-23 HAR transfer copies - native conversation backups - client/server build identifiers - SHA-256 hashes of the preserved evidence Those artifacts should allow the relevant team to determine what execution treatment the historical and current turns actually received. I do not need internal implementation details posted publicly. I need one of two answers: **If ~25–26m is now expected ordinary-Chat High behavior, please say so and document the change.** **If it is not expected, please log/escalate the historical/current request IDs as a conversation-execution/admission regression.** That is the issue I am trying to get resolved. ---
**Author:** ![dragonfruit](https://avatars.discourse-cdn.com/v4/letter/d/b4bc9f/32.png) [@dragonfruit](https://community.openai.com/u/dragonfruit)\ **Post date:** [August 25, 2026, 11:43pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/7 "2026-08-25T23:43:50Z")
I agree with you. at this point we need to understand exactly what we are paying for. I also notice that ~100m dropped to ~25m, alongside a clear degradation in the 5.6 response quality. While quality is subjective to some extent, I believe anyone who has built their workflow around this and worked with it long enough will notice it as well. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 26, 2026, 10:13pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/8 "2026-08-26T22:13:26Z")
@OpenAI_Support — I’ve now opened a dedicated private Support case for the separate ordinary-Chat ~25–26m execution/admission regression: **Case #13832863**. The case contains the exact historical/current conversation timestamps, request/turn IDs and compact engineering correlation packet. The canonical top post’s historical metadata correction has already been applied; account-specific diagnostics remain private. Could you please track **Case #13832863** against this thread and help route it to the ChatGPT conversation-execution/admission owner? If anyone else independently sees the same broad change (previous hour-scale ordinary Chat, now repeated ~25–26m High/Extended turns), please report **your own** example through normal Support in your own words. If Support gives you a numeric Case Number and you’re comfortable correlating it publicly, posting only that number + plan + one-line symptom here is enough. Please keep conversation/request IDs, account details, HARs, cookies/auth material and private chat contents inside Support. The point is independent case correlation, not duplicate tickets or repeated tagging. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 27, 2026, 12:52pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/9 "2026-08-27T12:52:08Z")
@Prashant_Pardesi — I saw that you are correlating Support case IDs for the separate GPT-5.6 → GPT-5.5-mini downgrade. This report is a **different GPT-5.6 issue that persists on confirmed genuine GPT-5.6**. Ordinary Chat on my Plus account previously produced a **102m26s** Thinking/Extended turn; current genuine GPT-5.6 ordinary-Chat turns repeatedly end around **25–26m** , while Work still receives the longer-running handoff architecture. OpenAI Support **Case #13832863** has the exact native historical/current request and turn IDs. A second Plus user has now independently reported essentially the same before/after symptom: **\>102m before Aug 20 → 25–26m unfinished now:** > [@GPT-5.6 Sol Thinking on ChatGPT Plus forcibly stops at 25–26 minutes since Aug 20](https://community.openai.com/t/1392782): > > Before August 20, when I used GPT-5.6 Sol Thinking in ordinary Chat on the web client as a ChatGPT Plus subscriber, a single task could run for over 102 minutes. However, from August 20 until now, every Chat session is forcibly interrupted after only 25–26 minutes, cutting off the task that is still in progress. This has persisted for a full week. Work that could originally be completed in one go now has to be split into multiple runs. But splitting it up appears to make GPT’s memory problems … Could you please help correlate **Case #13832863** and route it to the ChatGPT conversation-execution/admission owner? I am **not claiming this is the same bug as the mini downgrade.** ---
**Author:** ![Slavax](https://avatars.discourse-cdn.com/v4/letter/s/3be4f8/32.png) [@Slavax](https://community.openai.com/u/Slavax)\ **Post date:** [August 27, 2026, 12:57pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/10 "2026-08-27T12:57:11Z")
Are you trying to circumvent usage limits in work and codex by using “unlimited” chat with 3000 messages a week? I mean say you get 25 minutes right so 3000 messages that’s like 1200 hours a week when a week only has 168 hours I just don’t see an issue if anything shorter window helps to break down to reconciliate and not forget and if anything get the prompt done in chat with multiple phases passes and hand it off to work/codex it’s so much better with a nice prompt you can get it working and it only stops if there is a genuine issue ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 27, 2026, 1:23pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/11 "2026-08-27T13:23:29Z")
No. This report is **not** an attempt to circumvent Work or Codex usage limits, and I have not bypassed or reset any Work/Codex limit. OpenAI’s current Help documentation treats these as separate product/usage surfaces: **Codex and ChatGPT Work share the agentic allowance/credit pool** , while **regular Chat usage is not included in the Work/Codex usage views**. See: [https://help.openai.com/en/articles/11369540](https://help.openai.com/en/articles/11369540) The question in this thread is narrower: ordinary Chat on this same paid account historically produced hour-scale GPT-5.6 Thinking/Extended turns, including a preserved **102m26s** turn, while current genuine GPT-5.6 ordinary-Chat turns repeatedly end around **25–26m** with unfinished work. In the Windows desktop control I explicitly selected **“Keep chatting here”** rather than moving the task into Work, precisely so the test remained an ordinary-Chat control. That was not a Work-limit bypass; it was a product-behavior comparison. If ~25–26m is now intentional ordinary-Chat behavior, OpenAI can simply classify and document that change. If it is not intentional, **Case #13832863** gives Support the exact historical/current request and turn IDs needed to investigate it. This thread is about regression classification, not quota evasion. ---
**Author:** ![Slavax](https://avatars.discourse-cdn.com/v4/letter/s/3be4f8/32.png) [@Slavax](https://community.openai.com/u/Slavax)\ **Post date:** [August 27, 2026, 1:38pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/12 "2026-08-27T13:38:05Z")
First of all rereading my initial reply I understand I could have sounded harsh and accusatory for which I apologize To answer your question it’s probably a hidden nerf which will not be documented as before nothing said it’s 100 minutes it’s just an adjustment at their discretion like they don’t tell you each time they change all parameters it’s just this 100 to 25 change is quite impactful Having said that you mention something you get offered to move to work I use chat quite a bit for research too and I never had this notification however I saw online people got it when they gave chat a very complex task instead of work ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 27, 2026, 2:01pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/13 "2026-08-27T14:01:24Z")
Thanks for clarifying, and I appreciate the apology. One thing that would actually help the evidence here: since you said you use ordinary Chat quite a bit for research, have you **personally** noticed individual Thinking/High runs ending around **25–26 minutes** recently, especially since around Aug 20? Even a rough “yes/no + longest before vs now” is useful; no need to manufacture a long test just for this thread. On the Work prompt: that happened in the **official Windows ChatGPT desktop app** , while I was deliberately staying in ordinary Chat. The workload that triggered the handoff suggestion was intentionally large and source-grounded: it required **1,200 unique public pages** to be opened/checked with a hard acceptance gate not to finish early. The app showed a **“Continue with Work?”** banner with the buttons **“Keep chatting here”** and **“Continue with Work.”** I chose “Keep chatting here” specifically to preserve the ordinary-Chat control. I do not have the banner’s dynamic explanatory sentence preserved verbatim, so I don’t want to invent a quote for why it triggered beyond the observable fact that it appeared on that large task. ---
**Author:** ![Slavax](https://avatars.discourse-cdn.com/v4/letter/s/3be4f8/32.png) [@Slavax](https://community.openai.com/u/Slavax)\ **Post date:** [August 27, 2026, 3:39pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/14 "2026-08-27T15:39:40Z")
Are you worried you pressed something and it affected your account? I think it did happen to me once I just type continue but yes it was messy not great durability it’s like cross chat transfer without proper hand off since then I mostly use work for implementation or deep analysis chat is mostly orchestrate analyze my needs prepare a prompt to send to work. Work I had once running I think for 40-50 minutes But yes I saw a few posts on reddit about 100 and 25 minutes but it doesn’t affect me so can’t share more unfortunately ---
**Author:** ![LL01344](https://avatars.discourse-cdn.com/v4/letter/l/e68b1a/32.png) [@LL01344](https://community.openai.com/u/LL01344)\ **Post date:** [August 27, 2026, 4:17pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/15 "2026-08-27T16:17:34Z")
I experience the same thing. While working in chat, the model is unable to work for more than 24~27 minutes. Here is an example for a chat in which it failed: > **[Check out this chat](https://chatgpt.com/share/6a8f7cf0-f340-83eb-b01b-5964a62d8b13)** > > Here's a chat someone thought you'd want to see. in the chat the following prompt was sent to GPT 5.6 Sol on High: “test and use the execution window for more than 30 minutes. do not stop until you reach 30 minutes, document problems\changes during those 30 minutes.” The model worked for 26 minutes and 24 seconds, after which: “the environment forcibly terminated tool interaction” causing it to stop working. It occurs in both the browser and apps(both in phone\tablet\ect.\ and desktop). Important to note that its only in chats, codex works fine. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 28, 2026, 7:32am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/16 "2026-08-28T07:32:03Z")
@LL01344 Thank you — this is an unusually useful independent reproduction, especially because your public shared conversation gives an objective \>30-minute acceptance gate and the turn stopped at 26m24s. If you are willing, an **independent Support case number would be especially useful** now. Please report your own experience through normal OpenAI Support in your own words and include the public shared-chat URL. If they give you a numeric Case Number, posting only that number here would let OpenAI correlate two separately affected accounts against my **Case #13832863**. Please keep any private request/turn IDs, account details or other non-public diagnostics inside Support. No need to rerun the 30-minute test just for this. ---
**Author:** ![Slavax](https://avatars.discourse-cdn.com/v4/letter/s/3be4f8/32.png) [@Slavax](https://community.openai.com/u/Slavax)\ **Post date:** [August 31, 2026, 12:41pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/17 "2026-08-31T12:41:53Z")
I came back to look at this again because I’d been seeing more issues in a Project and wanted to test it properly I ran two ordinary Chat tests asking it to keep using tools for 30+ minutes. Neither reached 30 The cleaner run stopped at about **25m39s** , then ChatGPT was told it had run out of time to interact with tools and had to return a response What stood out is that the workspace itself was still there. I was tracking the Python PID, container hostname, temp files and hashes, SQLite data and live Python variables. Same PID, same files and same state were still present when I continued in the next turn I also saw a separate runtime reset during testing where the PID and hostname changed and the local files and variables disappeared, so that looked like a different event So in this case the long-run stop didn’t look like the workspace dying. Tool execution stopped, but the workspace carried on into the next turn Hope this is useful for narrowing it down Full test chat / evidence > **[Check out this chat](https://chatgpt.com/share/6a957475-9054-83eb-b81d-120be32bdf1a)** > > Here's a chat someone thought you'd want to see. ---
**Author:** ![krasnik](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@krasnik](https://community.openai.com/u/krasnik)\ **Post date:** [August 31, 2026, 6:06pm UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/18 "2026-08-31T18:06:40Z")
@Slavax This is useful — thanks for testing it properly. The important distinction is exactly what you observed: the **~25m39s stop did not coincide with workspace death** , while your separate runtime-reset event did change PID/hostname and destroy local state. That helps separate the long-turn/tool-execution stop from sandbox/runtime lifetime. If you’re willing, please file this reproduction through normal OpenAI Support in your own words and include your public shared-chat URL. If they give you a numeric **Case Number** , posting only that number here would let OpenAI correlate your independently affected account with my **Case #13832863**. Please keep private request/turn IDs, account details, HARs or other non-public diagnostics inside Support. No need to rerun the 30-minute test again just for this thread. ---
**Author:** ![Paid5hTrial](https://avatars.discourse-cdn.com/v4/letter/p/4bbf92/32.png) [@Paid5hTrial](https://community.openai.com/u/Paid5hTrial)\ **Post date:** [September 7, 2026, 1:56am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/19 "2026-09-07T01:56:54Z")
i noticed the same, beforehand I was watching very long running tasks, another experiement is to press the retry button on a previous long runnning task that took 90. 100 or 110 minutes, and reliably see it canceling itself at minute 25. even some price searching like find me product x the absolute minimal price offer onlinem let it search the best offer for around 40 minutes which suprised me earlier, now its impossible. im paying plus subscription account to use thinking model, but the thinking time has been cut by 3/4 ! 70% nerved. runtime went down from 115m~ =\> 25-26 minutes The worst change of this undocumentated clear subscription degradtion is, the turn ends, even before the task or goal was finished, the model knows its not done but still returns an final\_response with mentioning X not done, next step to complete would be Y … thats stupid in a way, work not done, return unfinished tasks. not what I paid for. ---
**Author:** ![Paid5hTrial](https://avatars.discourse-cdn.com/v4/letter/p/4bbf92/32.png) [@Paid5hTrial](https://community.openai.com/u/Paid5hTrial)\ **Post date:** [September 7, 2026, 2:16am UTC](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943/20 "2026-09-07T02:16:45Z")
> [@LL01344](#): > > The model worked for 26 minutes and 24 seconds, after which: > “the environment forcibly terminated tool interaction” causing it to stop working. me too worked for 25m 53s the final response: couldn’t finish verification within Tool-Timeframe [Next page](https://community.openai.com/t/gpt-5-6-high-execution-regression-ordinary-chat-went-102m26s-repeated-25-26m-stops-on-same-plus-account-work-still-gets-long-run-handoff/1391943.md?page=2)