Models and Reasoning
Choose Codex models and reasoning levels by task risk, cost, and latency.
Key takeaways
- Model selection is an engineering tradeoff: the most capable model is not always the best default, and the fastest is not always safe for complex changes.
- Match posture to task: fast and lower reasoning for small edits, strong models with higher reasoning for shared architecture, and high reasoning plus human review for security or auth changes.
- Start most work with
gpt-5.5, keepgpt-5.4as the conservative fallback, usegpt-5.4-minifor lighter tasks, and treatgpt-5.3-codex-sparkas a research preview. - Drop deprecated
gpt-5.2andgpt-5.3-codexfrom new defaults, and keep Codex Cloud model policy separate since cloud tasks cannot change the default model. - Ask whether a wrong answer creates production, security, or customer risk; if so, escalate to a stronger model and a stricter review path.
Model selection is an engineering tradeoff. The most capable model is not always the best default for every subtask, and the fastest model is not always safe for complex changes.
Selection Matrix
| Task | Model posture |
|---|---|
| Small edits and formatting | Fast, lower reasoning |
| Read-only codebase questions | Fast or balanced |
| Shared architecture changes | Strong model, higher reasoning |
| Security or auth changes | Strong model, high reasoning, human review |
| Batch sidecar work | Cost-efficient model with clear scope |
Current Model Baseline
- Start most Codex work with
gpt-5.5; keepgpt-5.4as the conservative fallback. - Use
gpt-5.4-minifor lighter coding tasks and bounded subagents. - Treat
gpt-5.3-codex-sparkas a ChatGPT Pro research preview for fast text-only iteration. - Remove
gpt-5.2andgpt-5.3-codexfrom new ChatGPT sign-in defaults; they are deprecated in current Codex model guidance. - Codex cloud tasks currently do not let users change the default model, so keep Cloud model policy separate from local CLI/app/IDE policy.
- Since CLI 0.138.0, reasoning effort selection has fallback shortcuts and should follow the model-advertised effort order.
Operating Rules
- Set defaults by task category, not personal preference.
- Escalate reasoning for ambiguous or high-blast-radius changes.
- Require extra verification when using faster models for code edits.
- Track cost and latency when Codex is used in automation.
- Document fallback behavior when a preferred model is unavailable.
Review Question
Would a wrong answer here create production, security, or customer risk? If yes, use a stronger model and a stricter review path.