Subscription vs Usage vs Hybrid
Trade-offs of the three pricing models for agent products — how non-zero marginal cost changes the classic SaaS equilibrium.
The subscription-versus-usage trade-off was a classic SaaS-era debate. Agent products add one more dimension to that debate — service marginal cost is not zero. This shifts the equilibrium of “which model is better for both customer and vendor”.
Three models from the customer’s perspective
| Dimension | Subscription | Usage-based | Hybrid |
|---|---|---|---|
| Budget certainty | High (fixed monthly fee) | Low (bill fluctuates) | Medium (base fixed + overage varies) |
| Entry barrier | Medium (commit to fixed monthly) | Low (small trial, no commit) | Medium |
| Heavy-use incentive | Strong (paid, may as well use) | Weak (each use is billed) | Medium |
| Finance approval complexity | Low (single approval) | High (monthly bill changes) | Medium |
| Perceived fairness | Medium (light users feel cheated) | High (pay for what you use) | High |
Three models from the vendor’s perspective
| Dimension | Subscription | Usage-based | Hybrid |
|---|---|---|---|
| Revenue predictability | High (stable MRR) | Low (bill varies with usage) | Medium |
| Gross margin stability | Low (heavy users compress margin) | High (cost scales with revenue) | High |
| Customer-acquisition fit | High (easy to quote) | Medium (must educate) | Medium |
| Cap-management complexity | High (must hard-cap to prevent abuse) | Low (more use = more pay) | Medium |
| Investor valuation | High (closer to SaaS) | Medium (closer to usage-API cos.) | Medium-high |
Which to pick when
Conditions favoring subscription
Satisfy three or more:
- Task complexity is uniform (same-class tasks within 2× token range)
- User frequency is concentrated (heavy users < 10%)
- Customer base is SMB or individuals, sensitive to bill volatility
- Sales cycle is short, simple quoting is required
- Competitors are subscription-based (e.g., Cursor, early GitHub Copilot)
Implementation note: must pair with hard tier caps — see economics/controls-and-roi. Subscription without caps + agent product = guaranteed loss.
Conditions favoring usage-based
Satisfy three or more:
- Task complexity varies widely (same-class tasks differ > 5× in token use)
- Customers are large enterprises with IT budget processes supporting monthly reconciliation
- Product positioning is “infrastructure / API” rather than “application”
- User base is mature and understands token-billing logic (e.g., OpenAI / Anthropic API customers)
- Integration with existing per-API billing products
Implementation note: bill transparency is core UX. Customers must see real-time usage and month-end projected bill daily. Unannounced “month-end bill shock” is the top churn driver for usage-based pricing.
Conditions favoring hybrid
Satisfy three or more:
- Customer base spans SMB to enterprise
- Task complexity is bimodal (many light tasks + few heavy tasks)
- Sales needs both simple quoting (subscription floor) and large-customer overage capacity
- Team has operational capacity to manage two billing mechanisms
Implementation note: make overage thresholds visible to customers in advance. Subscription + “overage by token” feels like “secret price increase” to customers if not surfaced clearly; hybrid becomes the worst of both worlds — losing subscription simplicity while inheriting usage-billing disputes.
Switching cost
Pricing models are difficult to change after contracts are signed. Difficulty of switching (industry experience):
| Direction | Difficulty | Primary friction |
|---|---|---|
| Subscription → Hybrid | Medium | Existing customers feel “charged extra” — 90-day notice + grandfathering |
| Usage-based → Subscription | High | Customers have established usage-billing finance workflow |
| Subscription → Usage-based | Very high | Contracts and procurement workflows need full rework; high churn risk |
| Hybrid → either side | Medium | Depends on specific contract terms |
The cost of choosing wrongly at the start far exceeds the cost of switching later — pricing model selection should be a pre-condition for product GTM strategy, not a post-launch adjustment.
Cross-section connections
- Cost foundation for each model: economics/cost-model
- Cap mechanism design: tier-design
- Customer migration operations: playbooks