Why Codex CLI Defaults to the General Model

Every model comparison on this site eventually circles back to one fact that still surprises people the first time they hear it stated plainly: the Codex CLI does not default to the model named for Codex. It defaults to the general frontier model. The Codex-branded model — built and documented as "optimized for agentic coding tasks in Codex or similar environments" — is something you have to reach for deliberately, with /model or a config change. Nobody stumbles into using it by accident, which is a strange thing to be true of the model whose entire stated purpose is this exact tool.

The naming does real work against you

Names carry information, and "the CLI named Codex defaults to the model named Codex" is such a natural inference that it barely feels like an inference at all — it feels like a fact you already know before you've checked anything. That's precisely what makes this worth writing about: the wrong belief isn't the product of carelessness, it's the product of a reasonable prior that happens to be false. Nothing about the CLI's first-run experience actively corrects it either. You install, you run, you get an answer, and unless you go looking at the startup banner or run /status, there's no moment where the assumption gets tested.

What OpenAI actually shipped, and why it's a defensible choice

Reading the underlying decision charitably: the unsuffixed model name is documented as an alias for the frontier model, described as "roughly corresponding to the unsuffixed model tier used in earlier GPT-5 families." That's a naming convention with its own internal logic — the plain, unqualified name goes to the general-purpose flagship, and named variants (Codex, Cyber, Pro, and so on) are specialized departures from that baseline. Within that logic, defaulting the CLI to the flagship model rather than a specialized one is entirely consistent. The confusion isn't that OpenAI made an indefensible choice; it's that the CLI's own name creates an expectation the naming convention it actually follows doesn't support.

Why this would matter less if the two models were closer substitutes

If the frontier model and the Codex-branded model differed only trivially — a few percentage points of price, near-identical windows — this would be a footnote, not a headline comparison. They don't. Context window differs by a wide margin. Price differs by more than half, in both directions on input and output. Knowledge cutoff differs by several months. And reasoning-effort control, a genuinely useful dial for tuning how much computation goes into a given answer, is published for exactly one of the two — the Codex-branded model, not the default. These are the kind of differences that change how you'd actually budget and plan a workload, not differences you can shrug off as immaterial.

The one axis that doesn't move

It's worth being precise about what doesn't change between the two, because it's the detail that makes this a genuinely interesting tradeoff rather than a simple "one is strictly better" story: both models sit in the identical published rate-limit group. Switching from the default to the Codex-branded model costs nothing in requests-per-minute or tokens-per-minute. If the two differed in throughput too, the decision would collapse into an obvious "pick whichever is faster for your budget." Because they don't, the decision stays genuinely three-dimensional — cost against context headroom against recency — with speed held constant.

Why nobody else has written this down plainly

No single page on OpenAI's own documentation puts these two models side by side and states the tradeoff. That's not a criticism of the documentation — a vendor's reference pages are organized around each model on its own terms, not around cross-model decision-making for a specific tool's default behavior. But it leaves a real gap: a developer choosing between these two has to open two separate pages, read both pricing tables, both context-window figures, both cutoff dates, and do the comparison themselves. Doing that comparison once, carefully, sourced from the same primary pages, and publishing the result is exactly the kind of thing an independent site can do that the vendor's own documentation structurally doesn't.

The cliff that makes this more than an academic comparison

There's a further wrinkle that raises the stakes on getting this right: the default model publishes the long-context repricing rule — cross a certain input-token threshold and the entire request reprices, not just the excess. The Codex-branded model's own page doesn't state that rule either way. For a workload that leans on the default specifically because of its larger window, understanding where that threshold actually sits is part of understanding what that larger window is actually worth in practice; a window you can't approach without a repricing penalty isn't quite the unqualified advantage the raw number suggests.

A pattern worth watching for beyond this one case

Once you've internalized that a tool's default doesn't necessarily match its most on-the-nose-named option, it's worth extending that skepticism generally rather than treating this as a one-time correction. Naming conventions across a fast-moving product lineup are optimized for internal consistency and technical accuracy, not for setting the expectations of someone encountering a single tool in isolation for the first time. The specific mismatch here — a coding CLI defaulting away from its own namesake model — is memorable precisely because it's counterintuitive, but the underlying lesson is more general: verify a default rather than infer it from a name, a marketing description, or what would make the most narratively satisfying story.

Why this site treats the comparison as its flagship page

Every other page on this site computes something — a price, a break-even, a context-window budget. This particular comparison earns its place as the most-read page for a different reason: it's the one piece of information that changes how a reader should even approach every other calculator here. Before you can meaningfully use the token-cost estimator or the context-window planner, you need to know which model you're actually planning against, and for a large fraction of Codex CLI users, the honest answer to "which model am I using" is not the one their intuition would supply. Correcting that one assumption is worth more, in practical terms, than any single computed number this site publishes.

What actually follows from all this

None of this is an argument that the CLI's default is wrong, or that everyone should switch to the Codex-branded model. It's an argument that the choice deserves to be made deliberately rather than inherited by accident from a name that happens to point the wrong way. Check which model your session is actually running. Understand what you're trading if you switch. And treat the CLI's default the way you'd treat any other tool's default setting — a reasonable starting point, not a verdict on what your specific task actually needs.