Choosing an OpenAI Model: The Only Trade-Offs That Matter
The lineup changes every few months. The way you pick between them doesn't.
Every few months OpenAI's model list changes — new names, new numbers, a bigger one, a cheaper one, a faster one, one that reasons more and costs more. If you try to memorise the current lineup, your knowledge expires by the next release. What doesn't expire is the small set of trade-offs you're actually choosing between. Learn those and the menu stops being intimidating.
The three dials
Strip away the branding and almost every model decision comes down to three things in tension: capability, cost, and latency.
Capability is how good the model is at hard tasks — reasoning, nuance, following complicated instructions. Cost is what you pay per token, which at any real volume is the number that decides whether your product is viable. Latency is how long you wait for a response, which is what your users actually feel.
The uncomfortable part is that these pull against each other. The most capable model is usually the most expensive and the slowest. The cheapest, fastest model is usually the least capable. No model wins on all three, and any lineup — whatever it's called this quarter — is really just different points on that triangle.
How to actually choose
So the useful question is never "which model is best." It's "what does this specific task need."
Most tasks don't need the flagship. Classifying support tickets, extracting fields from text, simple rewrites, routing — a small, cheap, fast model handles these fine, and reaching for the biggest model is just setting money on fire at scale. Save the expensive, capable model for the work that genuinely needs it: multi-step reasoning, subtle judgment, the tasks where a cheaper model visibly falls short.
The pattern mature teams land on is a mix, not a favourite. Route the easy, high-volume work to a small model and escalate to a big one only when the task warrants it. You get most of the quality for a fraction of the cost, because most requests were never the hard kind.
The mistake to avoid
The common failure is defaulting to the newest, biggest model for everything because it's the one in the headlines. It'll work. It'll also cost several times more than necessary and respond slower, and you won't notice until the bill or the latency graph makes you. Starting from "what's the smallest model that's good enough here?" is almost always the right instinct.
Why the framing outlasts the models
By the time you read this, the specific model names will have moved on — that's just the nature of this field. But the decision underneath is stable. You are always trading capability against cost against speed, and the skill is matching the model to the job rather than reaching for the most impressive option on reflex. The menu keeps changing. The way you read it doesn't have to.
