The math behind a $19 AI plan: why flat-rate token pricing quietly loses money

A pattern keeps showing up in AI product pricing pages: a plan priced at "$19/mo includes 10M tokens" that looks reasonable on the surface — until the actual cost math is run.

Three weeks later, the founder is looking at an LLM bill larger than their MRR, trying to figure out which power user is responsible.

Here is the math that catches it before a price goes live.

Three ways AI plans lose money

1. Blended cost is higher than assumed.

Input and output tokens do not cost the same. Output is typically 3–8x more expensive. Pricing based on a vendor's headline number means the real cost per token is already wrong.

2. Overage is priced below cost.

A plan that includes 5M tokens and charges "$0.50 per additional 1M" looks generous — until the actual blended cost is $3.60/1M. Every heavy user then costs more than they pay.

3. Payment fees eat low-priced plans.

Stripe takes 2.9% + $0.30. On a $19 plan, that is $0.85 — 4.5% of revenue gone before a single token is used. Platform fees (Creem, Gumroad, Lemon Squeezy take 5–10%) can erase the margin on a low-priced plan entirely.

The formulas

The core number is blended cost per 1M tokens:

blended_cost_per_M = 0.8 * input_price + 0.2 * output_price

The 4:1 ratio is a reasonable default for chat-style products. Summarization-heavy products should use closer to 10:1; generation-heavy products closer to 1:1. The ratio should match actual traffic.

Run that on 2026 model prices and the spread is significant:

That is a 30x difference between the cheapest and most expensive routing. A single "$19 = 10M tokens" plan cannot cover all of them. Pricing as if everyone uses the budget model while users route everything to the flagship means losing money on every sale.

The SAFE/UNSAFE check adds payment fees and a minimum margin:

net_revenue = price - payment_fees
cost_of_included_quota = included_tokens * blended_cost
margin = (net_revenue - cost_of_included_quota) / net_revenue

A plan is flagged UNSAFE when margin falls below 15%, or when the overage price is below 1.6x blended cost.

A zero-dependency way to check this

The math above can be run by hand in a spreadsheet, but it is easy to get subtly wrong — especially the Decimal handling. A per-token price like $0.28/1M is 0.00000028; round it to cents and it becomes $0.00. That is a silent revenue leak.

There is a small zero-dependency Python library that packages this check:

pip install ai-token-pricing

from ai_token_pricing import validate_plan_economics, PLAN_CATALOG

r = validate_plan_economics(
    PLAN_CATALOG["budget-pro"],
    blended_cost_per_m=0.40
)

print(r["status"])                    # SAFE
print(r["max_safe_included_tokens"])  # the real ceiling
print(r["break_even_overage_price"])  # the floor for overage

Point it at a bad plan and it returns UNSAFE instead of quietly allowing a loss leader. The CLI exits non-zero on UNSAFE, so a bad price change can fail a deploy:

ai-token-pricing check --plan flagship-pro --blended-cost 9.00

Money math uses Decimal, not floats. The library handles the conversion so the string does not have to be hand-typed.

What this does not cover

This checks token economics only. It does not account for infrastructure, support, retries, refunds, chargebacks, or other overhead. A SAFE verdict is a necessary-but-not-sufficient condition for profitability.

Further reading

The billing implementation layer — Stripe metered billing, weighted quotas, usage caps, and the edge cases the Stripe docs skip — is covered in a separate write-up: Usage-based billing for AI SaaS: what the Stripe docs don't tell you.