Feb 19, 2026
Arnon Shimoni
In the last six months, more companies have come to us asking to implement credit-based pricing than in the previous two years combined. We're seeing the adoption curve in real-time.
Tanso's AI Pricing Finder shows that, roughly:
Hard cap at 43%
Rollover at 14%
Pooling at 40%
Top-ups at 60%
I think these are the design benchmarks the industry is now using as reference points.
These are genuinely important design decisions! I think the conversation is missing something however:
From inside the infrastructure layer, the pattern is consistent: companies design their credit systems in the wrong order. They debate granularity, overages, and growth hacks first, and find the architectural problem later. Usually around month 12. Usually during a billing run nobody expected to be hard.
The design decisions Steven describes are downstream of a more fundamental one: are your credits built as a ledger primitive, or as a feature you layered on top of your existing billing setup?
The complexity compounds faster than anyone expects
Start with a simple scenario: an AI company that wants to give users a monthly credit allowance. Add a counter, decrement on usage, gate the feature when it hits zero.
Then come the exceptions.
A power user requests a top-up mid-cycle.
Your sales team closes an enterprise account that wants shared credits across their whole org.
A customer asks whether unused credits roll over to next month.
Another asks for a pool across multiple subsidiaries.
You want to give bonus credits for referrals.
Your CFO needs the revenue recognized correctly, which means prepaid credits can't sit on the P&L the same way a subscription does.
These aren't edge cases. Each one is already live at 40-60% of products in the market.
Suddenly you have a distributed balance problem!
Credits are being consumed by multiple agents simultaneously. You have wallets at different levels of your org hierarchy. You have multiple sources of credit (subscription allowance, top-up purchase, bonus grant, rollover) that need to be tracked separately for accounting purposes but drawn from in a specific order for billing purposes.
Overage handling, rollover policy, pooling rules, top-up mechanics: every design decision in Steven's taxonomy is, at its core, a ledger operation.
It requires your system to maintain accurate, real-time, transactionally consistent balances across concurrent writes and mid-cycle mutations.
Whether it's Stripe, homegrown, or whatever system - the problem appears when the complexity you're designing for outgrows the foundation underneath it.
The danger: credits as a feature, not infrastructure
Most AI companies add credit pricing on top of whatever billing setup they already have. Stripe subscription for the base seat fee, a custom credit_transactions table for usage tracking, some reconciliation logic in their application code to tie them together.
This works until it doesn't.
The sign that you've hit the wall usually looks like one of the following:
Invoices that don't reconcile with actual usage because the subscription system and the credit system have different understandings of the billing period.
Revenue recognition headaches because your credits table doesn't distinguish between prepaid credits (deferred revenue) and bonus credits (already recognized).
Enterprise customers asking for cross-subsidiary pooling and your team spending two sprint cycles building what should be a configuration option.
A customer who topped up mid-cycle and then downgraded, and nobody is quite sure whether their rollover balance counts against the new tier's allowance.
Salesforce is experiencing a version of this publicly, as Agentforce launched with per-conversation pricing, then added Flex Credits, and now coming back to seat-based per-user licenses.
Three co-existing models with different mechanics means three different billing paths that all need to reconcile against the same customer record. Analysts are calling it "pricing stack bloat," and the cause is architectural: billing systems without a unified abstraction for hybrid models can't hold the structure as it grows.
What "good" looks like
The companies that get this right treat the credit wallet as a first-class object in their billing infrastructure: not a column in a usage table, not a Stripe product variant, but a primitive with its own lifecycle, balance semantics, and rules for how it interacts with the subscription layer.
Concretely for me this means a few things:
The wallet is the unit of balance, not the user or the subscription. An org can have multiple wallets: a shared pool for team credits, individual allocations for specific users, a bonus wallet from a referral campaign. Each wallet has its own source, its own expiry rules, its own draw-down priority. When usage happens, the system knows exactly which wallet to debit, in what order, and how to handle the case where one wallet is exhausted before the operation completes.
Hybrid is a native configuration, not a reconciliation problem. Seat subscriptions and credit consumption aren't two separate billing systems that get stitched together at invoice time. They're two dimensions of a single billing model that the ledger tracks simultaneously. When your enterprise customer pays for 50 seats plus a shared credit pool, the invoice should reflect both without anyone writing custom code.
Revenue recognition is built in, not bolted on. Prepaid credits are deferred revenue until consumed. Bonus credits are a cost. Rollover credits have specific ASC 606 / IFRS 15 treatment depending on whether you've established a material right. Your billing infrastructure should handle this classification automatically at the point the credit is issued, not force your finance team to reconstruct it from a usage log.
Ask yourself this today
Before you spend time on granularity decisions, overage design, and rollover policy, ask this:
Where does the credit balance live, and what happens when two events try to modify it simultaneously?
If the answer involves application-level logic, a custom transactions table, or a third-party system that isn't your core billing ledger, you'll need to revisit this later.
The downstream design decisions are only as good as the foundation that enforces them.
Most teams discover this problem during a billing run they weren't expecting to be hard.