Choosing a model
Build the mental model
The best model is the smallest, cheapest, fastest option that meets the task contract on your evals—not the leaderboard winner in the abstract.
1Try it yourself
Playground
Model chooser
Turn on what you need. Watch the recommendation reorder — no hype required.
- 1Swift Mini
Great for autocomplete & short drafts.
- 2Local Open
Runs on your machine — privacy first.
- 3Balanced Pro
Solid daily driver for most chat tasks.
- 4Frontier Max
Hardest reasoning — slower & pricier.
Best match floats to the top
2Learn the idea
Read
Analogy for this concept only
Think of picking a vehicle for a delivery route—payload, fuel, maintenance, and failure modes matter more than brochure horsepower. Use the analogy to name the moving parts for model selection, then drop it when you need numbers. For the invoice-extraction service, the enduring idea is not a vendor feature name; it is the decision model selection changes and the evidence that decision leaves behind.
The best model is the smallest, cheapest, fastest option that meets the task contract on your evals—not the leaderboard winner in the abstract.
Beginners often blur neighboring ideas when discussing model selection. Keep it distinct by asking what artifact would still exist if model weights were frozen and only this layer changed on the invoice-extraction service. If you cannot name that artifact, you are still describing “the AI” in general.
Read
Case lens: invoice-extraction service
Define task cases and hard gates; score candidates on quality, latency, cost, context needs, tool/schema support, and vendor constraints; keep a fallback model. In day-to-day language for model selection: someone brings a need, the system inspects allowed evidence, this layer contributes a judgment or structure, and a consequence reaches a user or downstream system. Deterministic guards—permissions, schemas, arithmetic—still belong to the application around the invoice-extraction service.
Uncertainty is normal for model selection. Incomplete inputs and probabilistic behavior mean the invoice-extraction service needs an escape hatch (retry, fallback, escalate) rather than fake certainty in fluent prose.
Read
Make it operational
When you explain model selection to a new teammate on the invoice-extraction service, forbid the sentence “the AI just knows.” Replace it with the artifact that moves and the evidence you would file for model selection. If they can falsify your picture with a single counterexample from last week’s traffic on the invoice-extraction service, your mental model is working.
Also pin one numeric memory from this model selection chapter: If model L hits 96% field-F1 at $0.12/1k docs and model H hits 97% at $0.55/1k, the +1 pt may lose unless errors are extremely costly. That number is not decoration; it is a template for how claims about model selection on the invoice-extraction service should look in design docs. Scoped specifically to model selection / invoice-extraction service / mental-model.
Read
Common mix-ups
People confuse model selection with neighboring buzzwords when debugging the invoice-extraction service. Before changing prompts, ask whether the broken stage was evidence gathering, the model selection judgment itself, validation, or the product action. Fixing the wrong stage creates folklore (“we tried model selection and it failed”) that blocks the next team on the invoice-extraction service. Scoped specifically to model selection / invoice-extraction service / mental-model.
Go deeper
Before you start
Why this matters
Spend two minutes on the invoice-extraction service. If model selection disappeared tomorrow, what breaks first for the user, and what evidence would prove it was working? Write that before you read the analogy.
Related lessons
Check your understanding
Page assessment
Answer from memory. Completion is saved from this evidence, not from opening the next page.
All responses are required.