This is separate from the old ~25–26 minute Chat/Thinking execution regression I have been tracking.
I am opening a new topic because the current failure has a different native signature and there is now enough evidence to treat it as its own reliability problem: typed additional safety review (BIO/CYBER), long review-time withholding/stalls, and inconsistent continuation after the review ends.
OpenAI’s current documentation says these additional automated checks can make a response take longer; if a response can be provided safely, it should continue after the check. The notice itself does not mean the user violated policy:
The delay alone is not what I am reporting.
Current native census
From a selected preserved forensic corpus on one account, deduplicated by conversation/turn/review event:
- 25 distinct turns contain native safety_review_update with active:true;
- 17 CYBER, 8 BIO;
- 14 materially failed or ended incomplete under a conservative rule;
- 11 reviewed controls eventually completed normally.
This is not an all-turn denominator or a claimed failure rate, and I am not claiming the review subsystem has been independently proven to be the sole cause of every failure.
The 11 successful reviewed controls matter. They show this is not simply “review = dead worker.”
What a healthy reviewed turn can look like
One completed BIO control stayed in review for about 967.7s (~16m08s). During review, the backend created 52 turn nodes including 25 tool outputs. Those nodes were withheld from the browser until review cleared, then the turn completed normally.
A separate completed CYBER control stayed in review for about 604.1s (~10m04s). It created 50 nodes including 26 tool outputs during review; again, delivery arrived after clear and the turn completed normally.
So additional review can create a very misleading UI stall while useful backend work survives.
That makes the failures below more concerning, not less.
Failure controls
A deliberately benign local numerical workload entered CYBER review. Productive work stopped, the worker heartbeat later expired, /conversation/resume first returned a live connection carrying only keepalives and later became unavailable, while client bookkeeping still reported IS_STREAMING. There was no clean terminal answer.
A separate research workload entered CYBER review, then remained heartbeat-alive but substantively stale for about 67m52s. Heartbeat eventually expired; recovery degraded from a 200 keepalive-only resume to a later 404 unavailable state, while IS_STREAMING persisted. Again, no clean terminal.
And the current GPT-6 Pro examples are worse for paid long-horizon work.
One Pro engineering turn entered CYBER review for about 11m43s and later cleared. Across that interval an implementation tool-result edge was missing; after clear, execution-state continuity broke and the turn ended incomplete.
The clearest current specimen is from 21 September:
- GPT-6 Pro performed useful ordinary userscript engineering first;
- native CYBER review activated;
- the turn preserved 653 worker heartbeats;
- review remained active for 3601.761s = ~60m01.8s;
- review then emitted active:false;
- instead of resuming the requested engineering cleanly, the turn returned an incomplete result almost immediately afterward.
A heartbeat is evidence of worker/topic lease liveness, not proof of continuous useful computation. The important point is that the turn was not simply gone for that hour: the platform explicitly marked it as being in additional review for that interval, and useful continuation was not restored afterward.
This is not explained by my recorder/browser environment
The review signal above is not inferred from UI appearance. It is a typed server-stream event observed by the recorder.
More importantly, the same account/browser/recorder environment has also captured clean long GPT-6 Pro controls, including:
- a 47m11s WestUS3 Pro release run that completed and produced a verified release certificate;
- a 55m50s DenmarkEast Pro code-review run that completed normally;
- reviewed turns that also recovered and completed normally.
So extension/browser presence is plainly not sufficient to produce either the failure or the review/recovery pattern.
A clean-browser control can still be useful for ruling out a secondary local contribution to post-review UI recovery. It cannot explain why the server emitted a native BIO/CYBER review event in the first place.
Why I think this deserves a separate reliability thread
The older ~25–26 minute problem was primarily an execution/runtime-envelope investigation.
This is different:
productive work → native safety review → review-time withholding/stall → clear or heartbeat loss → inconsistent tool/context/delivery recovery
For a paid Pro turn, a one-hour review followed by an incomplete answer is not merely “slower safety checking.” It can consume the scarce turn while also destroying the work the turn was supposed to finish.
I have already provided the private conversation/turn/request correlation data to OpenAI Support, and the case has been escalated to a specialist. I am keeping raw HAR/session material private because it contains authentication/session data.
I am not asking to bypass safeguards. I am asking for two reliability problems to be investigated:
- why ordinary/benign paid work is repeatedly entering BIO/CYBER additional review;
- why some reviewed durable workers do not regain usable tool/context/delivery continuity after the review clears.
If you already have an affected turn
Please do not deliberately trigger another review or burn paid quota for this thread.
If you already preserved a natural specimen, the useful privacy-safe fields are:
- plan + selected model + reasoning effort;
- exact additional-review notice;
- approximate review start/clear time if known;
- whether the turn eventually produced a normal complete answer;
- whether tool work appeared only after review clear;
- whether resume/connection errors appeared afterward.
Please do not post auth headers, cookies, full HARs, account IDs, private conversation IDs, or request tokens publicly.
I will keep this thread scoped to the additional-review reliability problem rather than mixing it back into the old 25–26m execution thread.