Your AI bill should scale with users, not usage

Jul 5, 2026

If you’re building a product with AI features, you’re probably doing two things at once: charging your users a flat monthly price, and paying your inference provider by the token.

That’s a structural mismatch. Your revenue scales with the number of users. Your AI bill scales with what those users do. Those are different curves, and the gap between them is your margin.

This post makes one argument: for a product with users, your inference cost should be a function of headcount, not behavior — because that’s the only model where you can offer an unlimited experience and know your worst-case bill in advance.

Two ways to buy inference

Metered (per-token): you pay for every token in and out. Your cost is a function of user behavior — decided by your users, known only after the fact, and unbounded.

Capacity (per-seat): you pay a flat price for a reserved slot that serves one request at a time with no token caps. Your cost is a function of how much capacity you provision — decided by you, known before the month starts, and bounded.

Everything in this post follows from that one difference: who controls the variable your bill depends on.

	Metered (per-token)	Capacity (per-seat)
Bill is a function of	User behavior	Capacity you provision
Who controls it	Your users	You
Known	After the fact	Before the month starts
Worst case	Unbounded	The subscription price
Heavy user	Costs you more	Costs you the same

The fat-tail problem

Per-user token consumption is not a bell curve. It’s fat-tailed: most users send a few short conversations, and a small minority — power users, users who wire your product into a workflow, users running agents — consume one or two orders of magnitude more than the median.

When your COGS are metered, you price your product for the median and bleed on the tail. That leaves you three options, all bad:

Cap usage. “You’ve used your 50 messages this month.” Your most engaged users hit the wall first — you punish exactly the people who love the product.
Pass the meter through. Credit systems, token balances, per-message pricing. Users ration a feature they’re paying for, and usage anxiety kills adoption.
Eat it. Accept that some fraction of your users are unprofitable and hope the average holds. Your margin is now a bet on user behavior.

Per-seat capacity dissolves the trilemma instead of picking a corner: the heavy user and the light user cost you exactly the same, so you don’t need to cap, meter, or gamble.

The math

With metered pricing, your monthly cost is a sum over things you don’t control:

COGS = Σ (tokens per user × price per token)     ← one term per user, unbounded

With per-seat capacity, it’s a product of things you do control:

COGS = seats × price per seat                     ← known before the month starts

And here’s the part that makes the second equation better than it first looks: seats scale with peak concurrency, not with user count. A thousand users don’t make a thousand simultaneous requests — they make a handful at peak, because usage spreads across the day. You provision for the busiest moment, the same way you provision web servers.

Two consequences:

Your bill is a step function of how many users you serve simultaneously — which grows much more slowly than signups.
Your cost per user falls as you grow, because more users share the same peak capacity. Metered pricing has no equivalent: cost per user stays flat at best, and rises if engagement improves.

Under metered pricing, engagement is a cost. Under per-seat capacity, engagement is free. You’ve aligned your COGS with your business for the first time: more users → more revenue → step up capacity when queues grow. Nothing in that loop depends on how hard each user hits the API.

What bounded COGS buys your product

You can offer unlimited AI to your own users. No credit meters, no message counters, no “upgrade to continue.” This is the single biggest UX difference between AI features people use constantly and AI features people ration. You can only make that promise downstream if someone made it to you upstream.

Pricing becomes arithmetic. Gross margin per user = your price − (seat cost ÷ users per seat). Every input is known in advance. Compare that to forecasting a fat-tailed usage distribution and multiplying by a per-token rate.

A runaway user is a queueing problem, not a financial incident. On metered infrastructure, a user who wires your product into a retry loop shows up on your invoice. On seats, the worst they can do is saturate one slot and wait in line — they cannot add a cent to your bill.

You stop building cost-control infrastructure. Spend alerts, per-user budget tracking, anomaly detection on your own invoice — that’s engineering effort that exists only because your provider’s pricing made user behavior your financial problem.

What the seat model asks of you

Honesty about the trade: capacity pricing is not magic, it’s a different discipline.

One request at a time per key. A seat serves requests serially. Your backend keeps a pool of keys and dispatches to the least busy one — the same pattern as a database connection pool, and about as much code.
You scale in steps, not on a smooth curve. When p95 queue time creeps up, you add a seat. That’s the whole capacity-planning playbook.
Reserved time windows. Seats here are daily 8-hour blocks — reserve the block that matches your traffic hours, or all three for 24/7 coverage.
Fair use applies. Unlimited means no token counting during your reserved hours; it doesn’t mean reselling raw capacity.

If you’ve ever sized a server fleet, none of this is new. The point is precisely that it turns inference into infrastructure you provision instead of a utility that meters you.

When the meter is still right

Per-token pricing is the better buy when usage is genuinely sporadic — a weekly batch job, an internal tool ten people touch once a day. A seat that idles is money spent on capacity you didn’t use. Metered pricing is also right when you need a specific proprietary model, or thousand-way burst parallelism for a few minutes a day.

The crossover is steady, user-driven traffic: the moment real users generate load every day — and especially the moment agents multiply that load by 10–50× — the meter’s “pay only for what you use” becomes “pay for whatever your users decide,” and the flat seat wins.

Running it in practice

Size for peak concurrency. Count simultaneous in-flight AI requests at your busiest hour. That’s your starting seat count — not your user count.
Pool the keys. One API key per seat, least-busy dispatch in your backend. Keys are independent, so one saturated seat never affects the others.
Watch queue time, not spend. Your only scaling signal is latency. When it degrades at peak, add a seat; the bill changes by exactly one known number.
Match blocks to traffic. A product with a single dominant timezone can cover its whole day with one block per seat and pay a fraction of 24/7 coverage.

The API is OpenAI-compatible, so the switch is a base URL and a key.

We serve six open-weight models across two flat-rate pools — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 in the Frontier pool (from $44.20/mo), DeepSeek V4 Flash and MiMo v2.5 in the Core pool (from $5.94/mo) — with unlimited time-block subscriptions: no token caps during your reserved hours, one key per seat. Your users’ usage never becomes your problem. Get started or see plans.