OpenAI benchmarks a 16x load-time gain for giant ChatGPT and Codex threads
A 741-turn, 231 MB thread loaded in 1.66 seconds in a test, with lower memory growth and 98% fewer requests.
By Ryan Merket · Published
Primary source: X
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.
The test used a 741-turn conversation occupying 231 MB. According to Ambrosino's post on X, the revised implementation also produced 87.8% less JavaScript heap growth in the conversation renderer and 41.2% less memory growth across the application.
The benchmark's "94% faster" label describes a roughly 94% reduction in elapsed time. Measured as a speed multiplier, the conversation loaded about 16.6 times as fast.
Dan (@DanDr1s) circulated the results on August 15th as an upgrade for long ChatGPT and Codex conversations. The numbers describe client-side conversation loading and rendering, rather than model inference speed, answer quality or the time required for Codex to complete a task.
Loading less of the transcript
Two other measurements expose the likely source of the gain. Requests fell from 894 to 16, a 98.2% reduction, while the number of transcript items initially loaded fell from 15,529 to 64, a 99.6% reduction.
Those figures indicate that the revised client is avoiding the previous pattern of pulling a giant thread into the application at once. Loading a bounded set of transcript items would reduce the work performed by the network layer, JavaScript runtime and renderer before the user can interact with the conversation. The benchmark does not show how older messages are retrieved when a user scrolls backward, so smooth pagination and stable scroll positioning remain central to the experience.
The distinction matters because a long conversation can fail at several separate layers. A model may still have enough usable context to continue the task while the desktop interface stalls under the weight of rendering the stored transcript. Reducing the number of items hydrated into the client attacks that interface bottleneck without changing the model or shrinking the underlying conversation.
Long threads have become a product constraint
The benchmark addresses a documented pain point in OpenAI's desktop software. In July, a user reported in OpenAI's Codex repository that older turns became inaccessible after an update even though the full histories remained stored locally and the app server continued returning transcript pages. The report pointed to trouble merging paginated history into the visible, virtualized transcript.
Another Codex issue collecting long-session failures described freezes, memory growth and lost control of active turns as conversation state accumulated. These are user-submitted reports, but they illustrate why transcript loading has become a core product problem for agent software rather than a cosmetic optimization.
OpenAI's own usage data raises the stakes. In a June 2026 research post, OpenAI said that more than 70% of Codex users in May asked the agent to perform work that would take a person over an hour. Longer tasks generate tool output, intermediate reasoning records, file changes and repeated follow-up turns, producing histories far larger than a typical chatbot exchange.
Ambrosino's benchmark targets the accumulated cost of that usage pattern. A 16.6x improvement on a 231 MB test conversation would make reopening and continuing large projects substantially less disruptive if the result holds across hardware, operating systems and ordinary production threads. Until OpenAI attaches the work to a public build, the figures remain benchmark results rather than a performance guarantee for current ChatGPT and Codex users.