Match the model to the task, not to the benchmark, and the bill drops

Deciding which AI model for which task is now the highest-leverage cost decision most teams have, and almost nobody makes it deliberately. What happens instead is that somebody picks the model that topped a benchmark, wires it into everything, and the bill becomes a fact of life.

The problem is that the tasks are not the same shape. Tagging an inbound email, extracting five fields from an invoice, and refactoring a multi-file codebase are three completely different jobs, and only one of them needs a frontier model. Running all three on the top tier means paying frontier prices for work a model costing a tenth as much would have done identically.

The counter-move is routing: send each request to the cheapest model that can actually handle it. Published work on routing layers, including the RouteLLM research, reports cost reductions in the region of 40 to 85 percent with no visible drop in answer quality, precisely because most production traffic never needed the expensive model in the first place.

Two things make this hard in practice, and this guide fixes both. First, price lists move constantly, so memorising dollar figures is a waste of time. Second, sticker price is the wrong metric anyway. Let us deal with both.

We are using Claude Sonnet 5 at $3 per million input tokens and $15 per million output tokens as the base, so it is 1x. Every other model below is its published input price divided by that. Named models, real numbers, sorted cheapest first:

Prices checked July 2026 and they move every few weeks, so re-check the live price list before you commit. The multipliers move far more slowly, which is the whole point of running the table this way.

Four things jump out that you would never spot on a single vendor's pricing page.

Claude Fable 5 is exactly 2x Claude Opus 5. $10 against $5 on input, $50 against $25 on output, the same ratio on both. So the question is never "is the top model better", it is "is it more than twice as valuable on this specific task". For a nightly summarisation job, obviously not. For a migration that would take an engineer three days by hand, obviously yes.

The cheapest workhorse is Gemini 3.1 Pro, not anything from Anthropic or OpenAI. At $2 / $12 it undercuts GPT-5.6 Terra and Claude Sonnet 5 while sitting in the same tier. One caveat that is easy to miss: above a 200K-token prompt, Gemini 3.1 Pro reprices to about $4 / $18, so a long-context workload is not getting the headline rate.

Kimi is no longer automatically the cheap option. Kimi K2.6 is the cheapest model here at $0.95 / $4, but K3 launched in July 2026 at $3 / $15, which is roughly triple K2.6 and lands exactly on Claude Sonnet 5's rate. If your mental model is "Kimi is the budget choice", check which Kimi you are actually calling.

The whole ladder is 10x, and cheap to frontier is only 5x. Claude Haiku 4.5 at $1 to Claude Opus 5 at $5 is a 5x step, and it takes Claude Fable 5 at $10 to reach a full order of magnitude. That is narrower than most people assume, and it means the biggest wins come from moving work down a tier and cutting output length, not from hunting for an exotic vendor.

The equivalents, side by side

When someone says "use Opus 5" and you are on a different provider, this is the row you want. The tiers line up cleanly even though the naming does not.

Read those rows as rough peers on price and job, not as identical products. Claude Sonnet 5, GPT-5.6 Terra, Gemini 3.1 Pro and Kimi K3 all sit within about 0.67x to 1x of each other and all do the same job. Which one wins on your workload is a question your own evaluation answers, not a benchmark table.

The open-weight column is the one that changes the arithmetic most. Independent coding benchmarks published this year have shown open-weight models matching a frontier model's results at roughly a third of the cost while running about four times slower. That trade is excellent for an overnight batch job and terrible for anything a customer is sitting waiting on. Latency is a cost too, it just lands on a different line.

One more lever that is free and almost nobody uses: cached input. Gemini 3.6 Flash and Kimi K3 both bill cached input at around 90 percent off, and the GPT-5.6 family does the same. If every request shares a large fixed preamble, that discount is larger than most tier changes.

This is the part that changes decisions, and it is simple arithmetic.

A model that fails a task has not saved you anything. You retry it, a human fixes it, or worse, nobody notices and the wrong output flows downstream. So the number that matters is not price per million tokens. It is price per completed task.

If a model fails a fraction of the time, the expected number of runs to get one good result is 1 divided by the success rate. Multiply that by the sticker price and you get effective cost:

Run the numbers on two models. Model A costs $0.50 per million tokens and fails 40 percent of the time. Model B costs $0.70 and fails 5 percent of the time.

• Model A: 0.50 / 0.60 = $0.83 effective. That is 1.67x its own sticker price.
• Model B: 0.70 / 0.95 = $0.74 effective.

The model that looked 29 percent cheaper is actually 13 percent more expensive, and that is before you count the human time spent catching the failures. This is why "we switched to the cheap model and our costs went up" is a real thing that happens to real teams.

The practical implication is that you cannot route intelligently without measuring failure rate per task type. Not overall quality, not a benchmark score. Failure rate on your work. That measurement is cheap to set up and it is the difference between routing that saves money and routing that quietly costs you more.