ChatGPT 中实际观察到的日语通知，意思是“消息传送超时”，表示回答未能完整送达。首先应将它与“Too many requests”请求限制区分开。仅凭其中任一通知，都不能证明每周额度已用尽或设备已损坏。本文介绍手机、网页版和桌面版的检查方法，同时运行多个聊天时的注意事项，以及保留未完成工作后继续的方法。

实际观察到的日语通知：
メッセージの配信がタイムアウトしました。もう一度お試しください。
译意：消息传送超时。请重试。
此翻译不代表中文界面一定显示相同措辞。

先判断中断属于哪一类

传送超时

回答未能完整到达

检查连接、服务和对话状态。

请求限制

可能涉及提交过多或正在处理的请求过多

保存完整通知，暂停新提交和重试。

模型使用额度

界面说明额度或重置时间

查看具体模型的通知和剩余额度。

本文整理的排查框架。多个问题可能同时发生；单凭通知无法确定根本原因。

目录

超时与 Too many requests 的区别

超时通知能够确认的是传送没有完成。仅凭措辞，无法知道是生成停止、生成继续但接收失败，还是服务器或设备出现问题。即使已经看到部分回答，也不能保证恢复剩余内容。

OpenAI 官方 ChatGPT 错误排查指南将网络设置、浏览器扩展和临时服务器问题列为可能原因。不过，2026年10月12日查阅的正文并未针对上述传送超时确定根本原因或固定时间上限。

Too many requests

这一措辞指向请求数量过多。短时间内提交受到限制是其中一种可能。完整的错误消息、等待指示和网络错误代码有助于区分原因。

Too many concurrent requests

如果显示的确切消息是这一条，它指的是同时处理的请求过多。等待先前请求完成后再提交，是一种排查方法。

这些区别来自消息措辞。本次调查中，用户描述了类似“Too many requests”的通知，但没有完整文字，因此无法确定实际出现的是哪一条。查阅的官方资料也没有给出适用于所有 ChatGPT 用户的安全并行数量，或保证解除限制的等待时长。

不要把 API 429 与 ChatGPT 套餐额度混为一谈

OpenAI 的 API 错误文档区分了多种 HTTP 429 情况，包括请求速率限制以及余额或配额不足。除了 HTTP 状态，还要看响应中的错误代码。这是 API 文档，不能据此断定 ChatGPT 应用通知一定对应 429，或采用相同限制。

不要仅因看到类似“Too many requests”的提示，就认为必须购买额外额度。套餐和模型额度、短期提交限制、并行限制需要不同的处理方式。如果界面明确显示上限或重置时间，请记录下来。

回答中断后的检查与恢复步骤

先保留已有信息，不要删除对话或更改设置。下列顺序是本文基于官方通用排查建议整理的做法，并非针对这次特定超时的保证恢复流程。

先保护工作，再继续

  1. 保存：提示词、部分回答、完整错误消息和时间。
  2. 等待：暂停新提交，观察其他回答是否完成。
  3. 区分：检查服务事件、额度通知，以及对话或设备是否响应。
  4. 继续：说明未完成的部分，每次只重试一次。
反复点击重试之前，先检查哪些工作已经完成。

1. 保存部分回答和提示词

如果能看到回答，复制需要的部分。截取错误画面时，遮住私人信息和账户名称。无需一开始就删除对话、切换账户或重装应用。

研究任务中，要区分已核实的来源与尚未得到的结论。写作任务中，要区分已完成段落与未完成章节。如果涉及外部应用，即使回答中断，操作也可能已经执行。重复同一请求之前，检查发送、预订或发布的实际结果。

2. 多个聊天运行时，暂停新提交

如果多个对话正在处理，发送新请求之前先观察现有回答能否完成。遵循屏幕上的等待指示。不要假设另一个对话拥有独立限制，也不要认为反复重试能更早通过。

官方指南建议等待30–60秒，这是回答看起来卡住且无法完成时的初始步骤。这不意味着 Too many requests 一定会在该时间内解除。也不要把它变成固定时间后就停止正常推进中的长时间推理的规则。

3. 检查服务事件和模型额度通知

OpenAI Status展示涉及 ChatGPT 对话及所用功能的服务事件。应阅读受影响组件和发生时段，而不是只找“ChatGPT”一词。有些事件，例如账单报告延迟，并不影响对话。

