How to think about the model landscape

The short version: There's no single best model. Each lab ships a tier — fast/cheap, workhorse, flagship — along a cost-versus-capability curve. Pick a tier per task, start with the cheapest one that passes your own test, and weigh cost as heavily as intelligence.

Any article naming "the best model" is wrong by the time it's published. The rankings reshuffle every few weeks and the leading labs trade places constantly. So this isn't a ranking. It's a way to think about the choice that survives the next release, because it's built on how these models are constructed and what they cost to run — facts that change slowly — rather than on this month's leaderboard, which changes fast.

And for most real work, the choice hinges less on which model is smartest than on which is cheap and fast enough for the job. That's the dimension most people underweight, so it runs as a thread through everything below and gets a section of its own.

Why there are tiers, not a single best model

Every serious lab now ships a family rather than a single model — a small fast one, a balanced one, a frontier one. Anthropic's Claude line runs roughly from a compact tier through a workhorse to a flagship; OpenAI and Google ship analogous spreads; the open-weight world mirrors it. The names differ; the structure is identical, and it's identical because it reflects a real engineering tradeoff rather than a marketing decision.

The tradeoff is this: capability costs compute, and compute costs money and time on every single request, forever. A bigger model — more parameters — is generally more capable and is proportionally more expensive and slower to run for every token it ever produces. There is no setting in which you get the frontier model's capability at the compact model's cost, because the cost is paid in the physics of the forward pass. So the labs don't pick a point on that curve for you; they give you the whole curve and let you choose per task.

Which means the unit of decision is a tier for a task, not a favorite model for everything. Reaching for the flagship by default is the most common and most expensive mistake in the field.

The current field, by name

Naming names is risky on this article's own terms — the specific winners age fastest — so read this as a June 2026 snapshot and refresh it from the live trackers linked below, not from a copy of this page a year from now. As of now, three labs hold the closed-model frontier, separated by low single digits on most benchmarks and by more than 2× on price (Artificial Analysis, LLM Stats).

