Picking a model is a real cost/quality decision every time we use Codex. For simple tasks, many of us use more premium capability than needed; for difficult debugging or multi-file work, choosing too light a model can mean retries and lost time.
I opened a GitHub feature request for a built-in Smart model-picker option and optional /smart command:
https://github.com/openai/codex/issues/43868
The idea is that Codex would choose the appropriate model and reasoning level from task signals such as scope, ambiguity, and expected tool use—without consuming a separate user turn. It should also provide an explanation of its choice and keep an easy override plus a user-set cost/capability ceiling.
Would this help your workflow? If so, I’d love concrete examples of when you currently hesitate between models, or when the wrong choice cost you time or usage. Those examples will make the GitHub request more useful than a generic +1.
Could this operate like an TCP connection? A new connection begins at a low speed and increases if the channel supports a higher bandwidth. Could a less-capable model be tried first? Would it be cost effective to try progressive more advanced models? Could the task be segmented so that only a representative sub-task need be attempted until the threshold least-advanced/least-expensive model is identified? Is this even realistic, or am I hallucinating? Thanks @ashermenachem !
Not hallucinating — TCP slow start is a useful analogy. A Smart router could make an initial prediction from the prompt, repository, and task signals, then escalate only when confidence is low or early work shows that it is needed.
I would avoid running the whole task twice, since that can erase the savings. A better version could use the least-capable model for triage, planning, or a small representative probe, then continue or escalate with the context preserved. For a clear, small edit, the first choice should usually be enough; the probe is more valuable for long, ambiguous, agentic tasks.
The safeguards matter: a user-set cost/latency ceiling, a brief explanation of the route, and an easy override. And because Codex has the best view of the task and model availability, this seems more realistic as a built-in product feature than as an external tool. Thanks — this is exactly the kind of routing behavior I had in mind.