Revert #19053: Fast service tier should not be the default
Problem
#19053 makes Codex's Fast service tier the default for eligible ChatGPT plans (enterprise and business-like) when no explicit service_tier is set. Users who want standard routing have to either set service_tier explicitly or persist a new [notice].fast_default_opt_out = true marker.
This inverts the prior contract: service_tier used to flow directly from config.service_tier — what the user configured was what got sent. After #19053, core silently resolves an unset config to Fast based on plan eligibility.
Why this should be reverted
- Opt-out instead of opt-in for a routing/cost-relevant behavior. Fast tier has different performance, availability, and (for some callers) billing characteristics. Changing routing based on plan detection, without the user asking for it, is the kind of implicit behavior change that should at minimum be opt-in.
- New persisted config surface (
[notice].fast_default_opt_out) exists only to undo the new default. That's a strong signal the default itself is wrong — if users need a durable marker to say "no, really, use standard," the managed default is fighting them. service_tier: nullnow means "explicit standard" rather than "unset." This overloads the absence of a value with intent, which is hard to reason about and breaks the natural reading of the config.- TUI/status surfaces now diverge between
config.service_tier(what's configured) and the "effective" service tier (what core resolved). Two sources of truth for the same concept is a maintenance hazard.
Proposed fix
Revert #19053. If Fast-by-default for enterprise plans is still desired, reintroduce it as an opt-in — e.g., a [notice].fast_default_opt_in flag, a first-run prompt, or a plan-scoped config default that's visible in config.service_tier rather than resolved behind it.
A clean revert is already prepared on a fork:
https://github.com/nwparker/codex/tree/revert-19053-fast-default-enterprise
Happy to open a PR if a maintainer wants to move forward.
---
Made with Orca 🐋
7 Comments
Thanks for the feedback. This was an intended change, not a bug.
You can opt out of fast mode if you'd like.
@etraut-openai
Before today, you said I could use /fast to turn off fast mode. So I turned it off.
After the latest Codex CLI update, my previous Fast mode opt-out state was lost.
So it is intended to revert user's manually settings after software update?
The reason is already described above I think.
The update removed the old service_tier state but did not add [notice] fast_default_opt_out = true. As a result, with both service_tier and fast_default_opt_out absent, Codex started defaulting to Fast mode.
This is morally wrong. Really gross behavior here.
IANAL but this sounds illegal. You activate an expensive feature, the user did NOT order without even informing him.
To clarify, this default specifically applies to business and enterprise subscriptions, not plus and pro. The decision was based on feedback from business and enterprise subscribers; they generally want to optimize for employee productivity.
@etraut-openai - We this as a way to unnecessarily burn tokens. Most of our employees' workflow involves multitasking where we don't need immediate response. We install this on remote servers using the codex extension in VSCode and it always defaults to fast mode. If this is truly about giving business / enterprise subscriptions a choice then at least give us owners of business accounts a way to change the "default" setting back to normal speed.
look, just give us a simple switch that does not get overwritten and everyone will be happy, it will stay the no brainer default. but i would much rather have my own organisation have it disabled. o personally forget half the time about it and get angry when i see i have 0 usage remaining. im doing complex stuff, it takes tokens and im okay with wait. just honor user's customisation at least.