Quick answer: A compact model handles triage and extraction, a mid-tier model carries the conversation, and a frontier model takes the turns that genuinely need judgment. Routing between the three tiers is what makes the bill survivable; the tier map below shows which turns belong where.
Model choice matters more on voice than on chat for one reason: a voice agent runs the model on every turn of a live phone call, at phone-call volume, with the caller's patience measured in fractions of a second. That combination makes the per-token price of the model a per-minute property of the product. Get the tiering wrong in either direction — everything on the frontier model, or everything on a model too small to resolve anything — and the agent either costs more than the problem it solves or escalates so much it saves nothing.
The tier map: which models earn their place on a call
A production voice agent issues four kinds of turns, and they do not need the same model. The mature pattern that emerged over the last year across paid tiers and vendor deployments is a three-tier map:
| Turn type | What the model does | The tier that fits | Why |
|---|---|---|---|
| Classification and triage | Decide what the caller wants, route the turn, extract a field | Compact tier (e.g. Claude Haiku-class) | Sub-second, structured output, enormous volume — the cheapest tier that is reliable |
| Standard conversation | Answer from the knowledge base, call a tool, book, confirm, take a message | Mid reasoning tier (e.g. Claude Sonnet-class) | Needs tool-use reliability and instruction-following, frontier adds nothing measurably better |
| Hard judgment | Edge cases, ambiguous compliance or billing decisions, recovery after a misunderstanding | Frontier tier (e.g. Claude Opus-class) | Rare-turn insurance — correct only when a smaller model demonstrably mis-resolves |
| Never-a-model turn | Greetings, confirmations, fixed disclosures | No model at all | Deterministic prompts and recorded lines cost zero tokens |
Two implications fall out of this map. First, the frontier tier is a scalpel, not a default: on a well-routed agent it should carry a single-digit percentage of turns. Second, the "cheapest model that resolves the turn" framing beats the "best model overall" framing — on voice, accuracy that a cheaper tier already delivers is worth exactly zero extra cents.
Model routing: the difference between a demo and a P&L
Every vendor demo routes one model. Every production bill asks whether routing could have been cheaper. Model routing is the mechanism that decides, per turn, which tier runs — and it is what makes the tier map above an operating reality instead of a design aspiration. Devotel Orbit ships this as a built-in primitive, not a configuration the tenant assembles: intents such as triage, tool calls, extraction, compliance, and orchestration each map to a default tier, and a tenant can override the mapping per agent when its own telemetry says the defaults are wrong for its traffic.
The reason a platform ships this rather than leaving it to each tenant is structural. Routing decisions need three inputs only the platform sees at once: the intent of the incoming turn, the tenant's spend position (an optional budget cap can automatically downshift routing to a cheaper tier when spend nears the cap), and failover behavior when a provider returns congestion or errors. A tenant that hand-assembles routing on top of raw API keys owns the intent classifier, the budget logic, and the failover ladder itself — on a live phone call, where a wrong decision is a silent caller or a spiraling invoice.
The automatic downshift point deserves emphasis because it inverts the usual failure mode. The unbounded-meter failure is not a dramatic outage; it is a campaign push or a seasonal spike where conversation depth per call quietly doubles the token bill. A downshift-to-cheaper-tier policy degrades the agent's brain gracefully instead of letting the meter run — the call continues, the caller still gets an answer, and the operator reads the downshift on the spend dashboard afterward.
Grounding the choice in billing telemetry, not datasheets
Vendor directives and public benchmark tables say which model is "best." They cannot say which model is cheapest sufficient for your traffic, because sufficiency is a property of your calls, your knowledge base, and your escalation threshold. The only durable evidence is per-model, per-agent, per-conversation billing data on your own production traffic.
That is the grounding loop Orbit exposes in the dashboard: the billing telemetry surface breaks spend down per model, per agent, and per conversation, so a routing change is validated on the same screen that reports it — move triage to a cheaper tier, watch the resolution rate hold, watch the per-model spend line drop. A second dashboard prices the outcome side: each agent's AI cost against the value of the outcomes it resolves, under a configurable value-per-outcome assumption. An agent can look expensive on the cost surface and still be the best-performing line on the value surface, and the disagreement between the two views is exactly the question a buyer should be asking. The companion piece on this blog, LLM spend management — cost governance for AI agents, walks through both surfaces and the alert rules that watch them; per-country voice and messaging rates sit on the pricing page alongside the model bill.
This grounding loop also protects against a subtler drift: model providers change meaning under the same name. A routed agent should pin a specific model version per intent, or it is benchmarking a moving target. Prompt regression evaluation — replaying a fixed prompt set against a candidate model before a routing change goes live — is the cheap insurance that makes tier changes safe to make from billing data instead of folklore.
Where quality actually lives: small-model failure modes vs price
Cheapest-sufficient has exactly one failure mode, and on voice it is audible: a tier too small for the turn. The caller asks a layered question, the compact-tier model answers a different one confidently — and because a voice agent can't pause a live call to silently escalate, the muddled answer goes out over the line. The worst version of this is the multi-hop detour: a cheap router tier sends the caller through intents they never asked for, one hop at a time, each answer fluent and each answer wrong. That is the trade the whole section of the cost map is weighed against: every downward routing decision saves tokens and rents the risk of this audible mis-resolution.
The remedy is an escalation-aware routing policy, not a blanket upgrade. Track the share of turns the compact tier escalates or mis-resolves per intent, and upgrade only the intents where that share exceeds threshold. An agent that resolves 95% of FAQ traffic on the compact tier and 5% on the frontier tier beats the same agent solving everything on the mid tier at twice the price per turn — as long as the escalation events are real, measured, and priced. And where quality cannot be traded at all — a healthcare scheduling flow, a regulated disclosure — hard-pin those intents to a higher tier in the routing map, because the cost of one mis-resolved call dwarfs the token saving.
Frequently asked questions
Should I just run everything on the frontier model to be safe?
For most production traffic, no. A frontier-tier-everything posture spends the most money on the turns that need it least. Run the compact and mid tiers with an escalation-aware routing policy, and reserve the frontier tier for the turn types where your own telemetry shows smaller tiers mis-resolving. The spend surface in the dashboard makes that a measurable decision rather than an ideological one.
How do I know when a cheaper model is hurting quality?
Watch two signals together: the per-model spend line dropping, and the escalation or repeat-question rate rising. A downshift is successful only when the first moves without the second. Where quality cannot be traded — disclosures, regulated flows — pin those intents to a higher tier in the routing map instead of letting the budget governor downshift them.
What is the difference between model routing and the cost governor?
Routing maps intent to tier — which model answers which kind of turn. The governor bounds spend — an optional cap that can automatically downshift routing to a cheaper tier when the budget is nearly consumed. Routing is the steady-state decision; the governor is the exception-state protection. Both report onto the same billing telemetry surface.
Does a small-model routing layer add latency to the call?
The routing decision is a classification turn on the compact tier — one of the fast tiers by design — and it runs concurrently against the call rather than serially before every answer. Where the intent is deterministic (a greeting, a DTMF menu selection) no model runs at all. The latency budget of the full pipeline is a separate discipline; see how to reduce latency in AI voice agents for the stage-by-stage breakdown.
Where do I see which model each agent is using and what it costs?
The dashboard's AI spend surface breaks usage and cost down per agent, per model, and per conversation, with budget caps and downshift policy configurable alongside it. Change a routing tier, and the same screen shows the effect — that loop is the point.
The takeaway
Cost-effective voice agents come from tier-mapped models plus routing that picks the cheapest sufficient one per turn, with a governor that downshifts instead of an unbounded meter and telemetry that prices both the cost and the outcome side. Frontier-everything is a demo posture; the production posture is measured, per intent, on your own traffic — and the measurement is the difference between a voice agent that pays for itself and one that does not.
Published 29 August 2026.