AI Pricing Models: Why Token Cost Breaks Usage-Based and Subscription SaaS

Your AI feature has a price on the pricing page. Underneath it, the thing you actually pay for is tokens, and the token cost of serving one customer is not a number you set. It is a number the model, the prompt length, and the customer’s own behavior decide for you, call by call. That gap between the price you charge and the cost you incur is where AI pricing gets hard. It is why the pricing models that worked for cloud software are starting to buckle under AI features, and why more teams are looking at charging for outcomes instead.

Why does token cost break usage-based and subscription pricing?

Because the cost of one unit of work is variable and often invisible at the moment you set a price. A subscription assumes roughly predictable cost per user. A usage tier assumes a “unit” that maps to a stable cost. Metered tokens honor neither assumption, so both models start leaking margin the moment usage gets uneven.

Start with the token itself. The FinOps Foundation’s working group on GenAI pricing puts the problem plainly: “the cost per unit is not a fixed price. It is a distribution.” (finops.org) Three things move that distribution around. Output tokens are priced at a premium over input, often three to five times more, so a chatty answer costs more than a terse one for the same question. A stronger model costs more per token than the workhorse tier for the identical prompt. And because models are stateless, an agent re-sends the whole conversation history on every turn, so “the input token count for each new turn balloons” as a session runs long. Same feature, same customer, wildly different cost depending on how the session unfolds.

Now put that variable cost under a flat subscription. Two customers pay the same monthly fee. One runs a handful of short queries a week. The other has an agent looping over long documents all day, re-sending context on every turn and pulling the premium model for output. Their token cost differs by an order of magnitude, and your price does not move. The heavy user is subsidized by the light one, and if too many customers behave like the heavy one, the tier that looked profitable in the spreadsheet is underwater in the bill.

Simple usage-based pricing seems like the fix. Charge per call, or per thousand tokens, and the price tracks the cost. It tracks the cost, but it stops tracking the value. A customer who pays “per API call” has no idea what a call will cost, because the same call priced against your cost is a moving target. The FinOps working group notes that “identical prompts can yield different amounts of output tokens depending on the specific model employed,” so even a per-token meter passes an unpredictable bill straight through to the buyer. You have made your cost predictable to yourself and your price unpredictable to them, which is a hard thing to sell.

What is outcome-based pricing for AI?

Outcome-based pricing charges for the result the customer got, not the resources it took to produce that result. A resolved support ticket, a qualified lead, a merged pull request, a completed reconciliation. The price attaches to the job done, and the token cost sits underneath as your cost of goods, not the customer’s line item.

The appeal is that it realigns price with value. The Tokenomics Foundation frames the token as serving four roles at once: “the unit of cognition the model produces,” “the unit of compute the data center serves,” “the unit of price the lab charges,” and “the unit of value the enterprise extracts.” (tokeneconomics.com) The first three are supply-side. The fourth is the one your customer cares about. Outcome pricing tries to charge on the fourth while the first three float underneath. When it works, a customer who resolves twice as many tickets pays twice as much and feels fairly treated, because the bill tracks something they can see rather than a token count they cannot.

This is not a niche idea any more. Charging for AI outcomes is spreading precisely because the metered-token layer makes consumption pricing feel arbitrary to buyers. The direction of travel is away from access-and-consumption and toward results.

Why can’t you price on outcomes without measuring token cost first?

Because an outcome price is only safe if it sits above the token cost of producing that outcome, and that cost is exactly the number that varies call to call. If you charge $2 for a resolved ticket and the tokens to resolve one range from 20 cents to $3 depending on how the conversation went, you are profitable on average and bankrupt on the tail. You will not know which until the bill arrives.

The FinOps Foundation is direct that cost is table stakes, not the finish line. Its AI-value work states that “managing AI cost is only the beginning. The real question is whether AI investments are creating measurable business value.” (finops.org) You cannot answer the value question honestly until you can answer the cost one, because value is what is left after cost, and if the cost is a fog, so is the value.

Here is the ordering that actually holds. First, measure the token cost of one unit of work. That means attributing tokens to the thing that produced the outcome: the session, the agent, the feature, the customer. Second, look at the distribution of that cost, not the average, because outcome pricing lives or dies on the tail. Third, set the outcome price above the cost you can defend, with room for the expensive cases. Skip the first step and the rest is guessing dressed up as a pricing strategy.

