AI unit economics: cost per token vs. cost per outcome
AI unit economics relates the cost of AI-enabled work to a defined unit of output or value. Cost per token tells you what each token costs. Cost per task divides spending by the number of tasks attempted or completed, depending on what you count. Cost per successful outcome divides spending by the number of results that meet the team's definition of success.
The FinOps Foundation's unit-economics guidance distinguishes technical units from business-oriented measures. Both can be useful, but they answer different questions.
Explore Dome: Model Broker · Docs: LLM gateway.
Define which costs and outcomes to count
Suppose an agent drafts support responses. A token-price comparison describes one input cost. It does not capture how many attempts are needed, whether the drafts are accepted, or how much review and rework they require.
Before calculating a metric, specify:
- The workload and time interval.
- Which model, tool, infrastructure, and review costs are included.
- Whether retries and failed attempts remain in the cost total.
- What counts as an attempted task.
- What qualifies as a successful outcome.
Counting drafts generated gives a different result from counting responses accepted by the support team. Either measure can be useful, but label it clearly so readers know what you counted.
Token economics examines the cost and value of token-based AI use. Token metering supplies usage counts; pair those counts with accepted responses to assess whether the spending produced useful work.
Explore Dome: Audit · Docs: Audit events.
Lower total cost doesn't always mean lower cost per result
Consider a hypothetical comparison with the same acceptance criterion and measurement scope:
| Configuration | Total measured cost | Accepted responses | Cost per accepted response |
|---|---|---|---|
| A | $120 | 80 | $1.50 |
| B | $150 | 120 | $1.25 |
Configuration B costs more overall but delivers each accepted response for $0.25 less. Before choosing it, also compare quality, latency, demand, and any costs omitted here.
These are illustrative numbers, not provider prices or benchmark results. The calculation is total measured cost divided by accepted outcomes within the same scope and interval.
Include the cost of failed attempts when calculating the cost of delivering accepted outcomes. If the team uses different acceptance criteria for the two configurations, it is no longer comparing the same kind of result.
Explore Dome: Model Broker · Docs: Configure pools.
Find out what changed when costs rise
A rising cost per outcome can come from higher input prices, longer prompts, more retries, lower acceptance, or increased review work. Check which of those factors changed before assuming the model price is the cause.
Track each workload separately before combining totals. Averaging legal reviews with support summaries can hide a cost increase in one kind of work.
Dome's routed usage and audit information can contribute model-consumption and attribution data. Business completion, accepted quality, human effort, and final provider billing may require other sources. State which costs and outcome measures are included, and where the data comes from.
See cost allocation to assign costs to owners, and spend governance to set budgets and handle exceptions.
Explore Dome: Audit · Docs: Audit events.