没有列出服务事件，不代表设备一定有问题。状态页本身说明，整体可用性可能与不同套餐、模型和功能下的个体体验有差异。如果明确显示模型使用上限，应将其重置时间与服务事件分别检查。

4. 重试一次，必要时转移关键上下文

对于始终无法完成的生成，官方指南建议停止并重新生成，或在新聊天中再次发送。本例中，回答下方出现了重试按钮；先保留已有内容，再逐次尝试。也要检查其他正在运行的对话状态。

转到新聊天时，提供简短交接说明，包含目标、要求、已完成工作和剩余请求，不要假设全部历史记录会自动转移。无需复制整段保密对话。新聊天仍使用同一服务，因此不能保证解决请求限制或服务事件。

上一次回答中途停止。
目标：将研究结果整理成比较表。
已核实：下方粘贴的来源，以及已经完成的表格前半部分。
剩余：表格后半部分和选择方法的说明。
继续未完成的工作，不要重复已完成内容。
不要把未经核实的信息当作已核实。

并行运行多个聊天会发生什么

并行研究独立主题可以让等待时间重叠。不过，同时提交更多请求，也可能带来更多限制、失败和结果复核工作。一次启动所有请求，与减少工作总量是两回事。可以保留所有必要任务，同时错开启动时间。

需要检查的问题

  • 提交时出现限制通知。
  • 回答延迟或传送中断。
  • 显示或设备操作变慢。
  • 重试造成重复和返工。

缺乏证据时不可认定的说法

  • 推理投入随并行数量按比例下降。
  • 每个套餐都有已知的安全并行数量。
  • 超时意味着每周额度耗尽。
  • 增加设备就能解除服务器限制。

区分推理变弱与表面上的变慢

查阅的官方资料没有说明运行多个聊天会自动分摊每个回答的推理投入，也没有保证质量永远不会变化。比较质量时，需要保持模型、推理设置、提示词、对话上下文和额度状态一致。

OpenAI 关于模型和使用额度的说明指出，达到 Thinking 上限后，可能改用其他可用模型继续。如果并行工作时回答似乎不同，也要检查模型是否变化、是否出现额度通知。订阅 Pro 不会消除所有模型特定额度或限制。价格和额度可参阅ChatGPT Pro 套餐比较。

调整并行数量时，比较全部完成时间和失败率

不要自行设定固定安全数量，而应在同类工作中比较少量并行请求与目前的数量。除了首个字符出现的时间，还要测量全部回答完成的时间、失败次数及返工耗时。如果高并行时所有请求都正常完成，数量本身不是减少并行的理由。

为比较而反复重跑重要工作会消耗额度，也会增加结果差异。本文建议先记录日常工作的开始、结束和失败，仅在信息不足时考虑小规模受控比较。我们没有进行以触发限制为目的的负载测试。

排查手机、网页版和桌面版问题

不要假设换设备提交就有独立额度或限制。如果在电脑上查看由手机启动的多个任务，当前可见标签页数量并不反映全部活跃请求数。旋转指示器也不能保证服务器处理正常推进。

手机应用：记录完整错误、模型、开始时间和同时提交的请求数。关闭并重新打开应用前，保存未发送文字和部分回答。不要假设重启应用也会停止服务器端处理。

网页浏览器：区分回答缓慢与滚动、输入卡顿。设备负载、长对话、浏览器扩展和网络都可能影响。使用已获授权的其他现有环境查看同一对话，也有助于排查。

桌面应用：记录模型和应用版本。如果显示和输入也冻结，应同时调查应用；单凭传送超时不能确定内存不足或应用缺陷。

OpenAI 关于响应缓慢的指南建议关闭其他程序或标签页以释放设备资源。这可能改善界面响应，但不意味着设备 CPU 决定 AI 模型的推理能力。

在企业网络中，可能需要调查会中断长连接的设置。官方网络指南建议在连接建立后停滞时检查 WebSocket 超时和消息大小限制。这并不意味着每次超时都由 WebSocket 引起。

在含有保密信息的设备上，未经授权不要关闭防护功能或 VPN。官方指南列出了涉及扩展、VPN 和缓存的可能调整，但组织规则及所有者授权优先。先记录错误、检查服务事件并比较获准使用的环境。

已观察到的通知与类似用户报告

在2026年10月12日的调查中，AI Arte 通过用户提供的截图确认了上方引用的日语传送超时通知。对于另一次错误，用户说明它是在手机应用同时运行多个聊天后出现的。我们没有用实验比较回答质量，也未取得手机网络日志。

