Credits are a bad pricing model and I'm still using one
Every AI product lands on credits eventually. The underlying cost is real and variable and you can't absorb it forever, so you pass it through. Fine.
The problem is that credits break the moment the user has to guess. Nobody knows what 500 credits buys them. Everybody knows what $19 buys them.
The failure case is worse. If a generation comes back wrong, the customer already paid for it. So every bad output turns into a refund conversation where you either quietly eat the cost or argue with someone about whether their output was actually bad. Arguing costs more than the credits do, every time.
The rule I keep coming back to is that a run which fails your own quality check shouldn't bill at all. It moves the judgement onto you instead of making the customer fight to get it back. Not clever, just cheaper than the alternative.
So if you're pricing on credits, what does your refund path actually look like? Most founders I ask haven't decided. They find out during their first bad week.
Replies
Founder here, and I sell an action-metered product, so this is a live question for me rather than a theory.
Two things I would separate that the credits conversation usually merges.
First, on nobody knowing what 500 credits buys. I do not think that is a copy problem, and better explainer text will not fix it. It is a units problem. Denominate the unit in the customer's noun instead of yours. Not a credit, but a product added, an article published, a site rebuilt. The guessing disappears because the unit is a thing they already wanted. It also has a useful side effect: it forces you to meter only actions that produce something the customer can name. Anything you cannot name in their vocabulary is probably something you should be absorbing, because you are about to charge them for your implementation detail.
Second, your rule, which I agree with and want to warn you about at the same time.
"A run that fails your own quality check should not bill" is right and I run it. But it hides the fact that failed and bad are different sets, and only one of them is machine-checkable. My gates catch structural failure: empty extraction, missing required fields, wrong locale, output that does not satisfy its own schema. They do not catch well-formed and mediocre. So the rule removes the argument for most cases by count and almost none of the cases that produce the actual email, because the person who writes in is the one who got something well-formed that they did not like. Worth having, just do not expect it to retire the refund conversation, because that conversation was never mostly about the failures your checker can see.
And the warning. The moment the gate is load-bearing for billing, a bug in the gate becomes a revenue bug, and gate bugs are quiet. I had a quality gate that scored a single-language plan against four languages, so correct output was being marked as failing. Nothing crashed, nothing alerted. Content simply sat unpublished and read like a content problem. If billing had been hanging off that gate I would have been refunding correct work for weeks and filing it under generosity rather than under bug. So if you wire billing to the checker, the checker needs the monitoring you would give a payment path, not the monitoring you would give a heuristic.
The direct answer to your question, since you asked. For the mechanical class there is no refund path, because the charge never happens. The meter fires on the action that produced a durable artifact, and a re-run after a failure does not charge again. For the well-formed but disappointing class I do not have an automated answer and I doubt one exists, because that judgement is not machine-checkable, and automating it only relocates the argument to whether the checker was right. So I absorb those, and I treat the rate as a product signal rather than as a support cost.