Cost per Outcome, Not per Token: Reframing LLM Unit Economics

A document-extraction pipeline switched from gpt-5.4 ($2.50/$15.00 per 1M tokens) to deepseek-v3.2 ($0.14/$0.28) expecting an 18x cut in cost per token. Three weeks later the invoice was up 14%. The cheaper model parsed 71% of invoices cleanly on the first pass instead of 96%, so every miss triggered a retry, a longer correction prompt, and a chunk of human review. The per-token price fell through the floor; the per-document cost climbed. This article shows how to measure the unit that actually appears on your P&L — cost per business outcome — and when the raw per-token number is still the right thing to optimize.

The unit you bill internally is not the unit that matters

A token is an input to your system, not an output of it. Nobody downstream cares how many tokens you spent — they care about a resolved support ticket, a qualified lead, a processed document, a passing code review. Those are the units your business runs on, and they are what your model spend should be denominated in.

The per-token price is seductive because it is printed on the pricing page and varies by two orders of magnitude across models. gemini-2.5-flash-lite at $0.10/$0.40 looks 50x cheaper than claude-opus-4.7 at $5.00/$25.00. But the pricing page hides three multipliers that sit between a token and an outcome:

• Tokens per attempt. A weaker model often needs more few-shot examples, longer chain-of-thought, or more verbose output to reach the same answer. More tokens per attempt at a lower price can net out flat — or worse.
• Attempts per outcome. First-pass success below 100% means retries. Each retry re-bills the full input prompt, because input tokens are resent every call.
• Escalation per miss. Whatever the model can't do gets handed to a human, a more expensive model, or a fallback path. That cost belongs in the denominator too.

The formula that captures all three:

cost_per_outcome = tokens_per_attempt_cost / success_rate
                 + escalation_cost * (1 - success_rate)

where tokens_per_attempt_cost = input_tokens × input_price + output_tokens × output_price.

Each multiplier is independent, and any one of them can dominate. A model can be best on tokens per attempt yet worst on attempts per outcome; a model can be middling on both yet win because it never escalates. That is why you cannot read the winner off the pricing page — the three terms interact, and the interaction is workload-specific.

Worked example 1: support ticket resolution

A tier-1 support agent reads a ticket plus retrieved context (~3,500 input tokens) and writes a resolution (~600 output tokens). "Resolved" means the customer doesn't reopen. Below, prices are the discounted pass-through rates where available, and a human escalation costs $4.00 in agent time per missed ticket.

The per-token cheapest model, claude-haiku-4.5, is 4.3x more expensive per resolved ticket than claude-sonnet-4.6. The escalation column dominates everything else: at 68% first-pass resolution, 32% of tickets hit the $4.00 human path, and that $1.28 swamps the fractions of a cent in model cost. The lesson is not "always buy the premium model" — it's that the denominator (success rate) moves cost per outcome far more than the per-token price does. Note also that gpt-5.4 and claude-sonnet-4.6 differ by only 17% per resolved ticket despite gpt-5.4 carrying the lower sticker price; the four-point gap in first-pass resolution nearly cancels its per-token advantage.

Worked example 2: qualified-lead enrichment

Here the economics flip, because there is no expensive escalation path — a missed enrichment is just retried automatically until valid JSON comes back. Each call sends ~1,200 input tokens and returns ~300 output tokens of structured fields.

With no human in the loop, the retry multiplier is small (1.22x at worst) and never enough to overcome a 4x–18x per-token gap. gemini-2.5-flash-lite wins decisively here at $0.00029 per lead. This is the case where the cheap model is genuinely cheap — and the next section explains exactly why.

Worked example 3: document processing with caching

A contract-review pipeline reads a 60-page document. The system prompt, extraction schema, and few-shot examples (~9,000 tokens) are identical on every call; only the document changes. That stable prefix is cacheable, and cache reads bill at 0.1x the input rate — a 90% discount. The columns below isolate the prefix cost: what those 9,000 fixed tokens cost at full price versus on a cache hit, plus the per-document output.

(Prefix column is the ~9,000 fixed scaffold tokens; on a cache hit they re-bill at 0.1x. The variable document body and output bill at full rate.) The 90% cache discount cuts the prefix cost by an order of magnitude on every model, but it matters most where the prefix is large and the per-token price is high — for claude-opus-4.7 it removes $0.0345 per document. Caching is the single biggest lever for any workflow with a fixed prompt scaffold, and it changes nothing in your application logic beyond marking the prefix. For batch-eligible work, the 50%-off async tier (both input and output, 24h turnaround) stacks on top of this and is worth modeling separately for any non-interactive document run.

How to actually measure this

You cannot get success rate or tokens-per-attempt from a vendor benchmark. They come from your own production traces. The minimum instrumentation:

1. Log tokens per call (input and output separately) and tag each with the outcome it served.
2. Define the outcome and its success test unambiguously — "ticket not reopened in 72h," "JSON validates against schema," "extraction matches gold label." If you can't write the test, you can't compute the metric.
3. Track the escalation cost for misses: human minutes, fallback-model spend, or rework.
4. Compute cost per outcome weekly per model, not per token. Route on this number.

A useful sanity check: take any "we should switch to the cheaper model" proposal and ask for the proposed model's measured first-pass success rate on your traffic. If that number doesn't exist yet, the per-token comparison is premature. Run the candidate in shadow mode against a slice of live traffic for a week, score it against the same success test, and only then put the two cost-per-outcome figures side by side. A switch that survives that test is real; one justified by the pricing page alone is a guess.

When raw cost per token IS the right metric

The outcome framing is not universal. Cost per token is exactly right when all candidate models clear the quality bar and output is single-shot with fixed length. In that regime, success rate is ~100% across the board, there is no retry multiplier, and no escalation path exists — so the only variable left is price per token. Concrete cases:

• Embedding generation and deterministic classification into a small fixed label set, where modern small models hit near-ceiling accuracy and the cheapest valid option wins outright.
• High-volume, uniform transformations — short translations, format conversions, boilerplate normalization — where every model produces equivalent output and you are buying raw throughput.
• Worked example 2 above is essentially this case: no human escalation, near-equal validity once retries are cheap, so the per-token-cheapest model genuinely is the cheapest per outcome.

The tell is the shape of your success-rate column. If it's flat and near 100% across every candidate, stop computing cost per outcome — it adds nothing, and per-token price is the honest answer. The outcome framing earns its keep precisely when success rates diverge, because that divergence, not the sticker price, is what determines your real bill.

One more caveat: cost per outcome is a cost metric, not a quality metric. A model can be cheapest per resolved ticket while producing resolutions customers find curt or wrong in ways that don't trigger a reopen. Pair the cost number with a quality sample, and don't let a spreadsheet talk you into shipping a worse experience to save a cent.

The takeaway

Per-token price is an input cost; per-outcome cost is what your business pays. The gap between them is set by success rate, tokens per attempt, and escalation cost — and that gap can invert a 4x or 18x per-token advantage. Measure the three multipliers from your own traces, denominate spend in resolved tickets and processed documents, and route on that number. A structural per-token discount of −15% to −65% on the same model weights, plus a 90% cache read discount and a 50% async tier, all reduce the numerator — but they only pay off once you're optimizing the right ratio.

If you want to model these numbers against your own traffic on discounted pass-through pricing, Sign in to TokenMart and pull your token logs into the cost-per-outcome formula above.