How it works
The customer buys a metered unit — credits, tokens, checkpoints — and spends it on requests whose cost depends on how much work the software does. The work is probabilistic: the same request can succeed first time, partly succeed, or fail.
Because billing follows effort rather than result, an incorrect or incomplete answer is charged like a correct one. Fixing it takes another request, which is charged again. Reverting it does not return what was spent. The customer, not the vendor, carries the cost of the gap between what was asked for and what was delivered.
The pattern is strongest where three conditions meet: usage is outcome-insensitive, the customer cannot reliably know the cost before the work runs, and failed or incorrect output can generate additional customer-paid work.
Recognition checklist
What to look for
Charged by effort, not result
The price follows the work the software performed, whether or not that work did what was asked.
No price before the work
The cost of a request is visible only while it runs or after it finishes.
Wrong output still counts
Erroneous, incomplete or regenerated output consumes the same paid units as a correct result.
Repairs are billed as new work
Asking the software to fix its own output is charged like any other request.
No restoration path
Reverting a bad change, or reporting a failed one, does not return the units spent on it.
Documented cases
v0, Replit, Cursor and Lovable.
v0, Replit and Cursor moved to effort- or token-based charging in 2025 and bill AI work that corrects earlier output like any other work; each drew public complaints about cost after the change.
Lovable has the most explicit contract wording among the cases reviewed. Its August 2026 terms state that credits are consumed according to the effort and resources an AI action uses, regardless of the outcome, and are neither refunded nor restored when output is erroneous, incomplete or must be regenerated, except where the law requires otherwise. Its documentation states that no credit estimate is shown before a Build mode request runs, and that reverted messages still count.
Lovable also gives each account ten free fixes for build errors and security findings, each restored after 24 hours; beyond ten, fixes are charged as standard usage. It is the only company in the set that documents a free-fix allowance. Lovable is cited for the explicitness of its terms, not as the worst case.
Read the full Lovable investigation → — standard company investigation, no score assigned.
Correction-Cost Transfer is a newly adopted Lexicon entry. Company assignments are recorded as CHI assessments test for it.
Important distinction
What this pattern does not claim.
It does not claim that charging for compute is hostile. AI work has real costs, and metering it by effort is the industry norm. It does not claim that any company causes errors in order to sell more usage.
What it measures is who carries the cost of the product’s mistakes, and how much protection the customer has: free repair allowances, outcome-sensitive pricing, prices quoted before work runs, and restoration when work fails. More of these means a weaker case; their absence means a stronger one.
The distinction from Promissory Product Monetization is timing. That pattern charges for functionality that does not yet exist. This one charges for functionality that was attempted and did not work.