Usage-based billing can be a trap.
It is becoming the default for AI-native products and for any product adding AI features, and customers now expect to pay for what they use. But usage pricing is hard to sell, and hardest to sell to enterprise. Buyers fear unpredictable spend, and sellers lose deals to that fear. Once a deal closes, the risk is real: one overzealous employee can burn the month's credits by the 10th, and an agent left running overnight can drain a quarter's budget without a human touching the product.
The fix is to keep usage pricing and remove the fear. Give buyers visibility into spend, control over it, and assurance that the product will not stop working mid-quarter. The structure that delivers all three is a credit wallet.
A credit wallet is the customer-facing layer of credit-based billing: a pool of credits with per-user and per-agent visibility, spend limits, credit allotments, and top-up policies the buyer controls, all enforced at runtime. The products winning with usage pricing already ship one. Claude Code has a spend cap a buyer can set in one click. Cursor attaches credit allowances to seats. OpenAI sells prepaid API credits with budget caps. The wallet is the standard for selling usage at any scale. Enterprise buyers just demand it in writing before they sign.
This is its anatomy.
The first question every admin asks about a usage-priced product: how much is my team using, and who is using it most?
A wallet answers that without a support ticket. Show credit burn per user and per agent, over time, against the period's allotment. Show pacing: at this rate, the pool runs out on the 22nd. Surface the outliers, whether that is a power user defaulting to the most expensive model or a support bot retrying itself into a four-figure bill.
Agents need the same treatment as people. Every autonomous agent should appear in the wallet as its own line with its own burn history. If your customer cannot tell whether a human or an automation is consuming credits, they cannot manage either.
Visibility turns the first big invoice from a churn event into a conversation the admin saw coming.
Visibility tells the admin who is spending. Caps let them act on it.
Let the buyer set spend limits per user and per agent, per day, week, or month. A hard limit stops requests at the cap. A soft limit lets usage continue and bills the overage in arrears. The buyer picks the policy, and everyone gets a warning before anything stops. 80% is the common threshold.
Caps matter more for agents than for people. A human notices friction and slows down. An agent will loop until the pool is empty. A per-agent budget drawn from the company pool is the difference between an automation experiment and a budget incident.
Buyers bring up spend limits unprompted. Anthropic made the Claude Code spend cap settable in one click, and buyers cite it as a reason they trust the pricing. A cap the customer sets themselves does more for the deal than any assurance on a pricing page.
A cap is only as good as its enforcement. A balance checked nightly, or reconciled after the invoice, lets an agent overdraw the pool all afternoon. Limits have to be enforced at runtime: every request checks the live balance before work starts, and a request past the cap gets the policy the buyer chose, not a retroactive apology.
Concurrency makes runtime enforcement harder than it looks. When two agents draw from the same balance at once, a naive check-then-deduct races: both see 400 credits remaining, both proceed, and the pool goes negative. The fix is a lease, sometimes called a hold. Reserve credits when work starts, commit the amount actually used when it finishes, and release the reservation if it fails. Card payments have worked this way for decades with authorize, capture, and void. A credit system that supports agents needs the same primitive, or its caps are suggestions.
Enterprise already buys seats. Credits have to fit that model, and there are two ways to do it.
In a pooled model, the company buys a block of credits and everyone draws from it. It is flexible and efficient. No credits sit stranded on the seat of someone on leave. The risk is one team draining the pool for everyone, which is why pooled models depend on the caps above.
In a per-seat model, each seat includes its own credit allowance. This is how Cursor prices, and it maps to how procurement already thinks: cost per head, budgeted per head. The risk is rigidity. Light users strand credits while heavy users hit walls, and agents do not map to seats at all.
Neither model is wrong, and the choice belongs to the buyer. Pooled fits products with heavy agent usage. Per-seat fits products sold on headcount. Many products land on a hybrid: every seat includes an allowance, and allowances overflow into a shared company pool. Offer the choice. How a buyer answers tells you how they budget.
The worst thing a usage-priced product can do is stop working for a paying customer.
Running out of credits should never mean suspended service. Give the buyer paths forward: an overflow pool that absorbs bursts, self-serve top-ups, and auto top-up rules the buyer writes themselves, like "when the balance falls below 500, add 5,000." The customer sets the policy. The system enforces it. Nobody files a ticket at 2am because the support bot went dark.
Predictability cuts both ways. Buyers fear surprise bills, and they equally fear paying for credits that expire unused. Rollover fixes the second fear: carry some share of unused credits into the next period, or set expiry windows long enough that nobody feels cheated. Credits that silently expire read as breakage revenue, and enterprise buyers notice.
Get this section right and the renewal conversation starts from usage data instead of resentment.
One more component sits underneath all four, invisible to end users and decisive in enterprise evaluations: the ledger.
Every grant, burn, hold, top-up, expiry, and rollover should land in an append-only ledger the customer can export. Finance teams ask for it because prepaid credits are deferred revenue until they are consumed, and reconciling wallet activity against invoices is how both sides close the books. Under ASC 606, your own accountants will ask the same questions your customer's accountants do. A wallet without a ledger is a demo. A wallet with one survives procurement.
Usage-based pricing aligns price with value better than any flat fee. It also transfers risk to the buyer, and the buyer knows it. The credit wallet is how you take that risk back: visibility so nothing surprises them, caps enforced at runtime so nothing runs away, allotments that match how they budget, and top-ups so work never stops.
None of this is exotic. Claude Code, Cursor, and OpenAI all ship some version of this anatomy today, and buyers who have used those products now expect it from yours. Build the wallet before your first enterprise deal asks for it, because the deal will ask.
Credit-based billing prices a product in credits instead of raw units like tokens or API calls. Customers buy or receive credits and each action burns a set number. Credits give sellers a stable price abstraction over variable costs and give buyers a single number to budget against.
A credit wallet is the customer-facing layer of credit-based billing. It shows balances and per-user usage, enforces spend limits at runtime, and holds the top-up and rollover policies the buyer controls.
A top-up adds credits mid-period, either as a one-time purchase or through an auto top-up rule such as: when the balance falls below 500 credits, add 5,000. The customer should set the threshold and amount, not the vendor.
Check the live balance on every request before work starts, and use holds for concurrent workloads: reserve credits when a job begins, commit the amount actually used when it completes, and release the rest if it fails. Without reserve and commit, two agents drawing the same balance can double-spend it.
Show pacing against the period's credit allotment, warn before limits, let admins set spend caps for each user and agent, and never suspend service without a top-up path. Predictability comes from controls the buyer holds.
Rollover builds trust. A common policy carries 50% of unused credits into the next period with an expiry date. Hard expiry with no rollover trains customers to distrust prepaid credits.
Set per-user and per-agent caps that draw from a shared company pool. Hard limits stop requests at the cap. Soft limits allow usage to continue and bill the overage in arrears. Warn everyone at 80%.
