How to Choose a Model: Assigning the Right Model to a Task
📚 Series Navigation: The previous article [29 Slack / Linear and SDK Integrations] covered advanced setups to call Codex externally and embed it in products. This article returns to local environments, focusing on a daily decision—when you press enter, which model is running the task, and how much reasoning effort is assigned to it. The next article [31 Advanced Tips and Speed Optimization] covers how to make the entire workflow faster and more cost-effective.
People often say: "You can't go wrong choosing the strongest model," and I believed that for a long time.
For a while, I locked my default model to gpt-5.5 and set the reasoning effort to xhigh, thinking "it's resolved once and for all." Until one day, I asked it to change a variable name from data to payload—a thirty-second task. It "thought" for nearly a minute before editing the code. Watching the reasoning animation, I realized that "strongest" is not always smart.
Simply put, models are not always better when they are stronger; they are better when they fit the task. Using a flagship model with max reasoning for a typo fix is like using an excavator to weed a garden—slow, expensive, and unnecessary. Conversely, when refactoring a whole module, using a lightweight model to save time might result in a buggy codebase, costing you more time to fix than running it five times on a stronger model.
This article explains model selection: the active models in Codex, a key setting (reasoning effort) that is more effective than switching models, and a "task → model + effort" reference sheet I use daily. Reading it will make the /model panel clear.
By reading this article, you will get:
- A decision framework: matching task difficulty to compute resources without memorizing parameters
- The target scopes of active models in Codex, which one is the default, and which ones are legacy
- A key input setting that is often overlooked but highly effective—reasoning effort (reasoning effort)
- A reference sheet detailing which model and reasoning effort to assign to specific tasks
- Four ways to switch models: updating configuration defaults, specifying on startup, switching mid-session, or configuring for subagents
- A hands-on workflow to compare the output of the same prompt under different settings
⚠️ Model names and availability change with versions and subscription tiers (such as which is the active flagship, and what models your account can query). This article covers "how to evaluate and switch" methods; the models themselves are subject to what actually displays in your local
/modelpanel. CLI commands and settings follow the official Codex documentation (Models).
01 Understand First: Selecting Models is Not "Picking the Most Expensive One"
The bottom line: model selection involves matching task difficulty to compute resources—using too much is wasteful, and using too little risks bugs.
Many developers assume: "anyway, picking the strongest model guarantees success." The issue with this assumption: it ignores "wait time" and "token costs." In daily development, both factors matter:
- You run dozens of queries with Codex daily; waiting an extra thirty seconds per query adds up to half an hour wasted waiting for animations.
- Subscriptions have quotas, and API keys charge per token; flagship model token costs are several times higher than lightweight models.
Before choosing a model, evaluate three variables:
How complex is the task? How long can I wait? Do I care about token costs? Balancing these variables guides your choice.
| Situation | Direction |
|---|---|
| Complex tasks (architecture, cross-module refactoring, deep bugs) | Flagship model, high reasoning effort, prioritizing accuracy |
| Simple tasks (renaming variables, adding comments, minor functions) | Lightweight model, low reasoning effort, prioritizing speed and cost |
| Immediate responses (real-time pair programming, rapid chat) | Models optimized for quick responses, minimizing thinking time |
💡 Summary in one sentence: Model selection is not about choosing the strongest model; it is about matching compute resources to task difficulty.
02 Available Models in Codex
Opening the /model panel lists several models. Focus on their use cases rather than parameters.
Analogy: Assigning developers to tasks. For complex refactoring, assign the senior developer who thinks deeply (flagship); for minor edits, assign the fast intern (lightweight); for real-time pairing, assign the teammate with quick responses (real-time). Matching developer roles to tasks speeds up work.
The active models in Codex are grouped below:
| Model | Role | Best For | Speed / Cost |
|---|---|---|---|
gpt-5.5 | Flagship, Default | Complex coding, system operations, research workflows | Slower / Highest |
gpt-5.4-mini | Lightweight, cost-efficient | Simple coding tasks, subagent tasks | Fast / Low |
gpt-5.3-codex-spark | Instant (Research Preview) | Real-time high-frequency iterations (text-focused, limited coding) | Very Fast / Low |
Key settings to keep in mind:
- Defaults apply if unspecified. If you don't configure model defaults, Codex (App / CLI / IDE extensions) defaults to the recommended flagship model, which is sufficient for most tasks.
gpt-5.3-codex-sparkis a research preview (research preview) available only to ChatGPT Pro subscribers. It is normal if it does not display in your account.- Two legacy models you might see in older guides are deprecated:
gpt-5.2andgpt-5.3-codexare deprecated under ChatGPT login methods. Update them in your scripts,config.toml, orcodex exec --modelconfigurations. Deprecated models might still be queried via API keys, subject to the official API models directory.
My common configuration: running active sessions on the flagship model, and delegating batch tasks to subagents running gpt-5.4-mini. When cleaning up expired imports across twenty files last month, I asked the main agent to coordinate tasks and assigned mini models to subagents to write the changes. It finished in minutes—demonstrating the speed and cost efficiency of the mini model on simple tasks.
💡 Summary in one sentence: Focus on use cases: flagship for complex tasks, mini for speed and cost, spark for instant replies; and avoid deprecated model names in your configurations.
Model selection matrix:
Diagram: Plotting models along difficulty vs. speed/cost axes. Flagship
gpt-5.5handles complex tasks (bottom-right), while mini and spark models prioritize speed and cost (top-left).
03 The Key Variable: Reasoning Effort
Before switching models, inspect the reasoning effort (reasoning effort) configuration. It is often overlooked but has a direct impact on performance.
Analogy: Setting thinking time before a student answers. If you ask a student (the model) to answer immediately, vs. letting them draft notes, verify logic, and then answer, the output quality differs—though the latter takes longer. Reasoning effort configures how long the model evaluates options before outputting.
The five reasoning effort levels in Codex (for supported models in Responses API):
| Level | Meaning | Use Case |
|---|---|---|
minimal | Immediate response, minimal extra thinking | Very simple tasks, rapid chat |
low | Brief evaluation | Simple edits, fast iterations |
medium | Balanced speed and depth (common default) | Standard programming tasks |
high | Deep reasoning | Complex refactoring, deep bugs |
xhigh | Maximum reasoning (if supported by model) | Advanced architecture and debugging |
Notes: medium is the default starting level (varies with versions); xhigh is not supported by all models—verify availability in the /model panel; or refer to the official model documentation.
This explains the delay I faced when renaming variables—the model wasn't slow; I had set reasoning effort to xhigh, forcing it to evaluate options deeply for a trivial task. Conversely, when troubleshooting a race condition, standard levels failed; setting the effort to high allowed the model to trace the concurrent executions accurately.
If outputs are unsatisfactory, try raising the reasoning effort before switching models; if runs are slow, lower the setting. This adjustment is lightweight and effective.
💡 Summary in one sentence: Before switching models, adjust the reasoning effort—raise it if it misses details, and lower it if it runs slow.
04 Reference Sheet: Tasks, Models, and Effort Levels
Here is a reference sheet mapping common tasks to models and reasoning effort configurations:
| Task | Model | Reasoning Effort |
|---|---|---|
| Architectural design, tech selections | gpt-5.5 | high / xhigh |
| Cross-module refactoring, large rewrites | gpt-5.5 | high |
| Deep or concurrent bug debugging | gpt-5.5 | high |
| General feature coding and logic | gpt-5.5 | medium |
| Simple bugs, formatting edits, writing comments | gpt-5.4-mini | low |
| Subagents running simple batch edits | gpt-5.4-mini | low / medium |
| Real-time pairing, quick Q&A | gpt-5.3-codex-spark | minimal |
How to use the reference: default to the standard setup (flagship + medium) for daily tasks, and adjust when hitting specific cases:
- If suggestions miss edge cases → raise the effort to
high. - If running simple batch edits → switch to
gpt-5.4-miniat low effort. - If you need immediate replies without thinking pauses → switch to the instant model at
minimaleffort.
I keep the default configuration at flagship + medium for general tasks, and modify settings manually only when tackling complex bugs or running batch edits. Treat model settings as tools to select as needed, not settings to configure on every query.
💡 Summary in one sentence: Default to the flagship model at
mediumreasoning, and switch manually for complex debugging or batch operations.
05 Four Ways to Switch Models
Codex supports four ways to configure models, matching different scopes.
1. Setting the default model (Global). Define default keys in ~/.codex/config.toml to apply them to all sessions:
# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"2. Specifying on session startup. Use the -m / --model flags:
# Start a session with a specific model
codex -m gpt-5.5
# Applies to codex exec non-interactive mode
codex exec -m gpt-5.4-mini "Clean up expired imports in this file"3. Switching mid-session. Run the slash command to open the model selector:
/modelThe /model panel allows you to select both the model and the reasoning effort level.
4. Configuring for subagents. Keep the flagship model on the main thread, and assign the mini model to subagents for simple batch edits—optimizing speed and cost (details in Article 21 Subagents).
Comparing the methods:
| Method | Syntax | Scope | Use Case |
|---|---|---|---|
| Edit Default | Config key in config.toml | All future sessions | Setting your stable daily model |
| Start Flag | codex -m <model> | Active session only | Running a specific session on another model |
| Session Slash | /model command | Mid-session onwards | Switching models during a session |
| Subagent config | Defined in subagent settings | Selected subagent | Keeping the main agent on flagship, delegating to mini |
⚠️ Note: Cloud Task default models cannot be edited in configuration files currently, subject to official docs.
💡 Summary in one sentence: Configure defaults in
config.toml, specify on startup using-m, switch mid-session via/model, and assign mini models to subagents for batch operations.
06 Additional Configurations
Two settings to optimize display and priorities:
1. Reasoning summaries (model_reasoning_summary)—controlling how much thinking progress is displayed. Options are auto, concise, detailed, and none. Use detailed to review thinking steps, and none to disable progress outputs:
# ~/.codex/config.toml
model_reasoning_summary = "concise"2. Service tier (service_tier)—setting request priority. Options are flex (optimizes cost, may queuing) and fast (prioritizes speed). To enable fast execution, configure the tier and the corresponding feature flag:
# ~/.codex/config.toml
# Flex tier (Default)
service_tier = "flex"
# Fast tier: requires enabling the fast_mode feature flag
service_tier = "fast"
[features]
fast_mode = trueThese settings are optional; defaults are suitable for general use.
💡 Summary in one sentence: Reasoning summaries control thinking progress logs, while service tiers manage execution priority; defaults are suitable for daily tasks.
07 Hands-on: Comparing Reasoning Effort Levels
Let's walk through a hands-on comparison to verify model selection.
Step 1: Check available models
Enter a Codex session and run:
/modelExpected: The model selector displays the models available to your account. Note the active selection.
Step 2: Set defaults
Write these defaults to ~/.codex/config.toml (create the file if missing):
model = "gpt-5.5"
model_reasoning_effort = "medium"Restart the session and verify model selections in /model.
Step 3: Run the same prompt at different reasoning levels
We will pass this prompt: "Refactor this function to improve testability, and explain the tradeoffs."
- Run the prompt at
mediumeffort. Note the response time and the detail level of the output. - Set
model_reasoning_efforttohighin the config, restart the session, and run the same prompt.
Expected: The run at high effort takes longer but yields a more detailed response—considering more edge cases and detailing architectural tradeoffs. Testing this demonstrates the speed/depth balance.
💡 Summary in one sentence: Check models via
/model, configure default keys, and run a prompt at different reasoning levels to verify the speed/depth tradeoff.
Summary
We have explored model selection, covering:
- Model selection rule: match compute resources to task difficulty; do not default to the most expensive model.
- Active models: flagship
gpt-5.5for complex tasks, minigpt-5.4-minifor speed/cost, and sparkgpt-5.3-codex-sparkfor quick text replies; avoid deprecated ones. - Reasoning effort settings: raising it adds detail, lowering it saves time.
- Task mapping: use flagship +
mediumby default, and switch manually for complex debugging or simple batch tasks. - Switching methods: config defaults, CLI flags (
-m), slash commands (/model), and subagent configurations.
You should now be able to: identify active models, adjust reasoning effort, map tasks to model profiles, and switch settings mid-session.
The next article [31 Advanced Tips and Speed Optimization] moves to workflow optimizations: minimizing latency, reducing costs, and avoiding code iterations. Think about it: does latency come from model limits, or from cluttered context files that slow down the run? We address this in the next article.