Codex Fast Mode gets marketed as a simple win — flip a switch, get faster responses. The reality, once you read how it actually works, is more interesting: it makes responses about 1.5x faster, but it costs 2 to 2.5x the credits, and it does not make the model smarter or the output better. Fast Mode is a time-for-money trade, not a free speedup and not a cost optimization. This article walks through what it changes, the numbers OpenAI's own documentation states, when to turn it on, and — the part most write-ups skip — what you give up.
What Fast Mode actually is
Fast Mode is OpenAI's acceleration feature for the Codex CLI. Under the hood it does exactly one thing: it sets the request's service_tier parameter to "priority". OpenAI's servers maintain separate scheduling queues, and priority-queue requests get scheduled earlier, so the first token arrives faster. A useful analogy from the source material: it is the airport fast lane. The security check is identical — you are just farther forward in the queue.
That mechanism explains the two behaviors that confuse most users:
- Why the speedup concentrates at the start. Once a request starts streaming output, it is already running, and the queue advantage is over. Long outputs gain little.
- Why unsupported models are silently ignored. Models without a priority queue have the setting dropped with no error. No error, no warning — just standard-mode handling.
The critical fact: fast and standard share the same models and the same rate limits. Fast Mode changes scheduling priority and nothing else. It does not change the model, it does not change sampling, and the output content is theoretically identical.
The measurements
The sources are unusually explicit about the numbers, so here they are exactly as stated.
Speed: roughly 1.5x for supported models.
Credit cost (ChatGPT login, credit mode):
| Model | Speed improvement | Credit multiplier |
|---|---|---|
| GPT-5.6 | ~1.5x | 2.5x |
| GPT-5.5 | ~1.5x | 2.5x |
| GPT-5.4 | ~1.5x | 2x |
So the honest framing is: roughly 1.5x speed at 2 to 2.5x the credit cost, depending on model.
There is a second billing path that changes the equation. Users who pay via API Key do not get the credit multipliers at all — Codex bills API tokens, and fast mode maps to OpenAI API's Priority-processing billing, usually about 2x the standard token price. Before deciding whether it is worth it, check which mode you are in with codex login status. Getting this wrong is how people underestimate the cost.
And the misconception the evaluation explicitly calls out: Fast Mode does not save tokens. It consumes more per unit of output. The "saves money" impression comes from finishing faster, but billing is by actual consumption — there is no token discount. If you treat fast mode as a cost-optimization tool, you will see your quota drain faster, not slower.
When to use fast mode
The recurring guidance across the sources is one rule: is the request blocking your thinking? If yes, fast mode is probably worth it. If it can run in the background, leave it on standard.
Use fast mode for:
- Interactive multi-turn debugging. Dozens of serial steps; every step's first token arrives faster, and the savings compound.
- Long agent loops. When Codex executes autonomously, requests fire one after another and latency accumulates — exactly the pattern priority scheduling fixes.
- Time-sensitive operations. Fixing a bug before launch, adding a feature before a demo. When time costs more than credits, spending 2x to buy a stable rhythm is worth it.
- Deadline code reviews. Waiting for results is expensive when a human is blocked on them.
Keep standard mode for:
- Batch or background tasks. Results are not urgent; fast mode just wastes credits.
- Long text or document generation. The speedup concentrates in the front of the response; the long output tail gains little.
- Credit-tight subscription tiers. At 2-2.5x consumption, quota can vanish in days.
- Reproducible batch runs. The output is the same; the extra spend buys nothing.
The recommended team default is "off by default, on demand": keep standard for daily batch and long-text work, manually /fast on for interactive stretches, set a mental cap (for example, no more than 30% of daily requests on fast), and treat urgent and non-urgent tasks differently rather than uniformly.
What fast mode gives up — honestly
The "gives up" list is where most coverage gets vague, so here it is concretely:
- It is not faster reasoning. The model is unchanged. The speedup is in queue wait and first-token latency, not token-generation throughput. If a task needs thousands of tokens, the tail of the output is not meaningfully faster.
- It is not cheaper. It is more expensive per unit of output — 2 to 2.5x credits, about 2x API-token price. It is a "pay more, wait less" switch, not a cost optimization.
- It is not a better model. No reasoning-depth gain, no quality change. Output is theoretically identical.
- It is not unlimited. Fast and standard share the same rate limits. Traffic spikes can still trigger tiered throttling.
- It is silently ignored on unsupported models. Only GPT-5.6, GPT-5.5, and GPT-5.4 are supported. Older models and third-party compatible models get the setting dropped without an error.
There is also a setup footgun: /fast on is only as durable as your config. If it does not seem to work, check (1) the model is in the supported list, (2) config.toml actually contains service_tier = "fast" and [features].fast_mode = true — older CLI versions may not write it back automatically, and (3) in verbose mode that the request header's service_tier is priority or fast, not default.
Setup and configuration
Toggle it in an interactive Codex CLI session:
/fast on # enable fast mode
/fast off # disable fast mode
/fast status # show current status
The setting persists to config.toml, so it survives restarts. To enable it permanently, edit ~/.codex/config.toml:
service_tier = "fast"
[features]
fast_mode = true
service_tier = "fast" is the part that marks requests for priority handling; fast_mode is the feature switch. Written this way, all supported-model requests default to the priority queue — more durable than toggling /fast each session.
One clarification the sources are careful about: /fast is not the same thing as Codex-Spark. Fast mode is an acceleration channel for the existing models (GPT-5.6/5.5/5.4). Codex-Spark is a separate, independent lightweight model with different mechanics and billing. Do not mix them up.
And one practical note for third-party tools that integrate Codex: many offer a similar fast switch, and the principle is the same — setting service_tier to priority/fast. But support scope and billing follow the specific tool's docs, so verify in the official CLI before trusting a third-party toggle.
The smarter pattern: route, don't blanket-enable
The deeper lesson from the sources is that the right workflow is not "fast everywhere" or "fast nowhere" — it is per-request routing. Interactive stretches go fast, batch processing stays standard, and low-priority work can be pushed to a cheaper model entirely. An API gateway in front of Codex does this cleanly: Codex sees one base URL, and the gateway decides which channel each request takes, so you tune speed and cost independently rather than paying the 2-2.5x tax on everything.
Conclusion
Codex Fast Mode is a simple switch with a clear accounting: about 1.5x response speed for the first token, paid for with 2 to 2.5x credit consumption (or roughly 2x API-token price). It does not change the model, does not improve quality, and does not save tokens — it buys shorter waits for the requests that are blocking you. Use it for interactive debugging and agent loops; keep it off for batch work, long generations, and tight quotas. And if you can, route requests by urgency instead of flipping the switch globally. That is the difference between using fast mode and being used by it.
Top comments (0)