Token based pricing: a practical guide for AI products

Every AI product eventually meets the same pricing question: your costs scale with tokens, so how do you charge customers in a way that tracks those costs without confusing everyone? This guide covers the decisions that matter, in the order you will meet them.

Start with the unit your costs already have

Model providers quote prices per million tokens, so that is the natural unit for your pricing too. Charging in the same unit you buy in keeps your margin visible per request: if a model costs you $2.00 per million input tokens and you charge $3.00, your gross margin on that lane is legible to anyone on the team.

Two practical rules:

1. Quote per million, meter per token. Customers understand "$2.50 per 1,000,000 tokens." Your metering should still record exact token counts per request, because rounding at the event level compounds into real money at volume.
2. Distinguish input and output tokens if your costs do. Output tokens typically cost several times more than input. A single blended rate is simpler to communicate; separate rates track costs more honestly. Blend only when your input to output ratio is stable across customers.

Three models cover nearly every AI product

Pure usage. Price per million tokens, invoice monthly in arrears. Fits developer tools and APIs where usage varies wildly. The risk is revenue volatility and surprise bills; mitigate with spending alerts and caps.

Hybrid: subscription plus included usage. A monthly plan includes a token allowance; overage bills per million beyond it. This is the dominant model in practice because it gives you predictable base revenue and gives customers a predictable floor. The design decision is the allowance size: large enough that the plan price feels justified, small enough that your heavy users flow into overage.

Prepaid credits. Customers buy a balance up front and usage burns it down; auto top up keeps the balance from stranding a production workload. Credits smooth revenue, shift collection risk to zero, and make budgeting easy for the buyer. The mechanics that matter: a clear conversion rate (1,000 credits = $9.00, say), low balance alerts, and a decision about whether credits expire. We wrote a full guide to credits versus subscriptions.

Most products end up combining these: a plan, an allowance, credits for bursts. Your billing system needs to run all three on one subscription without a spreadsheet on the side. The usage pricing patterns guide walks the underlying shapes with worked numbers.

The math has to be exact, then rounded once

Token prices produce sub cent amounts constantly: 4,183 tokens at $2.50 per million is $0.0104575. If your billing layer rounds at each event, heavy customers get systematically miscounted; if it accumulates in floating point, the totals drift. The correct mechanics: exact decimal arithmetic on the raw counts, rounded once at the invoice line total. When a customer asks why the line says $43.17, you should be able to show the count, the rate, and the single rounding step.

That last part is worth designing for on day one. Usage charges are the charges customers question most, because they cannot see the meter. A bill that can show its own calculation, per line, closes most of those conversations before they become disputes.

Passing through model costs with a margin

Products built on top of third party models often want passthrough pricing: charge the customer what the request cost, plus a margin. This needs the billing layer to accept a cost per event from your application and apply the markup consistently, at the same sub cent precision as everything else. It also future proofs pricing against model price changes: your margin holds even when the underlying rate moves.

What to watch after launch

• Allowance utilization. If almost nobody exceeds the included tokens, the allowance is too big or the price too high; if everybody does, your plan price is a fiction and overage is your real price.
• Margin per lane. Track revenue against provider cost per model and per feature, not just in aggregate. One expensive lane can hide inside a healthy average.
• Bill shock signals. Spending alerts are cheaper than refunds. Give customers a threshold notification before their biggest month, not after.

Running this on yRecurring

yRecurring models all of the above directly: prices entered per million tokens, separate input and output rates where you need them, plan allowances with capped overage, prepaid credit wallets with auto top up, and cost passthrough with a margin percentage. The math is exact decimal, rounded once at the line total, and when a customer asks why a line says $43.17, the invoice can show the count, the rate, and the single rounding step itself. The trial takes no card: enter your per million rates and look at the invoice they produce. The billing for AI page shows the models in more depth.