GPT-5.6 High execution regression: ordinary Chat went 102m26s -> repeated ~25–26m stops on same Plus account; Work still gets long-run handoff

ChatGPT Bugs
, , , ,
1

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:

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:

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:

stream_handoff
  -> resume_sse_endpoint
  -> subscribe_ws_topic
  -> conversation-turn-<exact turn>

The browser subscribed to the exact target turn topic. The target-bound worker stream then contained:

request_id: wfr_...
async_source: saserver-...
stream_topic_id: conversation-turn-...
is_temporal_turn: true

and current server metadata classified the turn:

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:

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:

HTTP POST identity
       |
       | server issues stream_handoff
       v
conversation-turn-<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:

Relevant product context:

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.

2

Support you, this thread shall get more attetion!

3

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.

4

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.

5

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:

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.

6

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.

7

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.

8

@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.

9

@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:

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.

10

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

11

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

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.

12

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

13

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.

14

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

15

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:

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.

16

@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.