Quality, Speed, or Cost: Choosing How Your Agent Picks a Model
The routing preference setting that decides which model your agent reaches for when nothing else has already decided — and the one option it deliberately doesn't offer.
By default, you never see which model actually answered your message. That's usually fine — until your agent is noticeably slow, or noticeably expensive, and you want to know why, and whether you get any say in it. You do, in one specific place.
Three values, on purpose
In your agent settings, there's a routing preference with exactly three choices: quality (the default), speed, and cost. Quality reaches for the strongest model available for the task. Speed prefers models that answer fast, at some cost to depth. Cost prefers the cheapest model still capable of doing the work.
There's no fourth option for "accuracy," and that's not an omission — it's a refusal. Nothing in the platform currently measures model accuracy well enough to route on it honestly, and a setting that promises something nothing verifies is worse than not offering it at all. Three real levers beat a fourth fake one.
Where it sits in the decision
This setting matters, but it's deliberately the weakest signal in the routing stack. If you've pinned a specific model to a conversation, that pin wins. If a bot has its own configured model, that wins too. If a fallback chain is in play — the kind of failover that kicks in when a primary provider is unavailable — that overrides the preference as well. Routing preference only decides what happens when none of those more specific choices have already made the call.
That ordering makes sense once you think about what each setting represents. Pinning a model or configuring a bot's model is somebody choosing a specific answer. Setting quality, speed, or cost is somebody choosing a way of choosing — a weaker, more general statement that naturally yields to anything more specific.
Setting it
If you've pinned a model somewhere and also set your routing preference to "cheapest," don't be surprised when the pinned model runs anyway — that's the precedence working as intended, not a bug. For most people, most of the time, the default of "best answer" is the right call, since it's what the system assumes you want until you say otherwise. Switch to speed when you're doing quick, low-stakes back-and-forth where waiting for the strongest model isn't worth it. Switch to cost when you're running something repetitive or high-volume where the difference in model quality won't be the thing that matters.