What model tiers are, and how to pick one
Last updated: 2026-09-22
Short answer: a tier is not a model, it's a group of models. You choose the tier; which model actually answers is decided by the platform, based on conditions at the time.
Why layers instead of a list
There are hundreds to thousands of model names in circulation, and the set changes weekly. Expecting users to memorise which ones are good is unrealistic — and whatever you memorise goes stale fast.
Tiers compress that into three choices, layered by capability and quota. All you have to judge is how strong a model the job needs.
Roughly how the three split
| Tier | Suits | Typical jobs |
|---|---|---|
| Entry | Everyday work, unmetered feel | Sorting files, editing copy, translation, quick questions |
| Standard | The daily workhorse | Writing code, analysing data, multi-step tasks |
| High performance | Hard problems and long jobs | Complex refactors, long-document reasoning, work that's easy to get wrong |
For most people the standard tier covers the day. Entry suits high-volume, simple work; hold the top tier for the jobs that genuinely bite.
Why the same task differs across models
Models don't vary along one axis labelled speed. At least these:
- What they're good at — code, long documents, or strict output formats.
- How much context fits — how much material goes in at once. This decides whether you have to chop it up first.
- How steady they are — whether the same instruction gives consistent results.
- What they cost — the same job can differ several times over.
So "which model" isn't a detail. It's often the first variable in whether the result is any good.
Tier names belong to the platform
An easy one to trip over: a tier name is only valid where it was defined. Take it somewhere else, or point it at an entry point that doesn't serve it, and you get "model does not exist" — when the model is fine and the name simply doesn't belong there.
Similarly, one platform often exposes more than one entry point, each backed by a different model pool. The model name and the address have to match as a pair.
How tiers relate to bringing your own key
Tiers run on the platform's credit; your own key runs on yours. Both go through the same entry point, and they can be mixed: tiers for the day-to-day, your key for one particular job.
How to choose among the four routes, see where model credit comes from.
When you can't decide
Take the default and run it once. The fastest way to find out whether a model is good enough is not comparing specifications, it's letting it do one real job.
Not good enough, step up a tier. The reverse holds too: if you run a task daily and it's always simple, stepping down usually costs nothing.
There's one case where choosing up front pays: you already know the job is sensitive to the model — pulling in an entire document in one pass, say. Then check the context size first; it settles more than any other number.
Next
- Where model credit comes from: four routes, and you can mix them — tiers are only one of them
- Four command-line agents, and what each is good for — switch the tool, the models stay the same
- Attaching a key you already have — to use credit you already hold