Codex: Chat-to-Work y el caro Fast Mode
CodexChatGPT WorkFast Mode
Qué cambió exactamente en Codex
Para mí, el cambio principal no es Fast Mode, sino pasar de un chat normal a Work sin perder el hilo de la conversación. La documentación oficial de ChatGPT Work y Codex describe un selector superior entre Chat y Work, además de la opción de iniciar un chat nuevo o abrir un proyecto existente. En la práctica, eso es chat-to-work: una conversación se convierte en una tarea con contexto de trabajo.
En Work se puede utilizar el contexto del proyecto, abrir carpetas locales y seguir afinando la petición dentro del mismo chat. Parece un cambio menor de interfaz, pero a nivel arquitectónico elimina una ruptura incómoda entre formular una idea y poner a un agente a trabajar con archivos y restricciones. Hay menos transferencia manual de contexto y menos posibilidades de perder una condición importante.
A la fecha de publicación, el 23 de agosto de 2026, ChatGPT Work y Codex utilizan un fondo compartido de límites, precios y créditos. Fast Mode ofrece una aceleración aproximada de 1,5 veces, pero consume más créditos: el resumen actual de la documentación indica un multiplicador de 2× para GPT-5.4 y de 2,5× para GPT-5.5 y GPT-5.6. La documentación también menciona los comandos /fast on, /fast off y /fast status; la configuración está disponible en config.toml.
Una señal de la comunidad muestra bien el lado subjetivo de estas cifras. Un usuario afirmó haber gastado en un día el 15% de la cuota de un plan 20x usando Fast, y después alrededor del 10% durante dos días en el modo normal; otro comentario mencionó reinicios de cuota. No es una prueba controlada ni una medición oficial, así que solo lo tomo como advertencia de que el gasto adicional puede notarse.
La velocidad choca con la economía de la cuota
Fast Mode solo tiene sentido cuando la latencia de respuesta realmente bloquea el trabajo. Con una mejora anunciada de alrededor de 1,5 veces y un consumo de 2 o 2,5 veces, la velocidad crece menos que el uso de cuota. En tareas largas con agentes, puede ser un intercambio caro, sobre todo si el tiempo se va en herramientas, archivos y verificaciones, no en generación.
Yo miraría primero dos métricas: cuota consumida por tarea terminada y tiempo total hasta obtener un resultado utilizable. Si Fast solo muestra antes los pasos intermedios, pero no acorta el ciclo completo, resulta difícil justificar un consumo doble o superior. El modelo también importa, porque el multiplicador depende de él.
Chat-to-Work parece una mejora más fundamental. Conserva el contexto entre conversación y ejecución, mientras que Fast Mode compra principalmente menos latencia a costa del límite compartido. La conclusión es simple: la transición fluida seguirá siendo útil, pero Fast tendrá que demostrar su valor una y otra vez en tareas reales.