Which AI model for which task? Match it to the job, not the benchmark

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 backs this up. The RouteLLM research from LMSYS and UC Berkeley reports cost reductions of up to 85 percent while holding about 95 percent of the stronger model's quality on MT Bench, precisely because most production traffic never needed the expensive model in the first place. Your own number depends on your task mix, but the direction of it is not in doubt.

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 $2 per million input tokens and $10 per million output tokens as the base, so it is 1x. Anthropic launched it at that price as an introductory rate, then made it the standard price and cancelled the rise to $3 / $15 that was due on 1 September 2026, so this whole table is re-based on the lower figure. Every other model below is its published input price divided by $2. Named models, real numbers, sorted cheapest first:

Prices re-checked on 15 September 2026 against the published price lists from Anthropic, OpenAI and Google Gemini. The two Kimi rows were cross-checked against a September 2026 price tracker because Moonshot's own page would not load for us. Two rows carry an expiry date. GPT-5.6 Sol is on promotional pricing that OpenAI says is available at least through 21 November 2026. Gemini 3.6 Flash is on an introductory rate through 31 December 2026 that doubles to $1.50 / $7.50 on 1 January 2027, and Gemini 3.7 and 3.8 Flash sit on the same schedule. Prices move every few weeks, so re-check before you commit. The multipliers move far more slowly, with one exception worth knowing: when the base itself moves, as Sonnet 5 did here, every row moves with it, which is why we re-base the whole table rather than patching single rows.

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 workhorse price war ended in a tie. Claude Sonnet 5, Gemini 3.1 Pro and GPT-5.6 Terra all charge $2 per million input tokens, and Sonnet 5 is the cheapest of the three on output at $10 against $12. Do not read much into that output gap: Anthropic documents that Claude 4.7 and later models, Sonnet 5 included, use a newer tokenizer that produces about 30 percent more tokens for the same text than its previous one, so price per token is not price per page. Treat the three as level on cost and pick on fit. One caveat still stands: above a 200K-token prompt, Gemini 3.1 Pro reprices to $4 / $18, so a long-context workload is not getting the headline rate.

Kimi is no longer the budget choice in either tier. GPT-5.6 Luna now undercuts Kimi K2.6 by almost 5x on input, $0.20 against $0.95. And Kimi K3, launched in July 2026 at $3 / $15, is now the most expensive workhorse on the list at 1.5x Claude Sonnet 5. If your mental model is "Kimi is the cheap option", check which Kimi you are calling and what it is up against.

The whole ladder is now 50x, and the gap opened up at the bottom. GPT-5.6 Luna at $0.20 to Claude Fable 5 at $10 is a 50x spread. Inside one vendor it is narrower: Claude Haiku 4.5 at $1 to Claude Opus 5 at $5 is a 5x step, and it takes Fable 5 to reach 10x. So the biggest wins on this table now come from moving work down to the cheapest tier and cutting output length, not from swapping one workhorse for another.

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 and Gemini 3.1 Pro are level at exactly 1x on input, Kimi K3 sits at 1.5x, and all four 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 is exactly what we logged when we ran Manus for five days on real client deliverables: two tasks came back near production quality and two needed a third of the output rewritten, and only the per-task record made that visible. That measurement is cheap to set up and it is the difference between routing that saves money and routing that quietly costs you more.