Usage pricing charges a measurable resource or activity. Credits translate diverse actions into a vendor-defined unit. Outcome pricing charges when a defined result occurs. Compare them by modeling the same useful workload, auditing the billable boundary, and testing cost in normal, failure, and high-volume cases.
What this guide covers
- the defining questions for each model;
- predictability, auditability, and risk trade-offs;
- a unit-economics worksheet;
- contract and monitoring questions.
Usage-based pricing
Examples include tokens, minutes, executions, records, storage, or API calls. Stripe's usage-based billing documentation shows the operational importance of meters and meter events.
Strengths:
- the bill can track measurable consumption;
- the unit may be independently observable;
- low usage can produce low cost;
- marginal economics can be modeled directly.
Risks:
- consumption may not equal value;
- retries and failed work may still bill;
- high variance makes budgeting difficult;
- unit rates can interact with tiers, minimums, and commitments.
Credit pricing
Credits package heterogeneous operations behind one balance. Clay's pricing and AI pricing documentation are useful examples of why the action-to-credit conversion matters.
Strengths:
- one balance can cover many providers or features;
- the interface can be simpler than many micro-rates;
- subscriptions and rollover can provide predictability.
Risks:
- actions consume different amounts;
- conversion can be estimated or variable;
- “1,000 credits” has no meaning outside the conversion table;
- price and conversion can move separately.
Outcome-based pricing
Examples include a resolved support issue, qualified meeting, successful transaction, or completed workflow. Intercom's pricing FAQ shows why plan context and the definition of a resolution matter.
Strengths:
- the bill is closer to the value claim;
- vendor and buyer incentives may align;
- easier business-level comparison when the outcome is clear.
Risks:
- outcome definitions can be disputed;
- quality and durability may be missing from the event;
- abandoned, repeated, partial, or escalated cases need rules;
- the buyer may pay for the automated outcome and remaining human work.
Compare the billable boundary
Ask the same questions for every model:
- What exact event creates a billable unit?
- Who measures it and can the buyer reconcile it?
- Are tests, failures, retries, previews, and duplicates billed?
- What dimensions change unit consumption?
- Is the unit definition fixed for the contract term?
- What is included, pooled, rolled over, or expired?
- What happens at the limit?
- Are there minimums, tiers, add-ons, or required seats?
- How are disputes and corrections handled?
- Does the unit capture quality, or only completion?
Model one useful workload
Define the useful output first, such as:
- accepted engineering task;
- verified support resolution without repeat contact;
- qualified sales record meeting a known standard;
- completed workflow with correct downstream state.
Then model each pricing unit:
| Input | Usage model | Credit model | Outcome model |
|---|---|---|---|
| Useful outputs/month | |||
| Attempts/output | |||
| Billable units/attempt | |||
| Failed billable attempts | |||
| Base commitment | |||
| Variable/overage | |||
| Human overlap | |||
| Cost/useful output |
Run expected and high cases. The high case should vary failure rate and workload complexity, not merely volume.
Compare risk allocation
| Question | Usage | Credit | Outcome |
|---|---|---|---|
| Cost predictability | depends on stable volume | moderate if conversion stable | depends on outcome volume |
| Unit transparency | high when directly metered | variable | high only if definition/audit is clear |
| Failed-work risk | often buyer | usually buyer | often vendor, but check rules |
| Quality alignment | indirect | indirect | potentially stronger, definition-dependent |
| Vendor flexibility | rate/tier changes | conversion and bundle changes | outcome definition and price changes |
No model is universally fair. The right model matches a measurable value boundary, makes failure treatment explicit, and gives both sides enough observability to reconcile the bill.
Monitor two prices for credits
Credit offers have two moving parts:
- currency per credit;
- credits per action.
A stable monthly subscription can become more expensive if the action conversion increases. Track both, plus allowance, rollover, and over-limit behavior.
Decision worksheet
Useful output:
Expected/high monthly volume:
Billable unit:
Definition/source:
Who measures it:
Dispute mechanism:
Base commitment:
Included units:
Unit/credit/outcome rate:
Consumption per attempt:
Attempts per useful output:
Failure/retry treatment:
Human overlap:
Expected cost/output:
High-case cost/output:
Budget guardrails:
Terms that require monitoring:Use EXVIV's pricing-monitoring page, market map, and Evidence Compare to keep the public source attached to the modeled unit. EXVIV's own pricing should be evaluated by the same rule: identify the plan, entitlement, and actual unit rather than relying on a brand claim.
Related EXVIV research
Sources and further reading
Method note
This framework compares pricing mechanics; it does not determine value or negotiate contract terms. Recheck current definitions and rates within 30 days, model actual failure behavior, and involve finance/legal owners for material commitments.