Skip to content

Choosing Models

There is no single "best" AI model — there's the best model for a given task, at a given moment, for a given budget. Picking well is a skill that saves real money in products and real time in development. Picking by habit ("I always use the big one") usually means overpaying for easy work and occasionally under-powering the hard work.

Why this matters — Limitation #3 (Outdated knowledge), applied to the market itself. The frontier moves constantly. The model that topped the charts last quarter may be mid-tier and overpriced today; cheaper models routinely catch up to last year's flagship. Treat any specific ranking as perishable. Re-check the leaderboards when it matters — don't trust last quarter's pick, and don't trust a model name you memorized. This page deliberately keeps specific model names light for the same reason: they date fast.

The cost / speed / quality triangle

Every model choice trades off three things:

  • Cost — price per token (or per request). Multiply by your volume and it dominates the economics of an API product.
  • Speed — latency and throughput. Matters for anything a user waits on, and for high-volume batch work.
  • Quality — reasoning depth, accuracy, instruction-following on hard tasks.

You rarely get all three at once. A top reasoning model is slower and pricier; a small fast model is cheap but shallower. The job isn't to maximize quality — it's to pick the cheapest, fastest model that's good enough for the specific task.

Match the model to the task

For non-developers: the principle is simple — use a small, cheap model for simple repetitive work, and save the expensive, powerful model for genuinely hard problems. Same as you wouldn't put your most senior engineer on data entry.

Task type Lean toward… Why
High-volume classification, tagging, extraction A small, fast, cheap model The task is simple and repetitive; you pay per item, so unit cost dominates
Routine code edits, formatting, simple Q&A A mid-tier model Good enough, noticeably cheaper and faster
Multi-step reasoning, hard debugging, architecture, tricky logic A strong reasoning model The cost of a wrong answer dwarfs the price difference
Tasks over very large inputs (huge docs, whole codebases) A model known for large-context handling Some models degrade less as context grows (ties to Limitation #1)

Different models have different strengths

It's not a single quality ladder. Models specialize:

  • Large-context handling — several families now offer very large (~1M-token) context windows, and some hold up better than others across very large inputs, useful when you genuinely must feed in a lot at once. (That said, more context isn't free or always better — see Context Management.)
  • Multi-step reasoning — dedicated "reasoning" models that think before answering excel at logic-heavy, multi-step problems and hard debugging.
  • Cheap-and-fast at scale — smaller models are excellent for classification, extraction, routing, and other high-volume, well-defined tasks where you don't need deep reasoning.
  • Agentic tool-use — recent models are more agentic by nature and will more easily leverage accessible tools than previous model generations, even flagship ones.

A common, cost-disciplined pattern in API products: route by difficulty. Use a cheap model for the easy 80% of requests and escalate only the hard cases to a stronger model. This keeps the average cost-per-request low without sacrificing quality where it counts.

The go-to leaderboard: Artificial Analysis

When you need to compare models on real numbers rather than vibes, use Artificial Analysis (https://artificialanalysis.ai/leaderboards/models). It's the most practical cross-provider comparison for the exact triangle above — it benchmarks 100+ models from all the major providers and lets you weigh intelligence against price and speed in one place.

How to read it

The leaderboard reports several axes — read the ones that match your constraint, not just the headline rank:

  • Intelligence Index — a blended quality score across benchmarks. The headline "who's smartest" number. Good for the hard-task decision; less relevant for cheap bulk work.
  • Price — blended cost per million tokens. The number that decides your product's margins at volume. Sort by this when the task is simple and high-volume.
  • Output speed — tokens per second. Matters for user-facing latency and large batch jobs.
  • Latency — time to first token. Matters for anything interactive.
  • Context window — how much you can feed in at once. Check this for large-input tasks.

How to actually use it: start from your binding constraint. Cost-sensitive bulk task? Sort by price, then read up the intelligence column until you hit "good enough." Hard reasoning task? Start from the top of intelligence and check whether the price and speed are acceptable. The right pick is an intersection of your constraints, not the top of any single column.

The big families, at a high level

Three families consistently sit near the frontier, each strong across general reasoning and coding:

  • Claude (Anthropic)
  • Gemini (Google)
  • GPT (OpenAI)

Beyond these, a wave of open-weight models — many from Chinese labs — is closing on the frontier fast: Alibaba's Qwen, Zhipu's GLM, MiniMax, and Xiaomi's MiMo, alongside the better-known DeepSeek. They increasingly land within striking distance of the closed flagships on general reasoning and coding, while being open source (self-hostable) and often an order of magnitude cheaper — roughly 10–20× less per token through hosted APIs. That combination changes the cost equation entirely: for high-volume or cost-sensitive work they're often the pragmatic default, and being open-weight means you can run them on your own infrastructure when price or data residency demands it.

Specific model names are deliberately left out here. The ranking among these shifts every few months — the only reliable move is to check a current leaderboard against your actual task and budget when the decision matters (Limitation #3 in action). A name that was right when this was written may be wrong by the time you read it.

Cost discipline in API apps

In a product, the model isn't just a quality choice — it's a line item that scales with every user. A model that's 5× more expensive and only marginally better can quietly wreck your unit economics at volume. Discipline looks like:

  • Default to the cheapest model that passes your quality bar, measured on your task, not a generic benchmark.
  • Route by difficulty so expensive models handle only the requests that need them.
  • Keep output short. Output tokens are far pricier than input — commonly 4–5× per token — so verbosity costs more than it looks. Ask for the shortest useful answer and cap max_tokens; trimming a rambling response is a direct saving.
  • Return indexes, not full items. When the model selects from a list you already have, have it emit the IDs or positions of its picks rather than re-transcribing each entry — you pay for a number instead of a paragraph, on the expensive side of the bill.
  • Cache repeated context. Prompt caching reuses a stable prefix (a long system prompt, a big document, tool definitions) across calls for roughly 90% off those repeated tokens — a large win whenever the same context recurs.
  • Batch non-urgent work. For jobs that don't need a live response, the Batch API runs them asynchronously for about 50% off. Ideal for bulk classification, backfills, and offline evals.
  • Drop to a cheaper service tier when speed doesn't matter. For non-critical work that still needs a synchronous reply, some providers offer a slower, discounted tier (OpenAI's flex, for example) that trades latency for a lower per-token price — a middle ground between the standard tier and full batching.
  • Re-evaluate periodically. As prices fall and new models land, last quarter's optimal choice is often beatable — revisit it instead of assuming it still holds.

The model isn't the only cost lever — see Patterns for LLM Apps for how caching, batching, and routing fit together in production.

Same logic, both paths

The framework is identical whether you're choosing a model for product code or for a dev tool — only the weighting changes:

  • In product code (via the API): you pay per token on every request, multiplied by your traffic, so per-token cost at scale usually dominates. The discipline above — cheapest model that clears the bar, route by difficulty — exists to protect unit economics. See Patterns for LLM Apps for the product side.
  • In dev tools (a coding assistant): you typically pay a flat rate and make far fewer calls, so cost matters less and capability on hard tasks matters most. It's usually worth reaching for the strongest reasoning model, because your time is the expensive resource and a wrong answer costs more than the extra tokens.

Same triangle, different corner: scale pushes products toward cheap-and-good-enough; the value of your attention pushes dev work toward most-capable.

Quick checklist

  • Identified the binding constraint for this task (cost, speed, or quality)
  • Matched model strength to task type, not habit
  • Checked a current leaderboard rather than trusting a remembered ranking
  • For API apps: defaulted to the cheapest model that passes the bar; considered difficulty routing
  • Scheduled a re-check, because the frontier moves

Sources