business resources
Credit-Based Billing, Explained: Why the Balance Is the Hard Part
11 Sept 2026
Three agents hit the same account at the same instant. Each one reads the balance, sees a dollar and change left, decides it has room, and runs. All three run.
That is the whole failure in one line.
It is also why I've stopped thinking of credit-based billing as a pricing decision. The pricing page is an afternoon's work. Notion sells Custom Agent usage at $10 per 1,000 monthly credits as of September 2026, and Canva meters its AI features on the same idea.
So here's the short answer, since you probably came for one: credit-based billing works when the balance is kept as a double-entry ledger and the spend check happens before the compute runs. That's why runtime infrastructure like Stigg now sits alongside billing systems as its own enforcement layer.
Why credit-based billing spread so fast
Credit-based billing is the model AI companies reach for when one customer action can cost anywhere from a fraction of a cent to several dollars.
That variance is the whole reason. Per-seat pricing assumes every seat costs about the same to serve, which was a fine assumption when the marginal cost of a login was zero.
It stops being fine when one user's afternoon involves a model call that thinks for nine minutes.
Credits absorb the variance. You sell a pool, you map actions to a rate, and the expensive user pays more without you publishing a price for every model in your stack.
Customers are not thrilled about this, and the most common objection is fair. A customer who bought 10,000 credits often cannot tell you what 10,000 credits buy.
That's a genuine cost of the model, and better documentation doesn't fix it. Showing the balance draw down in something close to real time does.
A credit balance behaves like a ledger
A credit balance is a portfolio of grants, each with its own expiry date, cost basis, and category. Most teams start by storing it as an integer in a database column, and that version survives roughly one billing cycle.
Picture a single customer holding 5,000 credits from this month's subscription, 20,000 they prepaid at a volume discount last quarter, and 500 you handed them as an apology after an outage.
Which pool drains first is a margin decision. If you don't make it deliberately, your code makes it for you, usually on the credits you sold at full price.
The fix is the one banks landed on centuries ago: an append-only, double-entry ledger where every debit and credit is an immutable entry. You never update a balance. You write an entry and derive the balance from the entries.
That's what makes the number defensible when finance asks why last quarter's revenue recognition moved under ASC 606, and it's what lets you replay a customer's history when they open a dispute.
What should a credit system get right before launch?
Five things, and I'd treat this list as a floor.
Atomic debits. Two concurrent requests must never both succeed against the same last credit. This is where homegrown systems have their first outage.
Idempotency keys on every write. Retries happen. Double-charging a customer because your gateway retried a timeout is the kind of bug that costs you the whole account, and it is entirely preventable.
Expiry and burn order as configuration. Both will change the moment sales negotiates something new, and you don't want a deploy in the middle of that conversation.
A choice between hard and soft depletion. Hard stops the request at zero. Soft lets the balance go negative and invoices the overage, which finance often prefers and which your support team will not enjoy explaining.
A balance the customer can see. Most of the trust problem with credits is a visibility problem, and it's the cheapest of these five to fix.
What changes when your customer is an agent?
Agents turn a credit system from an accounting feature into a production dependency.
If your product is one human clicking one button and waiting for one answer, a nightly reconciliation job is a reasonable place to start. I'd build that, ship it, and move on to something customers can see.
Agents break the arithmetic. One instruction fans out into a dozen sub-calls, each one a spend decision, several of them running at the same moment.
The pipeline most teams already have (serve the request, log the usage, bill at month end) has no opinion whatsoever about whether the request should have run.
Financial-grade timing works the other way around: check and hold synchronously, run the compute, settle asynchronously. The synchronous check is the part that's hard to retrofit, because it lives in the request path where every millisecond is visible to your customer.
Where homegrown credit systems run out of road
The first version of a credit system is a good build. It's a table, a decrement, and a check, and a competent engineer ships it in a sprint. I wouldn't hire a vendor for that.
The road runs out somewhere around the third pricing change.
By then the ledger has grown grant categories, the enforcement path has grown a cache, finance wants a cost basis on every debit, and sales has promised an enterprise buyer that one credit pool cascades into team-level budgets.
You now own a financial system with an on-call rotation.
Miro's team put the honest number on this before it went looking for infrastructure: three engineers for three months. After buying instead, it shipped AI credits in under six weeks and moved pricing changes from a six-month project to a few days.
That's the trade companies like Stigg are priced against. You keep your billing system, your invoicing, and your warehouse, and you hand off ledger correctness and the enforcement path.
The trade has a real cost, and I'd want it named out loud. You're taking a dependency in your request path, which is the most sensitive place in an architecture to take one, so the latency budget and the failure mode both deserve hard questions before you sign anything.
Credit systems are on their way to becoming boring
Every layer of infrastructure goes through this. Payments were a differentiator, then they were a Stripe integration. Auth was a quarter of engineering work, then it was four lines of config.
Credit systems are early on that curve. Today the ledger and the enforcement layer are things AI companies build for themselves, usually twice, and the second build is the one that survives contact with a real enterprise contract.
My guess is that within two years nobody will describe their credit ledger as a technical achievement, in the same way nobody brags about their password hashing.
The teams that get there first won't win because they picked the elegant architecture. They'll win because they spent the saved quarters on the only part of this a customer ever sees: a balance that makes sense.
FAQs
Why do customers push back on credit-based billing?
Because a credit is an abstraction over a price, and nobody can budget against an abstraction they can't convert into dollars. The fix is visibility: a live balance and a rate card in plain language.
How many credits should one action cost?
Set your credit-to-dollar rate first, then map each action to its cost of goods plus your target margin. Round to numbers a person can hold in their head, because a customer doing long division to understand your pricing will assume you're hiding something in it.
Is credit-based billing better than per-seat pricing?
Credits fit products where the cost to serve varies by an order of magnitude or more between users, and seats fit products where it stays flat. Plenty of AI companies now run both: seats for access, credits for consumption.
Who should own the credit system inside a company?
Engineering owns the ledger and the enforcement path, finance owns the rate card and revenue recognition, and both read from one source of truth. Split that across a billing tool and a spreadsheet and the two numbers stop matching, which is the gap runtime layers like Stigg close.
