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 🐋