Pricing software that does work is a different problem from pricing software that provides access, and most of the awkwardness in agent pricing comes from using the second model for the first.
A seat used to be a decent proxy for cost. Ten users, ten times the support surface, roughly ten times the infrastructure. With an agent that proxy collapses: two customers on the same plan can differ by three orders of magnitude in inference spend, and nothing about the seat count tells you which is which.
So everyone lands on metering. The interesting questions are what you meter and, much more importantly, when you charge.
The attempt is the wrong place to charge
The obvious implementation charges when the work is attempted, because that is when the cost is incurred. It is defensible on the invoice and it is wrong on the incentives.
Consider what it means. A generation fails and the user pays. A generation succeeds but produces something unusable and the user pays. Your reliability problems become their line item. And because failures are now revenue rather than cost, the pressure that would otherwise force you to fix the failure rate is partially removed.
You do not have to be cynical for this to bite. Nobody decides to profit from failure; it just stops being urgent.
The recurring complaint in public reviews of agent products is some version of this — charged for work that did not happen, refunds owed under the vendor's own policy and never processed. Note that the policy usually exists. What is missing is that honouring it requires a human to act, and humans under load do not.
Charge at accepted output
The alternative is to move the charge as late as you can: to the point where the user has seen the output and accepted it.
For work an agent prepares on its own schedule, this falls out naturally from an approval boundary — nothing is held or spent while the draft sits waiting, and the charge lands on the approval. A draft you decline is free, not refunded. There is nothing to reconcile because nothing was taken.
For work a user triggers and waits on, you cannot defer to an acceptance that may never come, so the charge goes up front. That is fine as long as the failure path is automatic: wrap the whole operation so that any exception refunds the charge before rethrowing, and log loudly when a refund itself fails, because a silently failed refund is indistinguishable from theft from the user's side.
The honest consequence: you eat the cost of your own failures. Every failed generation is inference you paid for and cannot bill. That is a real number and it belongs in your model rather than being discovered later. It is also the entire point — it is the arrangement in which your interest and the user's are pointed the same way.
Idempotency is not optional
Here is the part that is usually learned the hard way.
Agent systems retry. Timeouts retry. Users double-click. Background jobs resume after a crash and re-enter the same code path. A queue delivers at least once, which means sometimes twice.
If your charge is a plain decrement, every one of those is a double bill. And it will not present as a billing bug — it will present as a user insisting they were charged twice for one action while your logs show two clean, successful charges, because that is exactly what happened.
The fix is to make the spend idempotent at the level where concurrency is actually resolved, which is the database. One function, keyed on the attempt rather than on the action type, that will not bill the same attempt twice however many times it is called, with the row locked while it decides. Not an in-process flag, which two instances will happily both pass.
Ours also does a lazy monthly reset in the same function, which is worth mentioning only because the alternative — a scheduled job that resets balances — is a second system that can fail independently and leave a user unable to spend credits they are owed.
One pool, not per-feature budgets
We originally metered per chapter of the product, with separate ledgers. It was tidy in the schema and bad for users, and we deprecated it.
The failure is easy to state: a user has credit and cannot spend it on the thing they need right now. Whatever the pricing page says, that reads as a bug. It also generates a support conversation that has no good answer, because the honest one is "our accounting is shaped like our codebase".
One shared pool with published per-action costs is easier to explain, easier to reason about as a user, and removes the whole category. The cost is that you lose per-feature revenue attribution — which you can recover from transaction metadata anyway.
Publish the price before the work
A charge is a decision if the user sees the number first and a surprise if they see it afterwards. Same amount, entirely different experience.
Concretely: the cost appears on the card being approved, next to what will be produced, before anything is spent. This is nearly free to implement and it is most of what people mean by fair pricing — not the level, the ordering.
What we are not sure about
Credits themselves. They are an abstraction over cost, and abstractions over cost are convenient for us and slightly opaque for the user: "150 credits" requires a translation step that "50 posts" does not. We use them because the underlying actions genuinely differ in cost by an order of magnitude and a single unit would over- or under-price most of them.
Whether that trade is right is not settled. If it turns out people cannot predict what a month costs them, the unit is wrong however defensible the arithmetic is — and predictability may be worth more than precision.
If you want to see the ordering in practice — cost shown before the work, nothing spent without a decision — the launch video generator is free and needs no account. Our comparison page is honest about where other tools are the better choice.