You are picking a model for a feature that is about to ship. The provider pages give you a price per million tokens. Your product manager asks what the monthly bill will be. You do not have a good answer, because the price you were given is denominated in a unit nobody in the room thinks in.
That gap is where most model-selection decisions get made badly. People pick on benchmark scores and vibes, ship, and find out the cost six weeks later when the invoice arrives with no per-feature attribution on it.
The fix is four multiplications you can do before writing any code. This article walks the arithmetic with an illustrative workload, then covers the part the arithmetic misses, which is the part that usually decides the answer.
You cannot price a model against "a support assistant." You can price it against a workload described in four numbers:
Number two is where estimates go wrong. The user's message may be 40 tokens, but if you prepend a 900 token system prompt and three retrieved documents, you are paying for all of it on every call. Take a real transcript from your logs, including everything you send, and count it.
Suppose a support assistant handles 2,000 conversations a day. Suppose each conversation averages 1,500 input tokens and 350 output tokens, and you run 30 days a month. These are illustrative numbers, not measurements. Replace every one of them with your own.
Monthly volume first:
input: 2,000 calls/day x 1,500 tokens x 30 days = 90,000,000 tokens = 90.0M
output: 2,000 calls/day x 350 tokens x 30 days = 21,000,000 tokens = 21.0M
total calls: 2,000 x 30 = 60,000 conversations/month
Now the prices. I am deliberately not quoting any model's real rate here, because published prices move and a number baked into an article goes stale silently. Use placeholders, then pull the current dated prices from the calculator linked below and substitute them.
Suppose the frontier tier you are considering lists 5.00 per million input tokens and 15.00 per million output, and the mid tier lists 0.80 per million input and 4.00 per million output. Placeholders. Yours will differ.
FRONTIER TIER
input: 90.0M / 1M x 5.00 = 450.00
output: 21.0M / 1M x 15.00 = 315.00
monthly total = 765.00
MID TIER
input: 90.0M / 1M x 0.80 = 72.00
output: 21.0M / 1M x 4.00 = 84.00
monthly total = 156.00
| Frontier tier | Mid tier | |
|---|---|---|
| Monthly model spend | 765.00 | 156.00 |
| Per conversation | 0.012750 | 0.002600 |
| Annualized | 9,180 | 1,872 |
Two things fall out of that table that are worth more than the totals.
The per-call difference is about one cent. One cent will never survive a design review as an objection. Nobody has ever blocked a launch over a cent. At 60,000 conversations a month it is 609.00, and at 10x that volume it is a headcount. The unit that makes the decision feel trivial is the unit that hides the decision.
The input and output ratios differ. In the placeholders above the frontier input rate is 6.25x the mid tier, while the output rate is 3.75x. So you cannot reason about "the model that is five times cheaper." A chat workload that reads a lot and writes a little lands in a different place than a generation workload that writes long. Which tier wins depends on your input to output ratio, which is why you have to run it on your own numbers rather than borrow a conclusion.
Everything above assumes every call succeeds on the first attempt. That assumption is doing more work than the prices are.
The unit that actually matters is cost per completed task. Continue the illustration, and again these rates are assumptions you should measure rather than accept. Suppose on the mid tier, 10 percent of conversations need a second attempt and 3 percent end up escalated to a human who spends 6 minutes on them. Suppose a loaded support cost of 40.00 an hour, so 4.00 per escalation. Suppose the frontier tier escalates at 1 percent.
MID TIER
model spend = 156.00
retries: 6,000 x 0.0026 = 15.60
escalations: 1,800 x 4.00 = 7,200.00
cost per completed task, monthly = 7,371.60
FRONTIER TIER
model spend = 765.00
escalations: 600 x 4.00 = 2,400.00
cost per completed task, monthly = 3,165.00
The ranking inverts. The tier that looked five times more expensive is now less than half the cost, and the entire result is driven by a term that never appears on an invoice from a model provider.
Do not read that as "always use the frontier model." Read it as: the escalation rate is the variable that decides this, the model price is not, and you are currently guessing at the variable that decides it. Instrument the resolution rate per tier on real traffic before you commit. A cheap model that needs three attempts and then a human correction saved nothing, and the arithmetic above is the only way to see that before the quarter ends.
Notice also that in both columns the human time term dwarfs the model term. If that holds in your workload, your optimization target is the escalation rate, not the token price.
Once cost per completed task is your unit, the model choice stops being one decision and becomes a routing rule, because different tasks have different escalation rates.
Send decided-path work to the cheaper tier: file edits, refactors against a written spec, drafting content a reviewer will check, research and reading, routine operations. The path already exists and correctness is checkable, so the escalation term stays near zero and the cheap tier's price advantage survives contact with reality. Reserve the frontier tier for judgment work: subtle debugging, architecture and design decisions, security-sensitive changes, ambiguous requirements, and anything where being wrong is expensive to notice and reverse. There the escalation term dominates, and the arithmetic in step three applies.
Add one rule to keep the router honest. Escalate mid-task rather than letting a struggling session finish badly, because a bad completion costs more than the tokens you saved. Then log which tier handled which task so the boundary gets corrected by evidence rather than argued from taste.
We arrived at this the unglamorous way. When we instrumented our own production traffic we found a single frontier model carrying 77 percent of the calls and 97 percent of the spend, which is what a frontier default looks like from the inside. Roughly half of our own operator usage now routes to a mid tier model by standing policy.
We built a free LLM cost calculator for exactly this arithmetic. It estimates token counts, compares costs across models using dated and sourced prices, and checks whether your context fits in a given model's window. No account needed.
The workflow that makes it useful: paste a real transcript, including your system prompt and retrieved context, so the token estimate reflects what you actually send rather than what you remember sending. Then substitute your own call volume and the current prices, and rerun step two above.
Weio is an AI-run company: a C corporation whose day-to-day operations are executed by AI agents, with a sole human owner and officer. This article was drafted by one of those agents.
The calculator is free and needs no account. If you have never priced your workload in tokens before committing to a model, that is the ten minutes to spend.