Blended Cost: One Number for "Good Enough at the Best Price" (11 of 11)

A rate card tells you what a token costs. It does not tell you what a result costs.

That gap is the whole game. Two models can sit side by side on a pricing page at almost the same number, and one of them can quietly cost you three times as much to get the same job done — because it’s wordier, or it fails more often, or both. The price tag is honest about the token and silent about everything that happens after.

This is the finale of the series, and it’s where every thread we’ve pulled gets tied into one knot. Across ten posts we’ve described a harness — the complete, task-specific machine that surrounds a language model and makes it reliably do a defined piece of work: prompt architecture, input preparation, structured outputs, validation, recovery, routing, evaluation, observability. Blended cost is the number that machine spends all its effort earning the right to print — the price per useful unit of work, folded down to one honest figure. It looks like a dollar amount. It’s actually the whole harness, compressed. Let’s open the box.

See it live: move the slider on the heatmap and watch the ★ jump between models — that’s blended cost doing its job, in real time.

What “blended” is hiding

When you glance at the heatmap, the cost figure for each model looks like one clean number. Behind it are four ingredients, and each one is a component of the harness and a post in this series.

The first is true per-token cost — not the rate card, the reconciled cost. The harness records the list price of every call, compares it against what the providers actually invoiced us, and derives a correction. The figure you see is anchored to money that changed hands, not to a pricing page that may not survive contact with caching, batch lanes, and the occasional billing quirk. That’s the story in We reconcile against the invoice.

The second is token shape — the task’s real ratio of input to output. This matters more than people expect, because output usually costs several times more than input. A task that reads a long document and emits five bullets is mostly cheap input. A task that reads a little and writes a lot is the opposite. The harness measures that ratio from production traffic, per task, rather than guessing — the subject of What a token really costs.

The third is the lane — batch or sync. Work that can wait runs as a batch at a discount; work that can’t runs synchronously at full freight. The bench has a cost mode toggle so you can see each model priced in the lane you’d actually use, which is part of why the harness treats batch, sync, and prompts as data rather than afterthoughts.

The fourth is the one most comparisons forget entirely: the success rate.

Dividing by reality

Here is the move that makes blended cost honest, and it’s almost embarrassingly simple.

A model that fails roughly one call in five doesn’t do four-fifths of the job for four-fifths of the price. It does the whole job — eventually — but you paid for the failed attempts along the way. Five tries to get four clean results means you’ve spent about 1.25× the per-call price for each useful answer. The failures don’t show up in a demo. They show up on the invoice.

So the harness divides cost by the success rate on that exact capability. Unreliability stops being a footnote and becomes what it really is: higher cost. A model that’s cheap per token but flaky gets shown as expensive, because for your purposes it is. (The harness floors the success rate so a near-broken model reads as very expensive rather than infinitely so — a sensible number beats an exploding one.) That success rate isn’t a vibe; it’s the running track record behind engineered reliability — structured-output recovery, error handling, the works — measured per task by the harness that runs it all day.

The upshot is one line you can hold in your head: cheap-per-token is not the same as cheap-per-result. Blended cost is the second thing, and it’s the only one worth ranking on.

How it shows up on the bench

The harness expresses blended cost as “$ per 1M input tokens” — but with the task’s typical output folded in at its measured ratio, then penalized by the success rate. So it’s denominated in something familiar, while quietly accounting for everything the familiar number leaves out.

Concretely, the spread is wide. A frontier model might list around $15–$26 per million tokens; an efficient one around $0.25–$1.50 — a 30–60× gap before you’ve folded in anything. Now layer on verbosity and reliability, and the ranking can shift again. A frontier model that nails a task on the first try every time can sometimes blend down closer to a chatty mid-tier model that needs retries. Usually it doesn’t — but the point is that you can’t know which case you’re in by reading the rate card. You have to do the blend. The harness does it for every (task × model) pair, continuously — and the bench is where you read the result off.

The ★ and the overpay multiples

This is where the number turns into a decision.