截图或用户报告能够确认的内容

完整传送超时通知，以及用户自述在高并行时出现另一条限制通知。

未取得的内容

另一条错误的完整文字、确切并行数量、发生时的模型和时间、HTTP 代码及根本原因。

该报告使与高并行相关的限制成为可能原因。但它并非固定设备、模型和并行数量的复现测试，不能证明普遍上限或因果关系。我们也没有根据屏幕上十来个旋转指示器推断内部活跃请求数。截图中的私人对话名称和内容不予公开。

作为一个外部具体例子，OpenAI Developer Community 用户 Krillo74 报告，长时间研究中连接中断后，重连返回404/410，并出现相同的英文传送超时消息。其诊断记录描述了在其他浏览器和新项目中的复现。可参阅报告及后续更新。

同一帖子10月7日的更新称，在该用户环境中已无法复现，但原因以及是否存在修复仍未确认。即使发表在官方站点的社区论坛，这仍是用户报告，并非 OpenAI 对原因的结论。它也不能证明本次截图有相同原因。应将其作为排查参考的类似案例，而不是推断所有会话都会在固定分钟数后停止，或该模型的所有用户都会遇到缺陷。

应记录什么并告知支持团队

要缩小原因范围，保留一次失败的具体条件，比同时更改许多设置更有用。无需包括输入聊天的保密信息。以下格式也适合手机备忘录。

日期和时间：包含时区
界面：手机应用／网页版／桌面版
模型和推理设置：界面显示的内容
完整错误文字：不要省略
并行数量：同时提交的请求数
失败阶段：提交后立即／推理中／回答中途
额度通知：是否出现及显示的重置时间
比较结果：其他对话是否完成，重试是否有用
网络代码和请求 ID：仅在已取得时记录

如果仅一个对话失败，检查其长度和内容。如果多个对话或设备在同一时段失败，可能涉及账户或服务端限制及服务事件。不过，共用同一连接的多台设备仍可能遭遇网络问题；设备数量本身不能确定原因。

对于跨浏览器、设备和网络仍持续的问题，官方指南建议向支持团队提供时间戳、模型、对话 URL 或 ID、浏览器错误，以及适用时的 HAR 文件。HAR 文件记录网络活动，可能包含凭据或对话内容。不要公开原始日志；先检查内容和接收方。

联系支持团队时，应区分“回答中途停止”“提交后立即受限”“其他对话已完成”，不要只说“经常很慢”。请参阅OpenAI 联系支持团队的说明，只发送调查所需信息。本文调查没有联系支持团队、更改设备设置，也没有大量提交请求测试限制。

总结：保存完整通知、并行数量和时间

传送超时表示回答未完整到达；Too many requests 通知提示可能存在请求限制。先保存部分回答，多个聊天活跃时暂停新提交，分别检查服务事件与模型额度通知。新聊天和重启是排查选项，并非保证有效的修复。

我们没有找到推理能力按并行聊天数量简单分摊的证据。实际使用中，应评估失败率、全部工作完成时间和模型变化。如果 Codex 显示“Selected model is at capacity”，这是另一类错误，请参阅Codex 容量错误的排查和处理。

常见问题

如果回答已完成却无法接收文件，请参阅ChatGPT ZIP 下载失败及实际观察到的日语操作失败通知。该指南区分生成链接过期、文件是否存在，以及交接 ZIP 内容的检查。

可以并行运行多少个聊天？

查阅的官方资料没有确定适用于所有 ChatGPT 用户的安全并行数量。保持模型、界面和工作类型一致，先记录日常完成时间及错误次数。某个用户成功运行的数量不代表所有人的上限。

升级 Pro 或额外购买能修复错误吗？

没有证据表明，更换套餐或额外购买能够解决这次传送超时，或那条缺少完整文字的限制通知。应区分明确显示的模型使用额度与连接或服务故障。

关闭手机应用能减少活跃请求吗？

我们没有确认关闭界面也会终止服务器端请求。如需停止处理，请寻找停止生成之类的操作。如果无法使用，记录状态，暂停额外提交，等待完成或限制相关指示。

等待几分钟能保证恢复？

没有确定的固定时间。遵循屏幕显示的等待时长或额度重置时间。官方30–60秒建议是回答看起来卡住时的初始步骤，并非解除请求限制所需的时间。