GPT-5.5 Is Now the Codex Default Recommendation. The Real Question Is When Not to Use It.
OpenAI’s Codex model guidance now has a simple recommendation: for most tasks, start with gpt-5.5. That is good advice for an individual staring at a hard problem. It is incomplete advice for a team paying for a fleet of agents.
The refreshed Codex models page positions gpt-5.5 as OpenAI’s newest frontier model for complex coding, computer use, knowledge work, and research workflows in Codex. The CLI invocation is not subtle: codex -m gpt-5.5. OpenAI says GPT-5.5 is available in Codex through ChatGPT sign-in or API-key authentication, and that it is strongest for complex coding, computer use, knowledge work, and research workflows. It also says gpt-5.4-mini is the faster, lower-cost option for lighter coding tasks and subagents, while gpt-5.3-codex-spark is a text-only research preview for near-instant coding iteration for ChatGPT Pro users.
The useful question is not whether GPT-5.5 is the strongest default. It probably is. The useful question is when not to use it. That is where engineering organizations will either turn Codex into leverage or into another mysterious line item with a dashboard nobody checks until the bill gets weird.
“Best model” is not a routing policy
There are tasks where the frontier model earns its keep. A multi-file refactor across an unfamiliar codebase. A production bug with partial logs, ambiguous ownership, and subtle state transitions. A computer-use workflow that needs to inspect a UI, reason about backend behavior, and produce a coherent fix. A security-sensitive change where a wrong answer is expensive. If the human equivalent is “pull in the senior engineer who knows the system,” using GPT-5.5 is defensible.
But a large percentage of coding-agent work is not that. Teams use agents for lint cleanup, README updates, fixture generation, dependency bumps, test renames, small migrations, branch hygiene, issue triage, type fixes, local explanation, and “make this error message less embarrassing.” Those tasks need speed, determinism, and narrow context more than frontier reasoning. OpenAI’s own docs identify gpt-5.4-mini as the better fit for lighter coding tasks and subagents. That sentence should be copied directly into team policy.
Subagents are the easy place to waste money because they make work feel cheap. A primary agent delegates five narrow jobs, each job pulls context, each context produces output, and suddenly the team has used a premium model to do what a cheaper model could have done with a smaller prompt. This is the agentic version of scaling every background worker to the largest instance class because the first request felt important.
OpenAI’s pricing page adds the other half of the story. It says GPT-5.5 usage averages 5–45 credits per message, and its token-based credit rate is 125 credits per million input tokens, 12.50 credits per million cached input tokens, and 750 credits per million output tokens. GPT-5.4-mini is listed at 18.75 credits per million input tokens, 1.875 credits per million cached input tokens, and 113 credits per million output tokens. The exact economics will vary by plan and workflow, but the shape is hard to miss: output is expensive, smaller models matter, and cached input only helps when the workflow actually benefits from caching.
Deprecation is an operations problem wearing a docs note
The models page also says Chat Completions API support in Codex is deprecated and will be removed in future releases. Codex can still point at models and providers that support either Chat Completions or Responses APIs, but the direction is Responses. It also says gpt-5.2 and gpt-5.3-codex are deprecated in Codex when signing in with ChatGPT, and that scripts, config files, and codex exec --model references should be updated.
That is not housekeeping. Model strings become infrastructure once they appear in wrappers, CI jobs, runbooks, internal tools, project config, agent launchers, and Slack commands. A deprecated model does not fail only at the command line. It fails in the automation path nobody has touched since the demo became a workflow.
The immediate action is boring and necessary: search for model references across repos. Look for codex exec --model, codex -m, model = in config, hard-coded model names in scripts, and internal docs that tell developers which model to use. Update what needs updating, but do not simply replace every old model with GPT-5.5. Use the migration as the moment to define routing.
A sane team policy might look like this: GPT-5.5 for architecture, deep debugging, security-sensitive changes, complex refactors, and high-ambiguity work. GPT-5.4-mini for narrow edits, subagents, formatting, docs, test scaffolding, and mechanical changes. Spark-style low-latency models for interactive iteration where the cost of waiting exceeds the cost of occasional shallowness. API-key authentication for automation that needs explicit token accounting. Cloud tasks only where the inability to change the default model is acceptable.
The governance layer decides whether this scales
The individual developer experience wants one answer: “what model should I pick?” The organizational problem needs several answers: what model is the default, who can override it, which tasks justify escalation, how much context is allowed, where usage is logged, and what happens when a team exceeds its budget. Without those answers, “start with GPT-5.5” becomes “everything starts with GPT-5.5,” which is not strategy. It is gravity.
Teams should log model choice per task, not just total spend. Cost without task class is trivia. If GPT-5.5 is being used mostly for dependency bumps and snapshot updates, the routing policy is failing. If mini-model sessions get frequently escalated because they miss important context, the task classification or prompts need work. If output tokens dominate the bill, teams should inspect whether agents are writing sprawling explanations where short diffs would do.
There is also a product-design lesson here for agent tools. Model selectors are necessary, but they are not enough. The useful interface is a policy-aware router that asks: how risky is this change, how broad is the codebase context, is this a subagent, is network access needed, will tests run, and what is the budget class? Developers should still be able to override, but the default should encode the team’s operating judgment rather than the vendor’s marketing hierarchy.
OpenAI is right that GPT-5.5 should be the starting point for serious Codex work. The mistake would be treating “serious” as synonymous with “everything that touches code.” Engineering is mostly deciding where to spend scarce attention. Agentic engineering adds a second scarce resource: expensive reasoning. Spend it like you mean it.
Sources: OpenAI Developers — Models in Codex, OpenAI Developers — Codex pricing, OpenAI Developers — Codex configuration reference, GitHub Docs — Models and pricing for GitHub Copilot, GitHub Changelog — Copilot billing and plans