Codex: Chat-to-Work and the Costly Fast Mode
CodexChatGPT WorkFast Mode
What exactly changed in Codex
For me, the bigger shift is not Fast Mode but the ability to move from a regular chat into Work without losing the thread of the conversation. Official ChatGPT Work and Codex documentation describes a top-level Chat or Work switch, plus the option to start a new chat or open an existing project. In practice, that is chat-to-work: a discussion becomes a task with working context.
In Work, you can use project context, open local folders, and keep refining the request in the same chat. It is a small interface change, but architecturally it removes an awkward break between defining an idea and having an agent work with files and constraints. There is less manual context transfer and less chance of losing an important caveat.
As of publication on August 23, 2026, ChatGPT Work and Codex use a shared pool of limits, pricing, and credits. Fast Mode delivers roughly a 1.5x speed increase but consumes more credits: the current documentation summary lists a 2x multiplier for GPT-5.4 and 2.5x for GPT-5.5 and GPT-5.6. The documentation also lists the commands /fast on, /fast off, and /fast status, with configuration available through config.toml.
A community signal illustrates the subjective side of that math. One user said they spent 15% of a 20x plan quota in one day using Fast, then about 10% over two days in normal mode; another report mentioned quota resets. This is neither a controlled test nor an official measurement, so I treat it only as a warning that the extra consumption can be noticeable.
Speed runs into quota economics
Fast Mode makes sense only when response latency genuinely blocks the work. With an advertised speed gain of around 1.5x and consumption of 2x or 2.5x, speed rises more slowly than quota use. For long agentic tasks, that can be an expensive trade-off, especially when time is spent on tools, files, and checks rather than generation.
I would first watch two metrics: quota spent per completed task and total time to a usable result. If Fast only reveals intermediate steps sooner but does not shorten the full cycle, spending twice as many credits or more is difficult to justify. The model matters too, since the multiplier depends on it.
Chat-to-Work looks like the more fundamental improvement. It preserves context between conversation and execution, whereas Fast Mode mainly buys lower latency from the shared limit. The conclusion is straightforward: the smoother handoff remains useful, while Fast Mode must repeatedly prove its value on real tasks.