• Anthropic — Claude. Opus 4.8 is the flagship and currently the top-ranked released model on several aggregate boards, with Claude Fable 5 sitting above it as the highest-capability tier; Sonnet 4.6 is the balanced workhorse and Haiku 4.5 the fast, cheap tier. Claude is the common pick for sustained agentic coding and for the most natural prose. Opus 4.8 lists around $5 per million input tokens and $25 per million output.
• OpenAI — GPT-5 line. GPT-5.5 is the flagship (about $5 / $30 per million in/out, 1M-token context); GPT-5.4 is the value workhorse ($2.50 / $15); GPT-5 Mini ($0.25 / $2) and GPT-5.4 Nano (~$0.20 / $1.25) cover the fast, cheap tier. Reasoning is now built into the GPT-5 line as a "thinking" mode rather than a separate o-series (the standalone o3 / o4-mini reasoning models have been retired). GPT is the broadest all-rounder with the largest ecosystem.
• Google — Gemini. Gemini 3.1 Pro is the flagship and the current reasoning leader, posting the top public scores on hard reasoning suites (GPQA Diamond, Humanity's Last Exam, ARC-AGI-2), and it's the cheapest flagship at roughly $2 / $12. Gemini 3.5 Flash (~$1.50 / $9) and Flash-Lite are among the lowest-latency capable models, which is why they dominate high-volume work.
• xAI — Grok 4. A strong frontier model, particularly competitive on coding benchmarks.
• Open weights — DeepSeek, Qwen, Llama, and others. The open frontier is now led largely by Chinese labs. DeepSeek V4 is the top open model and ties closed frontier models on agentic-coding benchmarks; Qwen 3.5 / 3.6 (Alibaba) ship under the permissive Apache-2.0 license; Kimi K2.6 (Moonshot) and GLM-5.1 (Z.ai, MIT) are recent strong entries; Google's Gemma 4 is now Apache-2.0; and Meta's Llama 4 Scout holds the long-context record with a 10M-token window. The best of these are competitive with the hosted workhorse tier and carry no per-token cost.

Prices and rankings here are list figures as of June 2026 and will move. The durable way to read "who's best at what" is off the live leaderboards — Artificial Analysis, LLM Stats, and LMArena — and each provider's own pricing page, not any single article.

Strong picks by task — June 2026 snapshot

Reasonable starting points, not a ranking to trust blindly. The named models age; the task categories don't.

Override any cell the moment your own evaluation disagrees with it — the section below on that is the part of this article that doesn't go stale.

The architecture that bends the curve

Two architectural facts are worth knowing because they break the simple "bigger = slower and pricier" intuition in ways that matter for your choice.

Mixture of experts (MoE) (deep dive). Many modern models are not one dense network where every parameter fires on every token. They're divided into many "expert" sub-networks, and a routing layer activates only a few of them per token. This decouples the model's total size from its per-token cost: a model can have an enormous parameter count — and the knowledge that comes with it — while only running a fraction of those parameters on any given token, which keeps it fast and cheaper to serve than its headline size suggests. It's the main reason some very large models are also quick. When a model seems to punch above its apparent cost, MoE is often why.

Quantization (deep dive). A model's weights are numbers, normally stored at 16 bits of precision. You can store and compute them at lower precision — 8 bits, even 4 — which shrinks memory use and speeds up inference, at the cost of a little accuracy. Most served models are quantized to some degree, and self-hosters quantize aggressively to fit big models on smaller hardware. It's a dial between quality and cost, and it means "the same model" can perform slightly differently depending on how it's been quantized for serving.

The dimensions that actually decide it

Reasoning capability. How well the model handles genuinely hard problems — multi-step logic, long-horizon agentic work, subtle code, ambiguous instructions. The flagship tier is meaningfully better here and the gap is worth paying for on hard tasks. On routine tasks it's invisible: you're buying headroom you never use.

Test-time compute — the newer axis (deep dive). A class of "reasoning" models trades latency and tokens for accuracy by generating extended internal reasoning before answering, or by exploring several solution paths. The dial is usually exposed as an effort or thinking setting. This is one of the most important recent shifts, because it means the same model can sit at different points on the capability/cost curve depending on how hard you let it think. The practical consequence: on hard problems, more thinking often buys real accuracy; on easy ones it's pure waste — slower and pricier for no gain. Match the effort to the difficulty, not to a default.

Latency, and its two separate numbers. "Speed" is really two things. Time to first token is how long before the response starts — dominated by the prefill step, which processes your entire prompt, so a long prompt slows the start even on a fast model. Inter-token latency is how fast tokens stream after that — dominated by model size. A user watching a chat stream feels both; a batch job feels neither. Techniques like speculative decoding (a small model drafts tokens, the big one verifies them in bulk) speed up the second without changing the model. The point: "is it fast" depends on whether your prompts are long, your outputs are long, and whether a human is watching — three different answers.

Cost, and the asymmetry inside it. Pricing is per token, and almost always charges more for output than input — often several times more — because generating tokens one at a time is the expensive part, while reading the prompt is comparatively cheap and parallelizable. The spread within a single family, from compact to flagship, is large — published list prices commonly differ by tenfold or more. At scale, cost dominates everything else, and the output/input asymmetry means a chatty model that pads its answers can cost far more than a terse one of the same tier.

Context window. How much the model can consider at once. Long windows unlock whole-codebase and whole-document work — but as covered elsewhere, a big window is room to think, not a memory, it's expensive to fill on every request, and effective performance degrades well before the advertised maximum. Treat the number as a ceiling with caveats, not a free resource.

Modality and tool use. Whether the model handles images, audio, and documents natively, not just text — increasingly table stakes at the frontier, but quality varies and a task involving screenshots lives or dies on it. And, less visible on leaderboards but increasingly decisive: how reliably the model uses tools, follows a long plan, and recovers from its own errors over a hundred steps. This agentic reliability is where the flagship tiers have separated from smaller ones by more than their raw scores suggest, and it's the dimension that matters most for anything autonomous.

A way to choose

The pattern: start at the cheapest tier that could plausibly work, and step up only when your own evaluation shows it failing. Most teams do the reverse — reach for the flagship first because it obviously works — and then never come back down, paying flagship prices for workhorse tasks indefinitely. The savings from one deliberate step down that still passes your eval usually dwarf the savings from any other optimization.

Cost is a first-class decision, not an afterthought

Almost every model discussion starts and ends with intelligence — which model tops the leaderboard. For a large class of real work, that's the wrong question. If the job is to run the same prompt over a hundred thousand documents, classify a stream of events, generate embeddings, or drive a fast extraction loop, you are not bottlenecked on whether the model can crack a competition math problem. You're bottlenecked on throughput and cost per item. The flagship is overkill, and at that volume "overkill" is a bill with a lot of zeros.

A handful of levers move that bill by an order of magnitude or more, and most teams use none of them.

Use the small models for the big jobs. The mini / flash / nano tier is dramatically cheaper and faster than the flagship, and for well-scoped, repetitive tasks it is usually good enough. The gap isn't subtle. A small model like Claude Haiku 4.5 runs about $0.25 / $1.25 per million input/output tokens, and GPT-5 Mini around $0.25 / $2 — against roughly $5 / $25–$30 for a flagship. That's well over 10× cheaper per token, often 20× or more, at noticeably lower latency. For classification, extraction, routing, tagging, and tight loops, the right default is the smallest model that passes your eval, not the smartest one on offer. (Other strong cheap-tier options: Gemini 3.5 Flash-Lite and GPT-5.4 Nano.)

Use batch mode — the most underrated discount in the business. OpenAI, Anthropic, and Google all offer a batch API that runs your requests asynchronously, returning results within a window of up to 24 hours, for half the per-token price (OpenAI Batch API; Anthropic Message Batches). You hand over a file of up to tens of thousands of requests and get them back at 50% off, with no change to the model or the output. For anything that doesn't need an answer this second — overnight evals, backfilling a corpus, bulk document processing, embeddings, synthetic-data generation — this halves the bill for nothing. The catch is in the name: it's batch, not interactive. It's the wrong tool for a chat UI or a live agent, and a single batch entry can't carry a multi-turn agentic conversation. But for large offline jobs, skipping it is leaving half the money on the table — and it's the lever teams most often forget exists.

Cache the stable part of the prompt. If every request shares a long fixed prefix — a system prompt, a rubric, a set of examples — prompt caching bills that repeated prefix at a fraction of the normal input rate after the first call. On high-volume loops with a big shared preamble, this is a large, almost-free saving, and it stacks with batch pricing.

Cut output, not just input. Output tokens cost several times more than input. A model that pads every answer with preamble and restated context can cost more than a terser model a tier up. Constrain output length, ask for just the answer, and use structured output formats — it's a direct line-item reduction.

Route by difficulty. You don't have to pick one model for the whole workload. A cheap model can handle the easy 90% and escalate only the hard cases to the flagship — a cascade, or a cheap model acting as a router. Done well, you pay flagship prices only for the slice of inputs that genuinely need them.

Measure the metric that matters: cost per successful task. Cost per token and peak benchmark score are both misleading on their own. What you actually pay is cost per item that came out correct — which folds in the model's price, its verbosity, and its error rate. A cheap model that fails a third of the time and forces a retry on the flagship can end up more expensive than just using the flagship once. Build that number from your own eval and optimize it directly; it routinely points at a cheaper model than the leaderboard would.

The pattern under all of these: intelligence is what you shop for when a task is hard and one-off; cost and throughput are what you shop for when a task is repetitive and large. A great deal of production AI spend is the second kind of work running on the first kind's model.

Open weights change the calculation

Alongside the hosted frontier families is a strong, fast-improving set of open-weight models you can run yourself — led now by DeepSeek (V4), Alibaba's Qwen (3.5/3.6), Meta's Llama 4, Moonshot's Kimi, and Mistral. The best rarely top the absolute frontier, but they're competitive with the workhorse tier — DeepSeek V4 reportedly ties closed models on agentic-coding benchmarks — and self-hosting changes both the economics and the privacy story: no per-token bill, and your data never leaves your infrastructure. For high-volume, cost-sensitive, or data-sensitive workloads the real question is now "hosted frontier versus open-weight self-hosted," and the answer turns on your volume and your ops capacity, not on benchmark scores alone. The tax is operational: you own the serving, the scaling, the quantization choices, and the uptime.

What no benchmark shows

Two models with nearly identical scores can feel completely different in production. Writing voice. How literally the model follows instructions versus inferring intent. How it behaves at the edge of its context. Whether it refuses appropriately or over-refuses. How it degrades under load or ambiguity. These are hard to put on a leaderboard and obvious after a day of real use — which is the case for the one evaluation that actually counts.

Build your own evaluation

Public benchmarks are a coarse first filter, not a decision, and they have two specific problems. They're gamed — there's enormous incentive to optimize for the well-known tests. And they suffer contamination — benchmark questions leak into training data, so a high score can measure memorization rather than capability. Both push public numbers away from what you'd see on your actual workload.

The teams that choose well keep a small, private evaluation set drawn from their real tasks, with real inputs and graded outputs, and re-run it whenever a new model ships. This converts "which model is best?" — unanswerable in general — into "which model is best for this?", which is both answerable and stable across the next ten releases. It's a few days of work that pays for itself the first time it stops you from upgrading to a model that scores higher on paper and worse on your data.

The frontier will keep moving. Matching a tier to a task, understanding what you're paying for in latency and tokens, and proving the choice on your own data — those don't move.