Designing a Hybrid Subscription and Token Pricing Model That Doesn't Lose Money

A flat subscription fee is calculated against an assumed average usage level. Any customer using meaningfully more than that average is being subsidized by the ones using less, and if your product attracts power users disproportionately, or a feature encourages heavier usage than the pricing model assumed, that subsidy can be large enough to turn a profitable-looking plan into a loss leader for its heaviest cohort.

This is easy to miss because total revenue can look healthy even while a specific tier is quietly unprofitable, since strong performance elsewhere in the business masks it. The gap only becomes visible when you look at unit economics tier by tier and account by account, rather than at the company-wide top line.

Pull actual token usage by account, calculate the token cost each account is generating, and compare it against what that account is paying. Plot accounts by usage and look at where the cost curve crosses the revenue line. If a meaningful share of accounts sit above that crossing point, especially if that share is growing, your pricing has this vulnerability today, not hypothetically.

Segment the plot by plan tier as well as by account, since the gap often concentrates in one specific tier, commonly the entry tier priced to win new customers, rather than being spread evenly across your whole customer base.

Audit and fix the gap in this order:

1. Pull actual token usage by account from your billing or usage data, rather than working from the average you assumed when pricing.
2. Calculate the token cost each account generates and compare it against what that account pays.
3. Plot accounts by usage and find where the cost curve crosses the revenue line.
4. Set the included allowance against a percentile of actual usage rather than the average.
5. Price overage tokens with real margin over your own cost, not at or near cost.
6. Move existing customers onto changes through a grandfathered or clearly explained transition path.

Set the included allowance in a subscription tier against a percentile of actual usage, not the average, since a plan built around the average will always be underwater for the heavier half of its users. A common approach is pricing the included allowance to cover a large majority of accounts at that tier comfortably, with overage pricing designed to make the remaining heavy accounts still profitable rather than subsidized.

Overage tokens should be priced with real margin over your own cost, not at cost or near it, since overage is exactly the usage that was outside what the subscription was priced to cover. A thin or non-existent overage margin defeats the purpose of having a usage-based component at all: it's there specifically to keep heavy usage from eroding the economics of the plan.

Revisit the overage rate whenever your underlying model cost changes, since a rate set to protect margin against last year's per-token cost can quietly stop doing that job if your cost structure shifts and nobody rechecks the rate against it. Treat it as a rate that needs periodic maintenance, the same way you'd revisit a foreign exchange assumption baked into a contract.

If the audit finds a real gap, fixing it usually means adjusting included allowances or overage rates for new customers, and handling existing customers on a grandfathered or clearly communicated transition path. Customers respond far better to a clearly explained shift, especially one framed around usage tiers rather than a blanket price increase, than to a change that looks like the number changed with no explanation attached.

Say your entry tier includes a fixed monthly token allowance priced to comfortably cover most accounts, but a specific use case, batch document processing rather than the occasional chat query the tier was designed around, pulls a small slice of accounts far past that allowance every month. Those accounts pay overage, but if the overage rate was set closer to a rounding convenience than to your real per-token cost, the tier can still lose money on exactly the accounts driving its heaviest usage.

The fix isn't necessarily to push those accounts to a higher tier, since the use case itself might be perfectly reasonable for an entry-level customer to run occasionally. It's to make sure the overage rate on that specific tier reflects real cost with real margin, checked against the actual usage pattern of the accounts triggering it, rather than a number picked once at launch and left alone.

This is also where segmenting by account type earns its keep: a handful of accounts running an unusual, heavy workflow inside an otherwise healthy tier is a very different problem from the whole tier being mispriced, and the audit needs to distinguish the two before deciding what to change.