Pricing
The hard part of pricing an agent product is not only that tokens cost money. The deeper issue is that task cost, task value, and failure risk all change with user behavior. Pricing turns that uncertainty into a structure the customer can buy and the vendor can sustain.
Pricing is therefore not a repeat of the cost model. It designs three things:
- Why the customer pays.
- Which costs and failure risks the vendor absorbs.
- How both sides share changes in usage, model prices, or task complexity.
Why SaaS Pricing Breaks
Traditional SaaS seat pricing assumes low marginal cost. Heavy users are usually more valuable because they increase retention and expansion without materially increasing service cost.
Agent products are different. Heavy use can mean high value, or it can mean high cost, low success rate, repeated retries, and human review. A flat seat fee pushes usage risk onto the vendor. Pure usage pricing pushes budget uncertainty onto the customer.
Good agent pricing handles three risks:
| Risk | What happens if ignored |
|---|---|
| Usage risk | A small number of heavy users consume margin |
| Success risk | Charging for failed tasks damages trust |
| Price-drift risk | Model, cache, region, or runtime price changes make contracts stale |
Three Base Models
Subscription
The customer pays a fixed monthly fee that includes a task volume or budget.
Good fit: clear task scope, relatively predictable usage, customers needing budget certainty, and sales motion requiring simple quoting.
Risk: without caps, heavy users compress margin; with overly tight caps, users feel the subscription is unusable.
Usage-Based
The customer pays by task, token, runtime, successful outcome, or another business unit.
Good fit: task complexity varies widely, customers can reconcile usage, the product behaves like API / infrastructure, or value tracks usage closely.
Risk: customers fear bill volatility; if the billing unit is too technical, non-engineering buyers struggle to understand it.
Hybrid
A base subscription gives budget certainty, while overage is billed by usage or moved into a higher tier.
Good fit: most agent applications, especially when the product needs simple procurement and support for heavy use.
Risk: if overage is unclear, customers feel secretly charged; if overage is too generous, the vendor still absorbs too much risk.
See Subscription, Usage, and Hybrid for the detailed trade-off.
Billing Units Should Track Customer Value
Do not expose tokens to customers by default. Tokens are an internal cost unit, not always a customer value unit.
Common units:
| Billing unit | Customer clarity | Vendor risk |
|---|---|---|
| Seat | High | High, requires strong budget controls |
| Successful task | High | Medium, requires clear success criteria |
| Usage / token | Low to medium | Low, passes cost through directly |
| Workflow package | High | Medium, strong fit for vertical products |
| Verified value | High, but needs calibration | Medium to high, harder to audit |
The closer a unit is to customer value, the easier it is to sell. The closer it is to internal cost, the easier margin is to control. Pricing design balances the two.
What Tiers Do
Tiers are not just feature gates. In agent products, tiers usually package four differences:
- How many tasks or how much budget the customer can use.
- Which model routing is default.
- Which tools, connectors, and execution environments are available.
- What happens after overage.
Detailed tier design is covered in Tier Design. The important point here is that upgrades should mean the customer can complete more work, harder work, or more reliable work, not merely unlock a feature checklist.
Price Drift
Model and infrastructure prices change. New models can also change token usage, step count, and success rate for the same task. Contracts that hard-code overly specific model prices become hard to maintain.
More durable approaches:
- Promise customer-legible capacity such as tasks, successful outcomes, budget pools, or workflow packages.
- Keep an internal cost model that recalculates margin from current official prices, routing, and usage history.
- For enterprise contracts, define overage, model upgrades, region requirements, hosted runtime, and human review boundaries explicitly.