How to Price Agent Tokens Passed Through to Customers

Before choosing a structure, build a cost ledger for one value unit. Four numbers are enough to start.

1. Input tokens per unit at the median, and at the 95th percentile.
2. Output tokens per unit at the median, and at the 95th percentile.
3. Retrieval and embedding cost per unit (vector searches are not free and can rival inference if you retrieve naively) per Databricks.
4. Your effective rate per million input and output tokens, including caching and batch discounts.

Then compute cost per unit with the formula the provider actually uses:

cost_per_unit = (input_tokens / 1,000,000 * input_rate)
              + (output_tokens / 1,000,000 * output_rate)
              + retrieval_cost

Worked example. A document-review feature takes a 6,000-token document plus 1,500 tokens of instructions and retrieved context, and returns 1,200 tokens of findings. At an input rate of $2 per million tokens and an output rate of $8 per million tokens (rates you would read off your own invoice, not assumed), median cost is:

• Input: 7,500 / 1,000,000 × $2 = $0.015
• Output: 1,200 / 1,000,000 × $8 = $0.0096
• Total: about $0.025 per document before retrieval and overhead

Now run the tail. A long contract with three revision passes might hit 40,000 input and 8,000 output tokens:

• Input: 40,000 / 1,000,000 × $2 = $0.08
• Output: 8,000 / 1,000,000 × $8 = $0.064
• Total: about $0.0144... no, $0.144, roughly 5.8 times the median

That ratio, not the median, is what determines whether a flat unit price survives. Price on the median and you lose money on the heavy tail; price on the tail and you overcharge the typical customer. Every structure below is a different answer to that gap.

This is the simplest structure and the closest to ordinary SaaS: a seat price, or a per-action price, that includes the model cost. The customer sees one number and never thinks about tokens.

It works when token consumption per unit is tight. A classification feature that always reads a fixed record and returns a label has low variance, so the tail is cheap to absorb. Per-action prices are the cleanest variant: the customer pays for an action, and you know from logs that an action costs between, say, two and nine cents.

The value-metric principle applies: if customers get very different value per unit, a single number either overcharges the low end or leaves money on the table at the high end as Robin Landy explains. Landy also warns that a single metric gives a procurement team one number to attack; a second lever (a higher tier with more capability, add-ons, support) keeps the negotiation from collapsing to one figure same source.

Margin math for baked-in pricing: take your fully loaded cost per unit at p95, add retrieval and orchestration, and require that the unit price clears your target gross margin at that worst case, not the median. If the target is 80% gross margin and p95 cost per document is $0.14 plus $0.03 retrieval and $0.02 orchestration, cost is $0.19, so the floor is $0.19 / 0.20 = $0.95 per document. Price at $1.20 and your margin at p95 is about 84%; at the median ($0.03 total) it is around 97%. The expensive tail is what you are actually pricing, and the rest is cushion that funds the features you haven't built yet.

If you are deciding whether to absorb that risk, model it explicitly: what fraction of units sits above your price point, and what does the loss on those units cost against the margin earned on everyone else? An AI pricing breakdown from Willingness to Pay calls this the margin trap: flat-fee unlimited pricing turns heavy users into a problem the business cannot outgrow per Willingness to Pay.

Here the customer pays per token, or per credit that maps transparently to tokens. Your revenue tracks your cost, and heavy users pay for their own consumption.

The tradeoffs are real. Pass-through revenue is volatile in both directions per Lago's comparison of usage and seat pricing. Customers face bill anxiety, and a user complaint on this point is illuminating: if the model decides how long its answer is, the customer has no agency over the bill, and it feels like paying a contractor by the hour while the contractor chooses the hours from this practitioner thread. That is not a naive objection. It is the core defect of raw token pass-through.

So pass tokens through only when two conditions hold: usage genuinely varies an order of magnitude across customers, and the buyer is technical enough to manage it (API consumers, platform teams, agencies building on your product). For everyone else, expose a proxy.

The proxy that works best is a credit whose definition you control. Lago's survey of usage models notes that credits map to user-initiated work, and that credits which do not map to a clear action confuse people per Lago. A defensible credit: one credit equals the median token cost of one action, rounded up, with a published rate card by action type.

Margin math for pass-through: your margin is the spread between your retail rate and your wholesale cost, so the spread must cover price changes you cannot control. If your provider's rate moves, your retail rate is fixed in the customer's contract. Set the retail rate with an explicit buffer, for example retail = wholesale × 3, and state in the contract that metered rates may be adjusted with notice. At wholesale $2/$8 per million and retail $6/$24, a 6,000/1,200-token action costs you $0.0216 and earns $0.0648, a 67% gross margin with room to absorb a doubling of wholesale rates down to about 33%.

