Choosing between Codex models on real work

The axis that matters

Model names and version numbers change often enough that memorising them is wasted effort. The axis underneath does not change. On one end you have faster, cheaper models that answer well when the task is local and the context is small. On the other you have slower, more expensive ones that reason for longer and keep a multi-step plan coherent across many tool calls.

Most teams pick one, put it in a config file, and never revisit it. That is where the money goes, and where the frustration comes from too.

Match the Codex model to the shape of the task

A rough split that has held up across the teams we work with:

• Rename, reformat, add a test to an existing suite, write a commit message: the fast model, every time
• Explain unfamiliar code, summarise a diff, answer a question about the repo: fast model, and the answer is usually as good
• Debug something with a non-obvious cause across several files: the stronger model, because the cheap one guesses
• Design a change that touches a boundary you care about: stronger model, and read the plan before approving anything
• Long refactors with many mechanical steps: fast model, but check for silently skipped cases

The tell that you are on the wrong model is repetition. If the agent tries the same fix twice with small variations, it has lost the thread. Stop, switch up, and restate the problem rather than paying for a third attempt.

Reasoning effort is a second dial

Alongside model choice, Codex lets you ask for more or less deliberation before it acts. Higher effort costs latency and tokens and buys you fewer wrong turns on genuinely hard problems. On simple tasks it buys nothing and you wait for it.

Treat the two dials together. A strong model at low effort and a fast model at high effort are different tools, and neither is a substitute for stating the problem clearly. No model setting rescues an instruction like "fix the login bug" with no reproduction.

What the choice will not fix

Model selection does not fix missing repo context. If the agent does not know your conventions, a larger model will violate them more fluently. Write the instruction file first. We have watched teams spend weeks A/B testing models when their real problem was that nothing in the repo told the agent which directory owned database access.

Try this

Take five tasks you did this week with the agent. Rerun two of them on the cheaper model and two on the stronger one. Time them and read the diffs. You will usually find that most of your work belongs on the fast model and that one category, probably debugging, does not. Encode that split as a team habit and move on.

If you want help putting this into practice, talk to us.