That the discipline is arriving is not in doubt. The FinOps Foundation reports that 98% of FinOps teams now manage AI spend, up from 31% two years ago. (finops.org) The Tokenomics Foundation names the same split directly: consumption optimization is “FinOps for AI,” and monetization is “AI value,” the effort to “tie AI use to business value and outcomes.” The FinOps-for-AI half is the measurement work. The AI-value half is the pricing work. You do them in that order or the second one is fiction.

How do you measure token cost per unit of work?

You attribute every token to the thing that produced it, then read the cost distribution for that thing rather than a single monthly total. A monthly bill tells you what you spent. It does not tell you what one resolved ticket cost, which is the number an outcome price has to clear.

The grain matters. If your telemetry only knows “we spent $4,000 on the model last month,” you can average that across outcomes and get a per-outcome cost that hides the tail entirely. The costly sessions, the ones where the agent looped and re-sent context and reached for the premium model, are averaged into invisibility next to the cheap ones. Price against that average and the expensive tail eats the margin you thought you had. You need the per-session, per-agent, per-feature cost, and you need its spread.

This is the part TokenJam is built for. It captures the token counts from your agent runs locally, prices them against a maintained model-rate table, and lets you break the cost down by agent, by model, by day, and by session. tj cost --group-by agent shows you where the spend actually lands, and the optimize analyzers surface the sessions whose shape drives the tail. The point is not a dashboard for its own sake. It is that outcome pricing needs a defensible cost-per-unit-of-work number, and that number comes from attribution and distribution, not from a total divided by a count.

None of that is a pricing model on its own. Measurement is the input to a pricing decision, not the decision. What it buys you is the ability to make the decision with the tail in view instead of a comfortable average, which is the difference between an outcome price that holds and one that quietly bleeds.

Common questions

Why is my flat AI subscription losing money on some customers?

Because a flat fee assumes roughly equal cost per user, and metered tokens break that assumption. A customer running an agent that loops over long documents re-sends the whole conversation on every turn, so their input token count balloons, and if they pull the premium model for output they pay the premium rate too. Their token cost can be ten times a light user's while your price stays fixed. The light users subsidize the heavy ones until there are too many heavy ones, and then the tier is underwater. The fix is to measure token cost per customer before you assume the tier is profitable.

Isn't usage-based pricing the answer to variable token cost?

It makes your cost predictable to you and your price unpredictable to the buyer, which trades one problem for another. Charging per call or per thousand tokens tracks your cost, but the FinOps Foundation notes that identical prompts yield different token counts on different models, so the same call is a moving cost. You pass that variance straight to the customer as a bill they cannot forecast. It is honest about consumption and silent about value, which is why the pressure is toward pricing on outcomes instead.

What is outcome-based pricing in plain terms?

You charge for the result the customer wanted, not the resources it took. A resolved ticket, a qualified lead, a completed reconciliation. The token cost of producing that result becomes your cost of goods rather than the customer's line item. The customer's bill tracks something they can see and value, and the messy variable token cost sits underneath where you manage it. It only works if you can measure that underneath cost with enough precision to price the outcome above it, including the expensive cases.

How do I know what one AI outcome actually costs me?

Attribute tokens to the thing that produced the outcome, then look at the distribution rather than the average. A monthly total divided by a count hides the expensive tail, and outcome pricing lives on the tail. You want the per-session or per-feature cost and its spread, so you can price above the cost you can defend with headroom for the costly cases. Tools that capture token counts and break them down by agent, model, and session get you that number; a single spend figure does not.

Does TokenJam set prices or recommend an outcome price?

No. It measures. TokenJam captures your agent token counts locally, prices them against a model-rate table, and shows the cost broken down by agent, model, day, and session so you can see the distribution, not just the total. The pricing decision stays yours. What the measurement buys you is a defensible cost-per-unit-of-work number with the tail in view, which is the input an outcome price needs and the step most teams skip.

Further reading

• What actually costs money in an agent loop. The mechanism underneath the variable cost: why re-sent context and output tokens, not the monthly total, are where per-outcome cost is decided.
• Prompt caching read vs write: when caching costs more than it saves. A worked example of how the same feature carries a different token cost depending on how the prompt is structured, which is exactly the variability that makes flat pricing leak.

---

TokenJam is a local-first, OTel-native cost layer for AI agents. No cloud, no signup. pipx install tokenjam, then tj cost --group-by agent to see what one unit of work actually costs you.