Pass-through also requires the boring engineering: metering, aggregation and pricing logic that runs every billing period, plus a way to show the customer their consumption in near real time per Lago. If you cannot render a trustworthy usage dashboard, do not sell tokens.

A monthly plan price includes an allowance of actions, credits or documents. Usage beyond the allowance bills at an overage rate. This is the hybrid model Lago describes as the most common shape for SaaS, because it gives you predictable baseline revenue and still lets expansion happen by design per Lago.

The pricing question splits in two. First, what allowance does each plan include, and what does that allowance imply about your worst-case token exposure? Second, what does overage cost per unit?

Set the allowance by converting your plan price into a token budget. If a plan sells at $99 and you want a floor of 75% gross margin, your total cost budget is about $24.75 per month. At $0.19 p95 cost per document (from the earlier example), that is roughly 130 documents before you hit the floor. Publish 100 included and you keep headroom for retrieval spikes and support.

Overage math: overage should be priced near the per-action price of the next tier up, not at raw token cost. If your $99 plan includes 100 documents and your $299 plan includes 500, the implied marginal price between tiers is $200 for 400 documents, or $0.50 per document. Set overage at $0.60 to $0.75 so the upgrade path stays attractive and the overage path is never cheaper than upgrading.

The risk you carry is the tail: a customer on a capped plan who has one enormous month. Two mitigations. First, enforce limits at runtime so a runaway agent cannot consume a month's budget in an afternoon; vendors that meter AI usage treat runtime enforcement as a first-class feature per Schematic's guide to outcome pricing. Second, set a hard ceiling (a maximum overage) and a per-unit rate that covers your cost at p99.

Three questions in order will place most products on the table above.

1. Can a customer predict how many units they will need next month? If no, meters and allowances beat raw tokens because they cap the surprise.
2. Does usage per unit vary by more than roughly three to one across your customer base? If yes, a single baked-in price is doing violence to your margin at one end of the distribution per Landy's analysis of single-metric pricing.
3. Can the customer take an action that directly reduces token consumption (shorter prompts, a cheaper mode, a summary instead of a transcript)? If not, charging them for tokens is charging them for something they cannot control, which is the exact objection raised in practitioner forums per this thread.

If you answer no, no, no: bake it in. No, yes, no: plan caps with overage. Yes, yes, yes: metered pass-through, with a credit that maps to an action.

A second rule for the price point itself. Willingness-to-pay research, including the Van Westendorp Price Sensitivity Meter, asks four questions to find the range between "too cheap to trust" and "too expensive to consider," and plots the intersections to find an acceptable band and an optimal point per Wikipedia and SurveyMonkey. The method assumes respondents can envision the product and price per the PSM assumptions, and Forbes notes that asking directly for willingness to pay tends to produce lowballed answers per Forbes. So ask your customers about an action or a month, never about tokens: "at what monthly price would this be too expensive to consider?" is a question customers can answer; "$X per million tokens" is not.

The strongest version of the AI value metric charges for the result, not the activity. Outcome pricing means the customer pays when a defined result happens: a resolved conversation, a qualified lead, a completed screening per The SaaS CFO. The SaaS CFO's test is a single sentence: write "the customer only pays when ____ is successfully completed," and if the blank describes internal activity, you have usage pricing with better marketing same source.

Published examples exist. Intercom's Fin agent charges per successful outcome, where an outcome is a resolution the customer confirms or a procedure handoff, with a monthly minimum, and charges once per conversation even if several questions were answered per Schematic. HubSpot's Breeze agents moved to per resolved conversation and per recommended lead per The SaaS CFO.

Outcome pricing fixes the two-unit problem: the customer pays in the unit they care about, and your margin depends on how efficiently you convert tokens into that outcome. It is also hard to operationalize: you must define success twice (a product definition for self-serve and a negotiated definition for enterprise), build failure forgiveness, and make the invoice auditable per The SaaS CFO. A reasonable sequencing, suggested by AI pricing practitioners, is to charge for inputs early to learn your cost structure, then move to outcomes once a valuable use case is proven per Willingness to Pay.

Whatever structure you land on, the token plumbing underneath is the same: one interface to several models, metered and priced in dollars. Quanta Inference routes text, image, video, audio and embedding models through one OpenAI-compatible API with prepaid US-dollar pricing (https://quantaintelligence.ai/inference), which makes the cost ledger easier to build before you commit to a published rate card.