Model Picker

Every model comparison page on this site answers "how do these two differ." This tool answers a different question — "which one should I actually use" — by walking through what your task actually needs rather than asking you to already know which axes matter.

Why a picker instead of another table

A spec table is the right tool once you already know which two or three models are in contention. It's a poor tool for the more common starting position: staring at the whole priced lineup and not knowing which handful are even worth comparing closely. This picker exists for that earlier moment — a short set of questions about your actual task, translated into a shortlist, rather than a wall of numbers you have to cross-reference yourself.

The questions that actually move the answer

How large is the context your task needs to hold — a single file, a whole repository, a long multi-turn agentic session? That alone rules out the smaller-window models for anything genuinely large, before price even enters the conversation. Does the task benefit from very recent training data, or is it working against stable, well-established APIs and libraries where recency barely matters? That's the axis most people underweight, and it's a real, publishable difference between model generations, not a vague "newer is better" instinct. Is this latency-sensitive, cost-sensitive, or throughput-sensitive — because those pull toward different tiers and sometimes different models entirely, and a task can only really optimize hard for one of them at a time. And does the task need a particular reasoning-effort setting — none for speed, or max for depth — which not every model accepts?

How the recommendation is built

Nothing here is a hidden scoring formula you have to trust blindly — the picker filters the published model roster against your answers in a visible, checkable way: a context-window requirement removes anything smaller, a recency requirement removes anything with an older knowledge cutoff, and a reasoning-effort requirement keeps only models whose own page lists the level you need — none if you want reasoning switched off for speed, max if you want the deepest setting. (This filter used to narrow to the single model this site believed published effort levels at all; every current model does, so it now filters on the levels themselves.) What's left after filtering is your shortlist, usually a handful of models, not a single forced answer — because for most real tasks, more than one model is a defensible choice, and the honest output of a filtering process is a shortlist, not a false certainty.

Why the CLI's own default isn't the automatic answer

The Codex CLI ships with a specific default model already selected, and it's a reasonable one for a lot of work — but "what the CLI does if you don't choose" and "what your specific task actually needs" are two different questions, and this site's whole premise is that no one page states the tradeoff between them plainly. If your answers point toward a different model than the CLI's default, that's not the tool disagreeing with OpenAI — it's your task's actual shape pointing somewhere specific, which is exactly the kind of judgment a generic default can't make for you.

What this tool won't tell you

It won't tell you which model produces better code for your specific codebase — that's a quality judgment this site has no reliable, sourced way to make, and any claim to the contrary would be exactly the kind of unverifiable assertion this site refuses to publish. What it will tell you, honestly and from published specs alone, is which models are even structurally suited to your task's context size, recency needs and cost profile — narrowing the full lineup down to the few worth actually trying is most of the real work, and the quality call from there is yours to make with real output in front of you.

Revisiting your answer

Model lineups change — a new release, a repriced tier, a context window that grows on a future generation. Answers you get here are a snapshot against the currently published roster, and it's worth re-running the picker after any release this site's own weekly fact-check catches, rather than assuming a shortlist from months ago is still the right one.

A note on the models that don't answer at all

Some entries in the roster are never shortlisted. The Daybreak cyber models carry published prices but need separate approval before anyone can call them, so recommending one to a reader who can't run it would be useless. GPT-5.4 Cyber was never priced and has been removed from the API. The picker excludes all of them rather than guessing at where they'd land — a recommendation built on a model you can't use, or on an unpublished figure, isn't a recommendation, and this site draws a hard line against shipping those.