Ask five developers which OpenAI model they use and you’ll get five answers, most of them defensive. One swears by GPT-4o mini because it’s cheap enough to run on every keystroke. Another insists the reasoning models saved a project that had been stuck for weeks. A third is still on an older snapshot because migrating means re-running an eval suite nobody has time to build.
All three are right. The OpenAI model catalogue isn’t a ladder where the top rung is best — it’s a set of trade-offs between thinking depth, speed, price, and how much text you can shove in at once. Getting the pick right is mostly about knowing which of those you can afford to lose.
The families, without the marketing gloss
Broadly, the lineup splits into general-purpose chat models (the GPT-4o and GPT-4.1 lines), smaller variants built for volume, and the o-series reasoning models. Names, versions, and snapshots shift constantly — the state of the OpenAI lineup in 2025 is a decent map of where things currently sit, and it’s worth re-checking every few months rather than memorising today’s SKUs.
The general models answer fast and handle most work: drafting, summarising, extracting fields from messy emails, classifying support tickets. The small variants (4o mini, 4.1 nano) do the same jobs at a fraction of the price with a fraction of the nuance. Reasoning models think before they answer, which is either transformative or a waste of money depending entirely on what you’re asking.
What a reasoning model actually buys you
When you send a prompt to an o-series model, it generates internal reasoning tokens before producing visible output. You don’t see them, but you pay for them — they’re billed as output tokens, which is the expensive side of the meter. On a hard problem, a model might burn several thousand reasoning tokens to land on an answer that’s 200 tokens long.
For a multi-step logistics puzzle, a tricky migration script, or a debugging session where the bug is three layers deep, that trade is usually worth it. I’ve watched o4-mini untangle a rate-limiting bug that a general model confidently misdiagnosed twice. For “summarise this meeting transcript,” it’s pure overhead. You’ll pay more and wait longer for the same paragraph.
A rough rule for the split
If a competent junior could answer your prompt in one pass without scratch paper, use a general model. If they’d need to sit down, draw something, and check their work, use a reasoning model. That heuristic has held up better for me than any benchmark table.
Context windows: the number that sells, the behaviour that matters
Advertised context windows now run from roughly 128,000 tokens on the 4o family to 200,000 on the reasoning models, with some newer entries pushing past a million. The catch is that stuffing a huge window doesn’t guarantee the model attends to all of it. Information buried in the middle of a very long prompt gets missed more often than information at the start or end.
Practical fix: put your instructions and the critical facts at the top, keep the retrievable material relevant, and don’t use a million-token window as an excuse to skip retrieval. The mechanics of how language models handle long context are worth understanding before you build a pipeline around brute-force stuffing.
Cost is an architecture decision
Pricing varies by model and changes without much ceremony, but the shape of the bill doesn’t. Roughly, GPT-4o costs about $2.50 per million input tokens and $10 per million output tokens; 4o mini sits near $0.15 and $0.60. That’s a 16x gap on output. Reason, then design accordingly.
- Cached input tokens cost meaningfully less than fresh ones — useful when you resend the same long system prompt on every call.
- The Batch API knocks around 50% off in exchange for results within 24 hours, which suits overnight jobs fine.
- Output tokens dominate the bill on chatty models. Trimming verbosity with a clear instruction often saves more than downgrading the model.
- Routing beats picking. Send everything to a cheap model first, and escalate to a bigger one only when a confidence check fails.
That last point is the one most teams underuse. A classifier on 4o mini that escalates maybe 8% of traffic to a reasoning model will usually cost less than a single mid-tier model handling everything, and it often scores better on the hard cases.
The models you keep forgetting exist
Text generation gets the attention, but the catalogue includes embeddings for search and clustering, speech-to-text and text-to-speech, image generation, and a realtime API built for live voice with latency low enough to feel conversational. If you’re building anything voice-driven, the realtime models are a different product category rather than a faster chat model, and they need a different architecture.
Embeddings in particular are quietly the highest-leverage piece. A decent retrieval layer on top of a small model usually outperforms a big model with no retrieval, and it costs a fraction as much to run.
Enterprise procurement changes the answer
Plenty of organisations end up using the same OpenAI models through a different door. Data residency, existing Microsoft agreements, private networking, and compliance sign-off often push teams toward running OpenAI models through Azure, which changes the pricing structure, the model availability timeline, and sometimes the feature set. Worth settling before anyone writes code, because migrating later means redoing auth, quotas, and deployment names.
How to settle the question in an afternoon
Benchmarks won’t answer this for you. Your data will. Pull 50 real examples from your actual workload — the messy ones, not the tidy ones — and run each through two or three candidate models with the same prompt. Score them blind: pass or fail, plus a note on why. It’s a couple of hours of work, and it will overrule every opinion in this article, including mine.
Log token counts and latency alongside the scores. Roughly half the time, the cheaper model wins outright on your specific task, and you find out before you’ve built the wrong thing around the wrong endpoint. If you’re starting from scratch, this walkthrough of building on the OpenAI API covers the setup, rate limits, and error handling you’ll hit in the first week — the boring parts that decide whether the prototype survives contact with production.
Then re-run the suite whenever a new snapshot lands. Model upgrades are not free wins; a version bump that improves reasoning can shift tone, break a JSON schema, or start refusing prompts it used to accept. Treat the model name as a dependency you pin, review, and test, exactly like any other library in your stack.