GPT-5.6 长任务执行能力疑似退化，耗时从 102 分钟降至 26 分钟

同一个 Plus 账号，始终使用 gpt-5-6-thinking 和 extended 模式，过去可以持续执行 100 多分钟的长任务，如今运行到 26 分钟左右便会被强制中断。问题看起来并不在于模型本身变笨，更可能是底层路由逻辑发生了变化，将后台异步任务放进了前台同步模式。

102 分钟与 26 分钟的执行差异

历史案例中，请求 ID 以 wfr_ 开头，异步源标识为 saserver-...:conversation-turn-...:EU，实际执行耗时达到 6146 秒，也就是 102 分钟 26 秒。这并非孤立现象，其他几个保存的对话里，worker-family 轮次分布在不同的欧洲区域，单次执行时长分别达到 2609 秒、2314 秒和 5094 秒。

如今采用相同配置再次测试，模型仍然是 gpt-5-6-thinking，但请求 ID 已经变成普通 UUID，也不再带有 SAServer 异步源标识。任务往往运行不到 26 分钟就会中断，finished_duration 大致停在这个水平。

同一对话中的路由身份发生变化

以一个特定对话序列为例，按照 UTC 时间记录：

• 07:41 - 08:14：所有 turn 都采用 wfr_ 加 SAServer 标识，属于能够长时间运行的异步 worker 模式。
• 08:17:44：最后一个确认的 worker 任务结束。
• 09:15:58：同一对话中的下一个 turn 启动，模型依然是 gpt-5-6-thinking，但请求 ID 变为普通 UUID，也不再带有 SAServer 标识。

切换点可以锁定在 2026 年 8 月 20 日的 08:17 到 09:15 之间。同一个对话内从后台异步切换为前台同步，很难归因于旧对话损坏或模型降级。

当前运行状态

• 普通 Chat 模式：已经变成非 Temporal/Foreground 模式，执行上限约为 26 分钟。
• Work 模式：同一账号下仍可正常接收 worker handoff，保留了长任务执行能力。

如果这是产品功能调整，为什么 Work 模式仍能维持长任务能力，普通 Chat 模式却受到限制？目前可能是灰度测试、账号处理问题，也可能是长任务执行逻辑出现了严重退化。

运行复杂长任务时，可以留意请求 ID 是以 wfr_ 开头，还是普通 UUID。后者代表任务处于“前台模式”，达到超时限制后连接会直接中断，即使模型尚未完成思考。