Flat AI Pricing Is a Subsidy: One User Burned $30,983 of Tokens on a $200 Plan

Key takeaways

• A developer on Indie Hackers reported burning roughly $30,983 of token value in a single month on a $200 per month flat plan, about 155x the price paid.
• Across the leaderboard he built, the numbers get bigger still: 18.7B tokens all time and 17B tokens in the last 30 days.
• Flat pricing does not remove usage cost, it just moves the variance onto your P&L instead of the customer's invoice.
• Your blended average cost per user is the wrong number to plan around. The top few percent of users decide whether the plan is profitable.
• Token burn is a vanity metric. Cost per shipped outcome is the number that should drive both your pricing and your model routing.

What actually happened?

A developer built a public leaderboard for AI coding spend and, in doing so, published his own numbers: roughly $30,983 of token value consumed in a month while paying a $200 per month flat subscription. His leaderboard shows 18.7B tokens all time and 17B tokens in the last 30 days across the models tracked.

The post landed as a flex. Read as a pricing document, it is something else entirely. It is a public admission that at the top of the usage distribution, flat AI plans are not a business model. They are a marketing subsidy with a monthly cadence.

Why does one heavy user break a flat plan?

Because AI usage does not follow a normal distribution. It follows a power law.

In a classic SaaS product, your marginal cost per extra seat is close to zero, so a heavy user is a good user: same price, negligible extra cost, free word of mouth. In an AI product, every extra hour of use has a direct, metered cost attached to it. The heaviest 1 to 5 percent of accounts can consume more inference than the entire remaining base combined.

That changes the math in a way founders often miss. If your average cost to serve is, say, $12 per user per month against a $49 plan, you look comfortable at 75 percent gross margin. But if 3 percent of accounts each consume $400 of inference, those accounts alone can wipe out the contribution of hundreds of ordinary users. The average was never the risk. The tail was.

How do you find your real cost to serve?

Stop looking at one blended number and start looking at a distribution.

1. 1Measure cost per account, not cost in aggregate. Attribute every input and output token to the account that triggered it.
2. 2Sort accounts by monthly inference cost and look at the top decile explicitly. That is your actual risk curve.
3. 3Compare each account's cost against the price it pays. Any account above roughly 40 percent of its own revenue in inference cost is a margin problem, not a power user.
4. 4Re-run the same distribution with a cheaper model mix and with prompt caching enabled, so you can see how much of the tail is genuinely expensive work and how much is routing sloppiness.

Developers in the comment thread on the original post reported cutting monthly spend by roughly half simply by routing file reads, greps, and explanation passes to cheaper models and reserving the frontier model for actual reasoning, plus caching long system prompts. Those are not exotic optimisations. Most teams have simply never measured what they would save.

What should you charge instead?

Three options, in rough order of how often they work for early AI products:

• Hybrid: base fee plus included usage. A predictable monthly floor covers your fixed costs and buyer psychology, and metered overage above an included allowance covers the tail. This is where most durable AI pricing has landed.
• Pure usage-based. Margins are structurally safe, but revenue is unpredictable and buyers hate uncapped bills. Works best when the unit maps cleanly to customer value, such as per resolved ticket or per document processed.
• Flat with a real fair-use policy. Viable, but only if you actually enforce the cap and you have modelled what the top 1 percent of users cost you. Flat with an unenforced cap is just a slower version of the $30,983 story.

The part the leaderboard misses

Here is the observation the original post does not make: a token leaderboard rewards exactly the behaviour that destroys margin, on both sides of the transaction.

For the user, high burn is framed as status rather than waste. For the vendor, that same burn is unpriced cost. The number that would actually change behaviour is a ratio: tokens per shipped commit, per closed issue, per resolved ticket. Raw burn measures how hard the model had to work. The ratio measures whether the work was worth paying for.

That is also the metric that should drive your pricing page. If you cannot state your cost per successful outcome, you cannot know whether your plan price is a price or a donation.

Takeaway: flat AI pricing is not wrong, but it is a bet on your usage distribution, and you should only take that bet after you have modelled the tail. You can model exactly this in Calcaas: plug in your token costs, simulate user tiers, and see where the margin breaks.