Course / Module 4

The LLM landscape: choosing a model

How to choose among proprietary and open models: criteria that matter for assistants, the tiers and routing strategies, and a dated snapshot of the families you will meet.

14 min study timeDesignCodeLast reviewed Markdown version

In short

  • The best model is the cheapest one that passes your evaluation set.
  • Measure cost per resolved conversation, not price per token.

What you will learn

  • Compare models using criteria that matter for assistants, not only leaderboards
  • Understand model tiers and when to route between them
  • Weigh proprietary against open-weight models
  • Plan for model deprecation, version pinning and fallbacks

Start from the job, not the leaderboard

New models arrive every few weeks, and rankings change faster than you can build. The durable skill is a method for choosing, not a memorized list. We give you both: criteria and tiers that last, and a dated snapshot that will age.

A note on neutrality

Vendors in this module are listed alphabetically, and we don't rank them. Third-party trackers disagree with each other, and any ranking would be stale within weeks. Use official documentation for current specifications and prices.

Criteria that matter for assistants

Criterion What to ask
Quality on your tasks Does it pass your evaluation set: your policies, tools and tone?
Tool-calling reliability Does it choose the right tool and fill arguments correctly?
Instruction following Does it obey scope and refusal rules over many turns?
Grounding Does it stay within retrieved sources and say "I don't know"?
Latency Time to first token and speed afterward. Critical for voice.
Cost Price per resolved conversation, with caching and routing included.
Context window and long-context quality Not just the size limit, but whether it uses long context well.
Languages Quality in each language you serve, tested, not assumed.
Data handling Retention, training use, regional processing, certifications.
Stability Rate limits, uptime, deprecation policy, version pinning.

Try it: a model-tier chooser

This small tool applies the reasoning above. It suggests a tier of model for your situation. It doesn't name a product, because the right product depends on your tests.

Tiers and routing

Most providers offer a family of models at different sizes. Think in tiers:

Tier Strengths Use for
Flagship / frontier Best reasoning, tool use and long tasks Hard turns, planning, agents, evaluation judging
Mid-tier Strong all-rounder at a lower price A sensible default for many assistants
Small / fast Very low cost and latency Classification, routing, simple answers, voice
Open-weight You host it, you control data and cost Privacy-sensitive or very high volume
On-device Runs locally, works offline Edge and privacy cases

A router sends each turn to the cheapest tier that can handle it, and escalates when confidence is low.

User messageSmall model: classify and score difficultyEasy: small model answersHard: flagship model answersValidate and respond

A simple routing design. The classifier is cheap, so the savings accumulate.

Measure the router itself: how often it escalates, and how often an easy-labeled turn fails. Many teams also add prompt caching for the system prompt and shared context to cut cost and latency, where the provider supports it.

Proprietary or open-weight?

Proprietary API Open-weight, self-hosted
Time to start Minutes Days to weeks
Peak quality Usually highest Closing the gap, varies by task
Data control By contract Full, inside your boundary
Ops burden Provider's Yours: GPUs, scaling, updates
Cost shape Pay per use Fixed infrastructure plus engineering
Licensing Terms of service Read each model's license carefully

Many teams use both: a proprietary model for the hardest turns and an open-weight model for high-volume, sensitive or simple ones.

Cost: think per resolved conversation

text
cost per resolved conversation =
  (model cost + retrieval cost + tool and infrastructure cost + human escalation cost)
  / resolved conversations

A cheap model that needs three retries, or escalates twice as often, may cost more than a pricier model that solves the problem first time. Include humans in the equation, because escalations are the most expensive turn of all.

Snapshot: the families you will meet (October 27, 2026)

This table will age

It was compiled on October 27, 2026 from vendor release notes and independent trackers. Names, versions and prices change often, and sources disagree. Confirm everything in the official docs linked below the table.

Vendor Families you will meet Often chosen for
Anthropic Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5, plus a higher tier called Fable 5.1 Tool use, long agentic tasks, careful instruction following; tiers from fast to flagship
Google Gemini 4 Argon (released October 13, 2026), alongside Flash tiers such as Gemini 3.8 Flash Multimodal work, long context, Google Cloud integration
OpenAI The GPT-6 family, with several variants and 6.1 releases through October 2026 Broad ecosystem, general assistants, coding
Open-weight DeepSeek V4 family, Kimi K3, Qwen 3.x, GLM-5.2, Gemma 4 Self-hosting, data control, cost at scale

Independent trackers in October 2026 rank these differently and often disagree on prices for the same model. That is the lesson: use them to build a shortlist, then decide with your own evaluation set.

Operate for change

  • Pin versions. Avoid "latest" aliases in production.
  • Keep a fallback. Test a second model from a different provider so an outage or deprecation is a configuration change.
  • Track deprecations. Subscribe to provider notices and calendar the retirement dates.
  • Gate every change. Run your evaluation set (module 14) before swapping a model or editing a prompt.
  • Log the model version with every conversation so you can explain behavior later.
  • Re-tune prompts per model. A new model usually needs a new prompt pass (module 5).

Key takeaways

  • The best model is the cheapest one that passes your evaluation set.
  • Measure cost per resolved conversation, not price per token.
  • Route easy turns to small models and hard turns to bigger ones.
  • Pin versions, keep a fallback and re-run your tests before any switch.

Knowledge check