Your AI stack is probably billed four different ways at once, and most teams only have a mental model for one of them.
This is not a pricing comparison. It is an explanation of the four mechanisms, because once you can name which one a tool uses, you can predict how it will surprise you.
1. Per seat — the only genuinely predictable one
A fixed price per person per month. Finance loves it because it multiplies, and it is the only model on this list where usage cannot move the number.
The failure mode is the opposite of a surprise bill: it is quiet waste. Seats get provisioned for people who leave, or for a trial that thirty people joined and four still use. Nothing alerts you, because nothing went wrong — that is exactly what a fixed cost looks like whether or not anyone is using it.
The control is an access review, not a budget alarm.
2. Premium requests — countable, until the agent shows up
An allowance of higher-cost interactions, sometimes with a multiplier per model. This was the industry's answer to "make usage-based billing feel like a subscription", and for chat it works: a request is a request, and a person can hold a rough count in their head.
It breaks when agents arrive. A person asking questions makes a countable number of requests. An agent completing a task makes as many as it needs, and you find out afterwards. The number of things you asked for and the number of requests billed stop tracking each other.
Watch for the multiplier, not the allowance. A generous allowance at a high multiplier is a small allowance wearing a costume.
3. Per token — scales with the work, not the ask
Billed by input and output tokens, usually with cached input at a steep discount. GitHub's Kimi K3 listing on 6 August is a concrete example: $3 per million input tokens, $15 per million output, $0.30 per million cached input.
This is the model people mis-estimate most, because token count has almost no relationship to effort as you experience it. Two prompts of identical length can differ by two orders of magnitude in cost, depending on how much context the tool pulled in and how long it worked.
The one lever that genuinely matters is caching. Cached input at a tenth of the price means repeated work over the same codebase is cheap and scattered work across many codebases is not. Your working pattern, not your prompt count, is what shows up on the invoice.
4. Credits — an abstraction over the other three
A credit is whatever the vendor says it is. That is the whole problem and the whole appeal: it lets a tool charge for a wildly variable underlying cost while showing you a stable-looking number.
Credit systems split into two camps by one question — does the vendor publish what an action costs? Lovable does, listing a simple edit at 0.50 credits and an authentication feature at 1.20. Emergent does not publish an equivalent table, and unpredictable consumption is the most common complaint about it in practice.
A second axis is when credits arrive. Emergent grants a monthly bucket — 10 on Free, 100 on Standard, 750 on Pro. Lovable drips a daily grant of 5 build credits capped at 30 a month on its free tier, plus monthly Cloud credits. Same word, opposite constraint: one caps your month, the other caps your afternoon.
How to budget a stack that mixes all four
Do not try to convert everything to one unit. Convert everything to one question instead: what makes this number go up?
- Per seat — headcount. Review the list quarterly and reclaim seats
- Premium requests — how many times people and agents ask. Watch multipliers on new models, and expect agent adoption to break your historical average
- Per token — how much work you hand over and how much context it drags in. Favour repeated work over the same repository; caching is the discount that actually applies
- Credits — whatever the vendor decided. Run a two-week pilot and measure your own burn rate, because no published number will tell you this
- For anything usage-based, set a spend alert before you need one; the whole category is designed so the invoice is the first signal