In the last lesson you learned to estimate the system bill: cost per request times requests times users. Now comes the trap that catches smart builders anyway — picking the model with the lowest token price and calling it the cheapest option.

Token price is not total cost. Retries, human correction time, and failed tasks all cost money. The number that matters is cost per useful result: everything you spent divided by the results you actually accepted.

The cheapest sticker often loses

Imagine you need one working function for a ByeBuy-style product page. Three workflows compete:

Workflow A: cheap model, three retries. The token price is tiny. But the first two attempts fail tests, the third needs twenty minutes of your fixes. You paid for four rounds of tokens plus twenty minutes of a human’s time.

Workflow B: strong model, once. The token price is 5–10× higher. It passes tests the first time. You review for five minutes and accept.

Workflow C: triage plus strong model. A fast inexpensive model handles the easy draft and classifies the problem; the strong model handles only the hard final step. Two models, each doing what fits — the routing idea from Class 10.

Which is cheapest? You cannot know from the pricing page. You have to count everything.

Count what the pricing page leaves out

Total cost per accepted result has four parts:

1. Token cost. All input, output, reasoning, and loop tokens across every attempt. 2. Retry cost. Every failed attempt still bills. Three cheap attempts can exceed one strong attempt. 3. Human correction time. Your time has a value. Twenty minutes of debugging “cheap” output is an operating cost, even when no invoice shows it. 4. Failure cost. Some results are never accepted — the task gets abandoned, the user leaves, the bug ships. That wasted spend belongs in the average too.

Put a rough hourly value on your own time (pick any honest number, say $30–$100/hour) and the comparison becomes concrete fast.

The comparison table

Here is a worked example with invented-but-realistic numbers. Read it as a method, not as current prices — check OpenRouter models when you run your own.

The token column says A wins. The total column says A costs five times more. For high-value or difficult work, the expensive model is the cheap option.

That flips for easy work. If the cheap model succeeds first try on simple summaries with a two-minute skim, its total wins easily. This is exactly the Class 08 selection card in action: task difficulty decides, not brand loyalty.

When each workflow wins

The triage pattern deserves special attention because it combines everything you have learned: a fast model does bulk classification from Class 08, routing sends hard cases onward from Class 10, clean context keeps both steps cheap from Class 09.

A quick method you can reuse

For any task you actually run:

1. Fix the task and the acceptance test first (same repo, same prompt, same rubric — the Class 11 fair-test habit). 2. Run each candidate workflow 5–10 times. Record attempts, tokens or dollars, and your correction minutes. 3. Compute: (total token dollars + hours × hourly value) ÷ accepted results. 4. Pick the lowest total — and write down why, so future you does not re-litigate it.

One fair test beats ten leaderboard opinions for your specific workload.

Practical exercise: choose the lower total-cost option

Finish line: a defended choice with numbers, not a preference.

You run a product-description task, 500 items per week:

• Option A: Cheap model at $0.008 per attempt. Succeeds cleanly 40% of the time; otherwise needs 15 minutes of editing. Roughly 2.2 attempts per accepted item.
• Option B: Strong model at $0.07 per attempt. Succeeds cleanly 90% of the time; needs 4 minutes of review on average. Roughly 1.1 attempts per accepted item.
• Value your editing time at $40/hour.

Questions:

1. What is the token cost per accepted item for each option? 2. What is the human-time cost per accepted item for each option? 3. Which option has the lower total cost per accepted item, and by roughly how much per week across 500 items? 4. At what point would Option A win — for example, if the task became much easier, or your review time dropped to near zero?

Verify: check your arithmetic by computing one item fully before multiplying by 500. Common failure mode: multiplying attempts × price but forgetting the failed attempts also consumed human review time.

Check your understanding

1. What is cost per useful result, and how does it differ from token price? 2. Why can a model with 5× higher token prices still be the cheaper choice? 3. What four parts make up the total cost of an accepted result? 4. When does the triage-plus-strong workflow beat either model alone? 5. How does this lesson connect to the Class 08 task-fit selection card?