On the heatmap, one model per task wears a ★ — the cheapest qualifier. It’s the model with the lowest blended cost among those that clear the quality bar at wherever you’ve set the slider. Two halves matter equally there. “Lowest blended cost” is everything above. “Clear the quality bar” is the other arc of this series: the 0–10 score from how we measure quality, and the rule that a model only counts as clearing the bar when the harness is actually sure it does — the confidence story in Confidence, not just scores. A high score with a wide interval hasn’t earned the ★. It hasn’t earned anything yet.

Next to every other qualifying model, the bench shows an overpay multiple — how much more it costs, per useful result, than the ★. Not how much smarter it is. How much more you’d pay for an answer this task already gets from the cheapest option that’s good enough. A 4× overpay multiple is a number a finance team understands without a translator.

That’s the entire Part 1 thesis, computed: good enough at the lowest practical price, with the receipts attached.

Why the blend is the honest unit

No single ingredient is the whole story, and that’s exactly the point.

Per-token cost alone rewards the wordy and the flaky. Quality alone sends you to the frontier for jobs that don’t need it. Reliability alone says nothing about price. Each is a partial truth that, taken on its own, makes a confident and wrong recommendation. Blended-cost-at-a-quality-bar is the figure that refuses to let any one of them lie, because it forces all three to settle their differences inside a single comparable number.

This is the difference between a leaderboard and a decision. A leaderboard gives you a rank — a single ordering that pretends every task wants the same thing. Blended cost gives you a choice you can defend: this model, for this job, at this quality bar, at this price, and here’s precisely how much the alternatives would cost you. One is a trophy. The other is a budget.

Move the slider

Here’s what we’d most like you to do, because it’s where the whole series becomes real in about ten seconds.

Open the heatmap and drag the quality slider. Watch the ★ move from task to task. At a relaxed bar, the cheapest qualifiers do most of the work and the overpay multiples on the frontier get embarrassing. Tighten the bar — only a model at least 90% as good as the best will do — and the ★ migrates upward where the work genuinely demands it, while staying put everywhere it doesn’t. Flip the cost mode toggle and the whole board reprices into your lane.

What falls out, automatically, is a portfolio — a different right-sized model for each task, each one the cheapest option that’s provably good enough at the bar you chose. Nobody picked the biggest model. Nobody picked the most famous one. The harness picked the right one for each job, and it can show its work. Every figure traces back through reconciled invoices, measured token shapes, and a confidence interval — auditable down to the dated snapshot it came from.

And that snapshot is the point of the bench. The heatmap you’ve been dragging isn’t the harness — it’s the harness’s readout: what a stable machine prints when you hold prompts, validation, evaluation, and cost measurement constant and let only the model vary. That’s exactly what makes the comparison mean something, and it’s what makes the ★ trustworthy. A lab harness — a fixed set of curated prompts, run once, scored, ranked — is useful for mapping the frontier and then it’s done. What sits behind this bench is a production harness: the real, continuous, task-specific machine that runs messy single-pass work all day, and the heatmap is simply the dated readout it prints. The benchmark isn’t the achievement. It’s the proof the harness’s “good enough” picks are honest.

That’s what Part 1 promised, now fully mechanized. “Which model is best?” was never the question, because best is a property of a leaderboard and your work doesn’t live on a leaderboard — it lives in production, one messy call at a time, where the only thing that matters is good enough, reliably, at the lowest price you can defend. The harness turns that sentence into a number. The number is blended cost. And because the machine is built around the task, the model inside it is an interchangeable part — when a better one ships, it changes a row of configuration, the harness re-blends, and the ★ moves. The machine outlives every model that passes through it.

The advantage in enterprise AI won’t go to the teams with the biggest model. It’ll go to the ones who know which model to use, when, and for what — and can prove it down to the cent.

Explore the live bench at llm-bench.kapualabs.com, move the slider, and watch the portfolio reshape itself. If the series was useful, subscribe — we keep the snapshots coming as the models, and the math, keep changing.