Billing for AI companies
AI products bill differently because they cost differently. A token processed, an inference call made, an agent run completed — each one has a real, variable infrastructure cost behind it, and that cost has almost nothing to do with how many people are logged into a dashboard. This guide covers how AI-native companies actually price and bill: why seat-based SaaS billing breaks under token economics, the pricing models that replaced it, the metering architecture that has to sit underneath any of them at scale, and why the credit wallet — not the invoice — has become the default AI pricing primitive.
Why seat-based SaaS billing breaks for AI products
Seat-based billing breaks for AI products because the number of logged-in users stops correlating with the cost of serving them. Traditional SaaS pricing works on a simple assumption: cost-to-serve scales roughly with headcount, so charging per seat keeps revenue and cost moving in the same direction. That assumption held for tools where the marginal cost of one more click, one more page load, one more saved document was close to zero. It does not hold for a product where every request runs a model, and every model run consumes measurable, non-trivial compute.
In an AI product, a single account can generate wildly different infrastructure cost depending entirely on how it’s used — not on how many seats it has. A three-person team running an agent continuously against a large document set can burn more inference cost in a week than a fifty-seat team using the product occasionally for one-off queries. Under seat pricing, the light team pays more and costs less; the heavy team pays less and costs more. That’s not a rounding error in the pricing model — it’s the model actively pricing the wrong variable.
The mismatch gets worse as AI products lean into autonomous usage. Agents that run unattended, batch jobs that process a queue overnight, and API integrations with no human clicking anything all generate real usage with zero seats attached to them at all. A pricing model anchored to logged-in humans has no way to charge for that activity, which means a growing share of a product’s actual cost-to-serve sits entirely outside what the pricing model can see.
| Seat-based pricing | Usage/token-based pricing | |
|---|---|---|
| What sets the price | Number of logged-in users | Tokens, calls or compute consumed |
| Tracks infrastructure cost | Loosely, if at all | Directly |
| Charges unattended/agent usage | No — needs a logged-in seat | Yes — any event can bill |
| Revenue as usage grows within an account | Flat until a seat is added | Scales with consumption |
| Where it still fits | Admin, workspace, collaboration features | Inference, agent runs, compute |
None of this means seats are wrong everywhere in an AI product — workspace management, admin controls and human collaboration features often still track headcount reasonably well. The failure mode is using seats as the only pricing dimension for a product whose cost is actually driven by compute. See seat-based pricing and usage-based pricing for the underlying definitions.
The pricing models AI companies actually run
Most AI companies converge on one of four pricing shapes, and the choice usually follows from how predictable a customer’s usage is and how much of the product’s cost scales with consumption versus headcount.
1. Token or usage metering
Usage metering charges directly for the raw unit consumed — a token, an API call, a compute-second — typically billed at period end from an aggregated total. It’s the most direct way to tie price to cost, and the model most infrastructure-layer AI companies default to, because it needs no separate packaging decision: whatever gets metered is what gets billed. The tradeoff is customer-side predictability — an open-ended, consumption-billed invoice is harder for a customer to budget against than a fixed number, which is part of why pure metering is often wrapped in a wallet rather than left as a raw pay-after-the-fact bill.
2. Credit-based wallets
Credit-based pricing sits on top of the same metering data but reframes it as a prepaid balance: a customer buys or is granted credits, and every metered event burns the balance down by a configured amount instead of accruing toward an invoice. This is the model most consumer- and prosumer-facing AI products settle on, because a visible, spendable balance is a far more intuitive mental model for inference cost than a running dollar total a customer can’t see until the bill arrives.
3. Hybrid seat-plus-usage
Hybrid pricing charges a base subscription — often tied to seats, workspaces or a feature tier — with usage or credits layered on top for the parts of the product that scale independently of headcount. This is the common shape for AI products built on an existing collaboration or workspace surface: the base fee covers access and non-AI functionality, and a credit allowance or metered overage covers the model calls a team actually makes. It’s rarely a philosophical choice so much as a practical one — most real products have both a headcount-shaped cost and a compute-shaped cost, and pricing that ignores either one misprices something.
4. Agent- and outcome-based pricing
An emerging shape charges for what an agent actually accomplishes — a completed task, a resolved ticket, a successful run — rather than for the tokens or calls it took to get there. This is the hardest model to bill correctly, because it requires metering at the level of an outcome, not a raw event, and defining unambiguously what counts as a billable outcome versus a retried or partial one. It’s early relative to token and credit pricing, but it’s the direction agent-native products are visibly moving, because it prices what the customer values instead of the mechanism used to deliver it.
Metering architecture for AI-native event volume
Metering for an AI product has to handle far more events, at far less predictable rates, than metering for a typical SaaS tool — a single chat completion or agent run can emit dozens of billable events (input tokens, output tokens, tool calls) in a fraction of a second, and a batch or agentic workload can spike volume without warning. An architecture built only for the happy path — steady volume, in-order delivery, no retries — is not one you can safely bill real customers on once that volume shows up.
Three properties matter more at AI-native scale than they do anywhere else in usage-based billing. First, idempotency: a network retry on a token-emitting request has to be recognized and dropped, not billed twice — with the request volumes AI products see, an un-deduplicated retry path turns into a visible, recurring billing error rather than a rare edge case. Second, an append-only ledger: totals, invoices and entitlement checks all need to be derived views computed from immutable event history, not a counter that can silently drift when volume spikes. Third, tolerance for late and out-of-order events — a background job reporting token usage after a long-running inference call finishes still has to land in the correct billing period automatically. Kribana’s ledger, for example, folds events arriving up to 72 hours late into the right period without a manual correction step.
The other requirement specific to AI products is that metering can’t add latency to the request path itself — a token-emitting API call is already latency-sensitive, and a metering call that blocks on a write would make billing infrastructure a bottleneck in the product’s core loop. Usage events need to be a fire-and-forget send that doesn’t sit in the critical path, while the separate question of entitlement — can this request proceed right now, given the account’s balance and plan — needs to be answerable fast enough to sit on the hot path without the customer noticing, typically through a local cache that stays consistent with the ledger underneath it.
See how Kribana’s metering pipeline handles idempotency, late events and real-time aggregation, or the glossary for idempotency keys, ledgers and usage events.
Credit wallets: the pricing primitive AI products converge on
Credit wallets have become the default AI pricing primitive because they solve a problem token metering alone doesn’t: making unpredictable, consumption-driven cost legible to a customer before the invoice arrives. A wallet turns “here’s what you owe” into “here’s your balance,” and a balance a customer can watch burn down in real time is a fundamentally easier thing to trust and budget against than an open-ended bill that only resolves at the end of a period.
A wallet built for an AI product needs to do more than hold a single number. Paid credits, promotional grants and trial allowances typically need to be tracked as separate balances even while the customer sees one combined figure, with grants burning down before paid credits — so a trial allowance or launch promo gets consumed first, and a customer’s own money isn’t quietly spent on usage that was meant to be free. Getting that burn order backwards is a common and entirely avoidable design mistake: a customer whose paid balance drops because a promotional grant was charged last, instead of first, generates a support ticket that’s hard to explain away after the fact.
The other half of wallet design is timing. A wallet that only reacts once it’s already empty creates exactly the failure mode AI products fear most: a batch job or agent run stopping mid-execution because a balance hit zero with nobody watching. A wallet built to alert — or, with explicit customer opt-in, auto-charge — at a threshold before the balance reaches zero avoids that outcome entirely, and because the threshold check runs continuously against live usage rather than as a periodic batch job, it can catch a fast-draining balance during a heavy inference workload, not just a slow monthly decline.
Wallets aren’t a separate system bolted onto billing, either — a well-built one is driven by the same metering ledger that produces invoices, so the balance a customer sees and the number that determines their access are computed from the same source, with nothing to reconcile after the fact. See how Kribana’s wallets handle burn order and threshold top-ups, or the glossary for credits and wallets, credit grants, burn-down and top-ups.
Where an autonomous billing agent fits in AI billing
An autonomous billing agent matters more for AI-native billing than it does for a typical monthly SaaS subscription, because the pace at which things go wrong is different. A subscription’s failure modes — a card expiring, a customer drifting toward churn — unfold over weeks. A credit wallet’s failure modes can unfold in minutes: a heavy inference workload can take a balance from healthy to empty during a single batch run, faster than a human watching a dashboard would reasonably catch it.
For AI products specifically, the highest-value playbooks are the ones tied directly to wallet and usage behavior: firing a top-up link the moment a balance crosses a threshold, before an agent run or batch job stalls out mid-execution; diagnosing why a payment failed — insufficient funds, an expired card, a bank block — and matching the retry timing to the actual reason instead of a blind fixed schedule; and flagging an account whose usage is trending toward a bill-shock number early enough for a spend alert to reach the customer before the invoice does. None of that requires a human to be watching in real time, which is the point — the moments that matter for a fast-draining wallet don’t wait for a person to check a dashboard.
None of this needs to run fully unattended from day one. Every playbook a billing agent runs can operate in autopilot, approve-first, or alert-only mode, set independently — a team can let low-risk playbooks like wallet top-up links run on autopilot immediately while keeping higher-stakes actions, like an auto-charge, gated behind explicit customer opt-in and a human-reviewed rollout. See how Kribana’s billing agent watches wallets, payments and usage, or the glossary for the agent and playbooks.
Evaluating a platform to run this on
If you’re comparing usage-based billing platforms specifically built for metered, credit-driven pricing, see how Kribana compares to Orb and Metronome, or browse Kribana’s own pricing to see the pricing-engine and wallet features described above in the product itself.
FAQ
Why doesn't seat-based pricing work for AI products?
Seat-based pricing breaks for AI products because the thing driving your infrastructure cost — tokens processed, inference minutes, compute-seconds — has almost no relationship to how many named users are logged in. A single developer wiring an agent into a CI pipeline can generate more inference cost in an afternoon than fifty light users of a traditional SaaS tool generate in a month. Charging by seat in that world means your highest-cost customers and your highest-revenue customers stop being the same group, which is the opposite of what a pricing model is supposed to do.
What's the difference between token-based and credit-based pricing?
Token-based pricing charges directly for a raw usage unit — a token processed, an API call made, a compute-second consumed — usually billed after the fact based on metered totals. Credit-based pricing sits on top of that same metering data but wraps it in a prepaid balance: a customer buys or is granted credits, each metered event burns down that balance by a set amount, and the bill becomes 'top up your balance' instead of 'here's what you owe.' Both read from the same event stream; the difference is whether the customer experiences it as a running balance or a period-end invoice.
How do AI companies meter usage at high event volume without dropping data?
By treating metering as infrastructure, not an afterthought: every usage event carries an idempotency key so a retried delivery is recognized and dropped instead of double-billed, events land in an append-only ledger rather than a mutable counter that can silently drift, and the pipeline tolerates events arriving late or out of order — a batch job reporting token usage twenty minutes after the request finished shouldn't produce a wrong invoice. Kribana's ledger, for example, folds events arriving up to 72 hours late into the correct billing period automatically, which matters at the event volumes token-metered products actually see.
Why do most AI products use credit wallets instead of pure pay-as-you-go billing?
Because inference cost is unpredictable in a way flat monthly bills aren't built to absorb, and a prepaid wallet gives both sides a way to manage that unpredictability before it becomes a surprise. A customer watches a visible balance burn down in real time instead of waiting for an invoice to find out what a heavy day cost them, and the seller collects cash upfront instead of extending open-ended credit on usage that hasn't happened yet. That combination — visibility for the buyer, prepayment for the seller — is what's made the wallet the default AI pricing primitive rather than an edge case.
What does an autonomous billing agent actually do for an AI company?
It watches every account's wallet balance, payment health and usage trend continuously and acts on the moments that would otherwise need a human noticing in real time — sending a top-up link before a wallet hits zero mid-inference-run, retrying a failed charge with timing matched to why it failed, and flagging usage trending toward a bill-shock number before the invoice lands. For AI products specifically, where a wallet can burn down fast during a heavy workload, that continuous watching matters more than it does for a slow-moving monthly subscription, because the gap between 'balance is fine' and 'balance is empty' can be minutes, not weeks.
Can an AI company combine seat-based and usage-based pricing?
Yes — hybrid seat-plus-usage is common and often the right answer, not a compromise: a base subscription covers the parts of the product that scale with team size (seats, workspaces, admin features) while usage-based charges or a credit wallet cover the parts that scale with consumption (tokens, inference calls, agent runs). The design problem isn't picking one model over the other; it's deciding which parts of your product genuinely track headcount and which genuinely track compute, and metering and pricing accordingly instead of forcing everything through a single dimension.