Choosing a model for your budget

Model selection usually gets argued on capability and settled on price, which is the wrong order. Capability is hard to evaluate and easy to have opinions about; price is easy to evaluate and gets treated as a tiebreak. The result is a decision made on the least reliable evidence available.

A better procedure starts from the shape of your workload, because that determines which price even matters.

First: is your workload input-heavy or output-heavy?#

Every model here charges four to five times more for output than for input. Claude Opus 5 is $5 per million in and $25 out; GPT-4o mini is $0.15 and $0.60. So the ratio between your input and output volume decides which column of the pricing table you are actually shopping in.

Input-heavy work — classification, extraction, summarisation, retrieval-augmented answering — sends a lot of text and gets back a little. A 4,000-token document producing a 200-token summary is twenty parts input to one part output. Here the input price dominates, and the gap between GPT-4o mini at $0.15 and GPT-4 Turbo at $10 is a factor of 66.

Output-heavy work — drafting, code generation, long-form explanation — inverts that. A 200-token instruction producing 2,000 tokens of code is priced almost entirely on output, where the same two models sit at $0.60 and $30.

Work out which you are before comparing anything. Teams routinely optimise the wrong column.

Second: does the task have a verifiable answer?#

This decides whether a cheap model is even a candidate.

If the output is checkable — JSON that must parse against a schema, a classification from a fixed set, code that must compile or pass a test — then a cheap model plus validation is often the better economics. A failure is detectable, so you can retry, and retrying a $0.0006 request twice still costs less than one $0.0225 request.

If the output is not mechanically checkable — an analysis, a piece of prose, a judgement call — then a wrong answer is silent. It reaches the user, and the cost of that is not on the pricing page. This is where paying for the stronger model is straightforwardly rational, and where "we saved 80% on inference" can be a bad trade.

Third: measure your actual tokens#

The tables in the pricing pages are per million tokens. Your decision needs dollars per month, and the conversion runs through your own text.

Take five representative requests, paste each into the calculator, and record input and output token counts. Take the median. Then multiply by volume, remembering that your system prompt is charged on every call and that multi-turn conversations resend their history each turn.

Only now does the comparison table mean anything, because it is denominated in your workload rather than in a hypothetical one.

A rough map#

With those three answers, the shortlist usually collapses quickly.

• High volume, verifiable output, simple task. GPT-4o mini at $0.15/$0.60. Add schema validation and a retry. This is where the enormous volumes live and where the savings are real. GPT-3.5 Turbo at $0.50/$1.50 is cheaper per token than most of this list but retires on 23 October 2026, so it is not a choice to build on now.
• High volume, needs some judgement. Claude Haiku 4.5 at $1/$5 sits deliberately between the tiers — meaningfully more capable than the cheapest options while staying an order of magnitude below the frontier.
• General-purpose product work. GPT-4o at $2.50/$10 or Claude Sonnet 5 at $3/$15 — the latter on introductory pricing of $2/$10 until 31 August 2026, which makes it the cheaper of the two today and the more expensive after. Most application features that are not enormous in volume land here, and the difference between them will be decided by evaluation on your task, not by the $0.50 gap.
• Hard reasoning, low volume, expensive mistakes. Claude Opus 5 at $5/$25. Justified when a wrong answer costs more than the request, which is a real situation and a rarer one than it feels.
• GPT-4 Turbo at $10/$30 is the outlier on this list: it is priced above Opus 5 while being an older generation, and it retires on 23 October 2026. If you are on it for historical reasons, that is now a migration with a deadline.

Fourth: check the model has a future#

A price comparison says nothing about how long a model will exist. Two of the eight above are removed by their provider in October 2026, which turns a good rate into a migration you did not schedule. Check the provider's deprecation page before committing, and treat a published retirement date as disqualifying for anything you are still building.

Fifth: re-check at ten times the volume#

Run the arithmetic again at 10x your projected traffic. A model choice that is comfortable at launch and alarming at ten times it is worth knowing about now, while switching is still a configuration change rather than a migration.

The same applies to your fallback. If you fail over to a second provider during an outage, that provider's rate applies for the duration — and a fallback on a frontier model is a sound reliability decision and an expensive default.

The part that is not about price#

None of this substitutes for evaluating quality on your own task. Benchmarks measure general capability; you care about one narrow thing. Build a small set of representative inputs with known-good outputs, run your shortlist against it, and let that decide between the two or three models that survive the cost filter.

Cost analysis narrows the field. It does not pick the winner.