Model releases have gotten hard to track. Providers ship faster than anyone can evaluate, benchmark differences are often within noise, and the price spread between the top models is wider than the capability spread.

This is a practical guide to the current lineup for people building products: what exists, what it costs, and how to actually decide.

The Current Frontier Lineup

The spread is the story. Fable 5.1 costs 10x what Haiku does on input and output alike. The capability gap between them is real but nowhere near 10x for most tasks — which means model selection is one of the highest-leverage cost decisions you will make.

Google, OpenAI, and Meta all ship comparable tiers at broadly similar price points. The strategic picture is the same everywhere: a frontier tier priced for hard problems, a mid tier that handles most production work, and a cheap fast tier for high-volume simple tasks.

The Mistake Almost Everyone Makes

Picking one model and routing everything through it.

Most applications have a mix of tasks: some genuinely need frontier reasoning, most do not. Classification, extraction, summarisation, routing, and simple rewriting run fine on the cheapest tier available. Complex multi-step reasoning and long-horizon agentic work is where the expensive models earn their price.

Routing by task rather than picking one default is usually worth more than any prompt optimisation you will do. If 80% of your calls are simple and you are running them all through a frontier model, you are paying roughly 5x more than necessary for that 80%.

How to Actually Choose

Start at the cheap end, not the expensive end

The common approach is to build against the best model, get it working, and then try to cut costs. This is backwards, because by then your prompts are tuned for that model and the migration feels like a regression.

Better: start with the cheapest tier that could plausibly work. If quality is insufficient, step up one tier. You will often find the mid tier is fine, and you will have discovered that before building a dependency on the expensive one.

Benchmarks are a weak signal for your use case

Published benchmarks measure performance on standardised tasks that are probably not your task. A model that leads on a reasoning benchmark may be unremarkable on your specific extraction problem.

Build a small evaluation set — twenty to fifty real examples from your actual workload, with known-correct answers. Run it against three models. This takes an afternoon and tells you more than any leaderboard.

Context window is usually not the constraint you think

Frontier models now offer 1M-token context windows. This sounds transformative and mostly is not, because filling a 1M-token context is expensive — at $5 per million input tokens, a single full-context call costs $5 before you generate anything.

Large context is genuinely useful for whole-codebase analysis and long document work. For most applications, retrieval into a smaller context is cheaper and often more accurate, because relevant information beats abundant information.

Latency is a product decision

Frontier models are slower. For an interactive product where someone is waiting, a fast mid-tier response often beats a better slow one. For a background job, nobody notices the difference.

Match the tier to whether a human is waiting.

Reasoning Modes and What They Cost

Current frontier models can spend extra tokens reasoning before answering, and this is now usually controlled by an effort level rather than a fixed token budget. Higher effort means better results on hard problems and more tokens spent on everything.

Two practical notes:

Effort is a per-route decision, not a global setting. Your hard reasoning path and your simple classification path should not run at the same effort level.

Higher is not always better. On simple tasks, high effort can produce worse results — the model overthinks a problem that had an obvious answer. Test rather than assuming.

Prompt Caching: The Underused Lever

If you send a large stable prefix — a long system prompt, a document, a set of examples — with every request, prompt caching cuts the cost of that prefix dramatically on subsequent calls.

The mechanic that matters: caching is a prefix match. Any byte that changes invalidates everything after it. This has a specific practical consequence — putting a timestamp, a request ID, or a user name near the top of your system prompt makes the entire prompt uncacheable.

The fix is ordering. Stable content first, volatile content last. This is a five-minute change that can meaningfully reduce your bill, and it is the single most common cost mistake we see people make.

Building So You Can Switch

Given how fast this moves, the important architectural decision is not which model you pick — it is how hard it is to change your mind.

Put provider calls behind a thin interface. Not a heavy abstraction layer, just a function you call instead of the SDK directly. Switching then means changing one file.

Keep your evaluation set. The twenty to fifty examples you built to choose your first model are what let you evaluate the next one in an hour instead of a week.

Do not over-tune prompts to one model. Heavily model-specific prompt engineering is a migration cost you are choosing to take on.

Watch your actual token usage. Log input and output tokens per route. Most teams are surprised by which endpoint dominates their bill, and you cannot optimise what you have not measured.

The Practical Summary

• Route by task. Most work does not need a frontier model.

• Start cheap and step up, rather than starting expensive and cutting down.

• Build a small real evaluation set. Trust it over benchmarks.

• Order prompts stable-first so caching works.

• Set effort per route, and verify higher actually helps.

• Keep provider calls behind one thin interface.

The models will change again in a few months. An architecture that lets you re-evaluate in an afternoon is worth more than picking correctly today.

Pricing and model details above were checked against provider documentation at the time of writing. This space moves quickly — verify current figures before making budget decisions.

If you are building an AI product independently, you can see what other indie makers are using in our report on 132 indie AI products, or list your own.