Cost per Token vs Cost per Outcome

What is cost per token?

Cost per token is the unit price a model provider charges for the input and output tokens of a request. It is the LLM equivalent of a per-GB or per-vCPU line item — a clean, low-level metric that shows up directly on the bill and is trivial to compare across models.

Because it is so easy to observe, cost per token becomes the default lever teams reach for: swap to a cheaper model, trim the prompt, cap the output length. Each move visibly reduces the per-request number, and the dashboard turns green.

The problem is that cost per token measures effort, not value. It tells you what you paid to run the model once — not whether that run produced anything you could safely ship to production.

What is cost per outcome?

Cost per outcome is the total spend required to deliver one verified, successful result. It rolls up every token across the whole attempt — the first try, the retries, the tool calls, the re-prompts after a bad answer — and divides by the number of outcomes that actually passed a correctness check.

In production cloud operations the outcome is concrete: a scaling change that held, a misconfiguration that was actually remediated, a cost anomaly correctly root-caused, an incident closed and confirmed resolved. A token spent on an answer that gets rolled back is not a cheaper outcome — it is a more expensive one, because you also pay for the rollback and the human review it triggers.

Cost per outcome is the FinOps metric that maps to business value. It is harder to measure than cost per token precisely because it requires a definition of "success" — and a mechanism that checks each result against it.

Why does optimizing cost per token alone backfire?

When you optimize the input metric in isolation, you push cost into the parts of the workflow the metric cannot see. A cheaper, less capable model hallucinates more often; each hallucination triggers a retry, a re-prompt, or a wrong action that has to be undone — and every one of those costs real tokens plus real engineer time.

The failure has a shape. A model that is right 95% of the time on the first pass can be dramatically cheaper per outcome than one that is right 70% of the time, even if the second model is half the price per token — because the retries, verification failures, and remediation of wrong actions dominate the bill. The visible per-token number went down; the invisible cost-per-outcome number went up.

In production this is worse than a rounding error. An unverified agent action on live infrastructure — a scale-down that starves a service, a policy change that opens an egress path — is not a cheap token, it is an incident. Cost-per-token accounting never sees it. Cost-per-outcome accounting is the only view that prices it correctly.

How does DARV's Verify step turn tokens into outcomes?

CloudThinker runs the DARV loop — Detect, Analyze, Remediate, Verify. The Verify step is what converts cost per token into cost per successful output: after an agent remediates, the platform independently confirms the result held before the outcome counts as delivered. Unverified work does not get to masquerade as a finished outcome.

Without a Verify step, an agent that "finished" and an agent that produced garbage look identical on a token dashboard — both spent tokens, both returned. Verify draws the line: it re-checks the target state, confirms the metric moved the right way, and rolls back if it did not. Only a verified result increments the outcome count, which means cost per outcome becomes something you can actually measure instead of assume.

Verify also caps the blast radius of the retry problem. Because every attempt runs under brokered credentials in a sandboxed execution environment with tamper-evident audit, a failed verification is contained and reversible — the platform pays a bounded re-run cost, not an unbounded production-incident cost. That containment is what makes it safe to let cost per outcome, not cost per token, be the number you optimize.

How does graduated autonomy protect cost per outcome?

Graduated autonomy (L1–L4) is the second lever on cost per outcome. New workflows start with a human on the loop reviewing every action; as a workflow proves a low verified-failure rate, it earns more autonomy. You spend human-review budget where outcomes are still uncertain and withdraw it where they are proven — so oversight cost tracks outcome risk instead of running flat.

The pairing matters: Verify measures whether an outcome succeeded, and graduated autonomy decides how much it should cost to supervise the next one. Engineers stay on the loop, not in it — reviewing outcomes and adjusting guardrails rather than babysitting every token — which is how a team drives cost per outcome down without accepting the hidden cost that unsupervised, unverified token-cheapness creates.

Cost per token vs cost per outcome, side by side

Two metrics for the same spend. One is easy to measure and easy to game; the other is harder to measure and aligned with business value.

How to shift your FinOps from cost per token to cost per outcome

You do not stop tracking tokens. You add the outcome layer on top so the token number stops lying to you. The shift is a sequenced measurement change, not a tooling rip-out.

1. Step 1

   Define what "success" means for each workflow

   For every agentic workflow — an incident remediation, a cost-anomaly fix, a scaling action — write down the concrete, checkable condition that says it worked: the metric that must move, the state that must hold. Without this, cost per outcome is undefined and you are stuck with cost per token by default.

2. Step 2

   Attach a Verify step to every action

   Make verification part of the loop, not an afterthought. In CloudThinker this is the Verify step of DARV: after remediation, the platform independently confirms the success condition and rolls back if it fails. Now only verified work counts, and you can finally divide total spend by real outcomes.

3. Step 3

   Tune autonomy to the verified-failure rate

   Use graduated autonomy (L1–L4) to spend human review where it pays. Keep new workflows human-on-the-loop; as a workflow shows a low verified-failure rate, promote it to higher autonomy. Route model choice by outcome quality, not sticker price — the cheapest per-token model that clears verification wins on cost per outcome.

Frequently asked questions

Is cost per token or cost per outcome the better metric?

They answer different questions, but only cost per outcome maps to business value. Cost per token tells you the unit price of running a model once; cost per outcome tells you what it actually costs to deliver a verified, successful result. Track both — but optimize for cost per outcome, and use cost per token as one input to it rather than the goal.

Why does a cheaper model sometimes cost more?

Because a lower per-token price does not guarantee a lower per-outcome price. A cheaper model that is less accurate hallucinates and fails verification more often, and each failure forces retries, re-prompts, or the remediation of a wrong action — all of which spend additional tokens plus engineer time. A model that is right on the first pass more often can be cheaper per outcome even at a higher per-token price.

How does the DARV loop relate to cost per outcome?

DARV — Detect, Analyze, Remediate, Verify — is CloudThinker's execution loop, and its Verify step is what makes cost per outcome measurable. Verify independently confirms that a remediation actually held before the result counts as delivered, and rolls back if it did not. Without a Verify step, a successful run and a failed run look identical on a token dashboard, so cost per outcome cannot be computed honestly.

Does optimizing cost per outcome mean spending more on tokens?

Not necessarily — often the opposite. Once you count only verified outcomes, you can route inexpensive models to the tasks they handle reliably and reserve stronger models for the tasks that would otherwise fail verification. The result is lower total spend per successful result, because you stop paying repeatedly for work that never counted.

How does CloudThinker keep unverified agent actions from inflating cost?

Every agent action runs under brokered credentials in a sandboxed execution environment with tamper-evident audit, and the DARV Verify step confirms the result before it counts. Graduated autonomy (L1–L4) keeps a human on the loop for workflows that have not yet earned trust. Together these bound the retry and rollback cost of a failed attempt, so a wrong action is a contained, reversible re-run rather than an open-ended production incident.