OpenAI reporta una mejora de 16x en los tiempos de carga para hilos gigantes de ChatGPT y Codex

Un hilo de 741 turnos y 231 MB se cargó en 1.66 segundos en una prueba, con menor crecimiento de memoria y 98% menos solicitudes.

By · 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.

Illustration of OpenAI's ChatGPT and Codex giant conversation threads racing through a digital network to show a 16x faster load of a 741-turn, 231 MB thread

Andrew Ambrosino (@ajambrosino), who leads OpenAI's Codex desktop app, ha medido con una prueba comparativa un nuevo enfoque para cargar conversaciones extremadamente largas de ChatGPT y Codex, reduciendo el tiempo de carga del hilo de prueba de 27.62 segundos a 1.66 segundos.

La prueba usó una conversación de 741 turnos que ocupa 231 MB. Según la publicación de Ambrosino en X, la implementación revisada también produjo un 87.8% menos de crecimiento del heap de JavaScript en el renderizador de la conversación y un 41.2% menos de aumento de memoria en toda la aplicación.

La etiqueta "94% más rápido" de la prueba comparativa describe una reducción aproximada del 94% en el tiempo transcurrido. Medido como un multiplicador de velocidad, la conversación se cargó alrededor de 16.6 veces más rápido.

Dan (@DanDr1s) difundió los resultados el 15 de agosto como una mejora para conversaciones largas de ChatGPT y Codex. Los números describen la carga y renderizado de conversaciones en el lado del cliente, en lugar de la velocidad de inferencia del modelo, la calidad de las respuestas o el tiempo que Codex tarda en completar una tarea.

Resultados de la prueba comparativa para cargar una conversación de OpenAI de 741 turnos
La prueba midió tiempo de carga, crecimiento de memoria, solicitudes de red y elementos de la transcripción para una conversación de 231 MB.

Cargar menos de la transcripción

Dos mediciones adicionales exponen la probable fuente de la mejora. Las solicitudes cayeron de 894 a 16, una reducción del 98.2%, mientras que el número de elementos de la transcripción cargados inicialmente cayó de 15,529 a 64, una reducción del 99.6%.

Esas cifras indican que el cliente revisado evita el patrón anterior de cargar un hilo gigante en la aplicación de una sola vez. Cargar un conjunto limitado de elementos de la transcripción reduciría el trabajo realizado por la capa de red, el runtime de JavaScript y el renderizador antes de que el usuario pueda interactuar con la conversación. La prueba comparativa no muestra cómo se recuperan los mensajes más antiguos cuando un usuario desplaza hacia atrás, por lo que la paginación fluida y el posicionamiento estable del desplazamiento siguen siendo centrales para la experiencia.

La distinción importa porque una conversación larga puede fallar en varias capas separadas. Un modelo puede seguir teniendo suficiente contexto utilizable para continuar la tarea mientras la interfaz de escritorio se queda bloqueada bajo el peso de renderizar la transcripción almacenada. Reducir la cantidad de elementos hidratados en el cliente ataca ese cuello de botella de la interfaz sin cambiar el modelo ni reducir la conversación subyacente.

Los hilos largos se han convertido en una limitación del producto

La prueba comparativa aborda un punto doloroso documentado en el software de escritorio de OpenAI. En julio, un usuario reportó en el repositorio de Codex de OpenAI que los turnos más antiguos se volvieron inaccesibles después de una actualización, aunque los historiales completos seguían almacenados localmente y el servidor de la app seguía devolviendo páginas de la transcripción. El informe señaló problemas al combinar el historial paginado en la transcripción visible y virtualizada.

Otro reporte en Codex que recopila fallas en sesiones largas (Codex issue collecting long-session failures) describió congelamientos, crecimiento de memoria y pérdida de control de turnos activos a medida que se acumulaba el estado de la conversación. Estos son reportes enviados por usuarios, pero ilustran por qué la carga de transcripciones se ha convertido en un problema central de producto para el software agente en lugar de una optimización cosmética.

Los propios datos de uso de OpenAI aumentan la apuesta. En una publicación de investigación de junio de 2026, OpenAI dijo que más del 70% de los usuarios de Codex en mayo pidieron al agente realizar trabajo que le tomaría a una persona más de una hora. Las tareas más largas generan salida de herramientas, registros intermedios de razonamiento, cambios en archivos y turnos de seguimiento repetidos, produciendo historiales mucho más grandes que un intercambio típico con un chatbot.

La prueba comparativa de Ambrosino apunta al costo acumulado de ese patrón de uso. Una mejora de 16.6x en una conversación de prueba de 231 MB haría que reabrir y continuar proyectos grandes sea sustancialmente menos disruptivo si el resultado se mantiene en distintos hardware, sistemas operativos y hilos de producción ordinarios. Hasta que OpenAI incorpore el trabajo a una compilación pública, las cifras permanecen como resultados de prueba comparativa y no como una garantía de rendimiento para los usuarios actuales de ChatGPT y Codex.

Reader comments

Conversation for this story loads after sign-in.