Model picker

The question this replaces

"Which model should I use" usually gets answered by habit — whichever model a team started with, or whichever one showed up first in a blog post — rather than by actually weighing the task against the current lineup. This tool asks for the inputs that should decide it instead: the shape of the task, a rough budget ceiling, how much latency you can tolerate, and how much context a typical request needs. It returns a recommended model and effort level with the reasoning shown next to the answer, not just the answer on its own.

The shape of the current lineup

The current models span a wide range on price and capability, not a smooth gradient — there's a low-cost Haiku tier at the bottom, a mid-tier pair that most production workloads should default toward, and a top tier above them at the highest per-token price in the lineup. Prices are quoted at the context size you enter, because the newest Haiku is priced by prompt length: past its threshold a whole request moves to its higher rate card. The picker only recommends models you can actually call: invitation-only models are priced elsewhere on the site but never recommended here, and where two models in a line cost the same, it picks the one that hasn't been superseded. Picking the wrong end of that range in either direction is expensive in a way that's easy to miss: over-provisioning pays for reasoning depth a simple task never uses, and under-provisioning produces answers that look complete but are quietly wrong on anything that needed real reasoning to get right.

Why effort level matters as much as model choice

Two teams can pick the identical model and land on very different bills and very different output quality, because effort level is doing as much work as the model choice itself. A task that's genuinely simple — classification, extraction, a scoped lookup — usually does fine on a cheaper model at a modest effort level; a task that looks simple but has an open-ended reasoning component often needs the model bumped up before the effort level does. This tool weighs both levers together rather than fixing the model first and treating effort as an afterthought, because in practice the two decisions are not independent.

What the recommendation actually optimises for

The tool doesn't just return the cheapest model that could plausibly handle the task — it returns the model and effort combination that fits your stated budget ceiling and latency tolerance while flagging where you're trading one for the other. If your task needs a large context window fed in on every request, that constrains the recommendation too, since not every model in the lineup carries the same window, and a model swap for cost reasons can silently shrink how much context you can actually fit.

After you have a recommendation

A model recommendation is a starting point, not a guarantee — the only way to know it's right for your actual prompts is to test against them. Once you know which model you're targeting, the token & cost estimator prices your real text against it, and the effort & thinking cost estimator shows the cost curve across effort levels for that model specifically, so you can see where the recommendation sits relative to the alternatives rather than taking it on faith.