OpenAI 对巨型 ChatGPT 和 Codex 线程进行了基准测试，显示加载时间缩短了 16 倍

Why it matters

Agent products increasingly live inside long, tool-heavy threads. OpenAI's test suggests the desktop client can keep those histories usable without loading every transcript item at once.

Andrew Ambrosino (@ajambrosino), who leads OpenAI's Codex desktop app, has benchmarked a new approach to loading extremely large ChatGPT and Codex conversations, cutting the test thread's load time from 27.62 seconds to 1.66 seconds.

该测试使用了一个包含 741 轮、占用 231 MB 的对话。根据 Ambrosino 在 X 上的帖子，修订后的实现还使对话渲染器的 JavaScript 堆增长减少了 87.8%，整个应用的内存增长减少了 41.2%。

基准中标注的 “94% faster” 描述的是大约 94% 的耗时减少。若按速度倍数计算，该对话加载速度大约提升了 16.6 倍。

Dan (@DanDr1s) 在 8 月 15 日转发了这些结果，作为对长 ChatGPT 和 Codex 对话的改进说明。这里的数字描述的是客户端对话的加载和渲染，而不是模型推理速度、回答质量或 Codex 完成任务所需的时间。

Loading less of the transcript

另外两个测量结果揭示了性能提升的可能来源。请求次数从 894 降至 16，减少了 98.2%；而初始加载的抄本项数量从 15,529 降至 64，减少了 99.6%。

这些数字表明，修订后的客户端避免了之前一次性将巨量线程拉入应用的模式。只加载有界的抄本项会减少在用户可以与对话交互之前，网络层、JavaScript 运行时和渲染器需要执行的工作量。基准未展示旧消息在用户向后滚动时如何被检索，因此平滑的分页和稳定的滚动定位仍然是体验的核心。

这一点很重要，因为长对话可能在多个不同层面上出现故障。模型可能仍有足够的可用上下文来继续任务，而桌面界面却因渲染存储的抄本而停滞。减少被“水合”到客户端的项数量可以解决该界面瓶颈，而无需更改模型或缩减底层对话。

Long threads have become a product constraint

该基准回应了 OpenAI 桌面软件中一个有据可查的痛点。今年 7 月，一位用户在 OpenAI 的 Codex 仓库中报告称，尽管完整历史仍保存在本地且应用服务器继续返回抄本页面，但在一次更新后旧的轮次变得无法访问。报告指出了将分页历史合并到可见的虚拟化抄本中存在的问题。

另一则收集长会话失败的 Codex 问题描述了随着对话状态积累出现的冻结、内存增长以及对活动轮次失去控制的情况。这些都是用户提交的报告，但它们说明了为什么抄本加载已经成为代理软件的核心产品问题，而不仅仅是表面上的优化。

OpenAI 自身的使用数据提高了事态的严重性。在一篇 2026 年 6 月的研究文章，OpenAI 表示 5 月份超过 70% 的 Codex 用户要求代理执行需要人类超过一小时的工作。更长的任务会生成工具输出、中间推理记录、文件更改和反复的后续轮次，产生的历史远远大于典型的聊天机器人对话。

Ambrosino 的基准针对的是这种使用模式累积产生的成本。在一个 231 MB 的测试对话上实现 16.6 倍的改进，如果在不同硬件、操作系统和普通生产线程上都成立，将使重新打开和继续大型项目时的干扰大幅减少。在 OpenAI 将该工作附加到公开构建之前，这些数字仍然只是基准结果，而不是对当前 ChatGPT 和 Codex 用户的性能保证。