Comparing Provider Pricing Models Without Getting Fooled

Every AI provider publishes a price and almost none of them publish the same unit. One quotes dollars per million tokens, one quotes seats, one sells credits that expire, one bundles a monthly allowance with an overage rate. The comparison you want cannot be read off the pages directly.

The fix is not a bigger spreadsheet. It is picking one denominator — cost per unit of finished work on your own workload — and converting every offer into it.

The five structures you will meet

Metered per token. The industry default and the most honest about underlying cost. You pay for what you consume, input and output billed separately, usually with a discounted cached-input rate. Kimi K3 at $3 in, $15 out and $0.30 cached in is the canonical shape.

Per seat. A fixed monthly figure per named user, with usage limits somewhere in the terms. Predictable for finance, and the unit is a person rather than a workload, which is the source of most of its problems.

Credits or prepaid balance. You buy a pot up front and draw it down at metered rates, sometimes with a discount for volume and often with an expiry date attached.

Tiered allowance plus overage. A monthly bundle at a headline price, then a per-unit rate above it that is frequently much higher than the effective rate inside the bundle.

Flat rate. One price for a period, with limits expressed as fair use or concurrency rather than tokens. Predictable by design, and the structure with the widest gap between good and bad implementations.

Normalising them

Convert everything to cost per million tokens at your own input-to-output ratio, then to cost per completed task. Skipping the second step is the common error, because a task is what you actually buy.

Work an example. Suppose a representative task consumes 40,000 input and 8,000 output tokens. On DeepSeek V4 Pro at $0.44 and $0.87 that is about 1.8 cents plus 0.7 cents, so roughly 2.5 cents per task. On Kimi K3 at $3 and $15 it is 12 cents plus 12 cents, about 24 cents. Nearly ten times, on the same task.

Now put a seat price beside it. A $30 monthly seat pays for itself against the DeepSeek figure at about 1,200 tasks a month, and against the Kimi K3 figure at about 125. The seat price has not changed; what changed is the model behind it, which is why "is a seat worth it" is unanswerable without the token profile.

Do this with your own measured token counts. Input and output pricing matters here because the ratio between them varies enormously by workload, and a comparison built on a blended rate will mislead you in whichever direction your workload leans.

The terms that change the effective price

Cached input is the largest single modifier and the most often ignored. Kimi K3's $0.30 cached rate against $3 standard is a ten-fold discount on the repeated portion of a prompt, which on an agent loop is most of it. Two providers with identical headline rates can differ by several times once caching behaviour is accounted for.

Then check what counts as billable. Whether failed and cancelled requests are charged, whether reasoning tokens are billed as output, whether a rejected tool call still costs you. These are the differences that show up as a mysterious gap between your estimate and the invoice.

Reasoning effort deserves particular attention. GLM-5.2 exposes high and xhigh levels, and the level you pick changes token consumption materially at the same posted rate. A price comparison run at one effort level does not transfer to another.

Finally, look at rate limits as a price. A cheap rate you cannot access at your required concurrency is not cheap. How rate limit tiers work covers reading that dimension properly.

Where each structure genuinely wins

Metered wins for spiky, low-volume or highly variable usage, and for anything where you want the price signal visible to the people generating the load. It is also the only structure that scales down to nearly nothing during quiet weeks.

Per seat wins when usage per person is genuinely uniform and finance needs a number they can multiply by headcount. The seat versus token comparison works through when that uniformity assumption holds, which is less often than vendors imply.

Flat rate wins when variance rather than level is the problem — heavy agent use, unpredictable週 loops, or a solo developer who would otherwise self-throttle to avoid an unknown bill. It is the wrong choice when your usage is genuinely light, because you will pay for headroom you never touch, and when you need per-project attribution, because a flat fee carries no usage signal to allocate.

Questions to ask before signing

What exactly is metered, and is it published. What the overage rate is and whether it is capped. Whether prepaid balance expires. What happens at the limit — throttle, queue, hard stop, or a bill. Whether the posted rate is the rate at your tier or a volume rate you do not qualify for.

Ask for the answers in writing rather than inferring them from a pricing page. Every one of these has been the subject of a nasty surprise for somebody, and all of them are cheap to clarify before money moves.

Then run a two-week trial with real traffic and reconcile the invoice against your own token accounting line by line. Token accounting for finance covers building that reconciliation, and the discrepancies it surfaces are usually more informative than the pricing page.

The decision rule

Compute cost per completed task under each structure at your measured token profile, then ask what the number does at three times your current volume and at a third of it.

The structure that stays acceptable across that range is the one to pick, even if it is not the cheapest at today's volume. Pricing structures are switched at cost, and the volume you have this quarter is the least reliable input in the whole calculation.