Usage-based pricing charges a customer for how much of your product they consume: API calls, messages, compute, credits. Outcome pricing charges for a result: a resolved request, a completed task, a job kept done. The usual way to choose between them is to weigh predictability against value alignment. When an AI agent does the work, there is a simpler test: who controls how much usage it takes to get the result?
Usage-based pricing works best when the customer controls the meter. They decide how many queries to run, how many messages to send, how big a warehouse to spin up. The bill follows their choices, so it feels fair. When your own AI does the work for the customer, that changes. Your agent decides how many steps a task takes, how often it retries, and how many tool calls it makes. The meter is now in your hands, and a usage bill charges the customer for your efficiency, or for your lack of it.
The definition pages that rank for this term explain the mechanics well and stop there. They treat usage as a stand-in for value, which held for twenty years because a person was driving the usage. The argument of this post is that the right model depends less on your industry or your customer's budget than on who is driving the work, and that one software company will often need both models at once.
What usage-based pricing is
TechTarget defines usage-based pricing as a consumption-based model in which "customers are charged only when they use a product or service." It lists three common forms:
- Pay as you go. The customer pays only for what they consume, such as a virtual machine billed by the minute or hour.
- Per-unit pricing. Charges follow resource usage, also called price per unit or pay per use.
- Tiered pricing. Each tier comes with an allowance, and usage beyond it moves the customer to the next tier.
The model is mainstream. Metronome's State of Usage-Based Pricing 2025 reports that 85% of surveyed software companies have adopted it, and that 77% of the largest software companies have some level of it. Stripe's billing docs call it "a common pricing model for SaaS businesses," and Stripe now names Metronome, which it acquired, as its primary usage-based billing platform.
Two familiar examples show the shape:
- Snowflake bills compute in credits by warehouse size, "billed by the second with a one-minute minimum." An X-Small warehouse uses 1 credit per hour.
- Twilio charges a base rate of $0.0083 per 160-character SMS segment sent or received in the US.
In both cases, the customer decides how much happens. Snowflake does not choose how many queries you run. Twilio does not choose how many texts you send. That is the quiet condition that makes the model feel fair.
Usage-based pricing vs subscription
Many searchers are really comparing usage pricing with a flat subscription, so it is worth settling that first.
A subscription charges the same amount each period whether the product is used or not. Usage pricing moves with consumption. Tomasz Tunguz put the trade-off plainly: application software usually sells seats because, in his words, "The predictability of fixed costs outweighs the benefits of flexibility," while infrastructure usage varies more, so usage pricing fits it better. He also flagged two practical problems: picking a unit that tracks value, and avoiding "sticker shock" in the first bill.
| Subscription | Usage-based | |
|---|---|---|
| Customer pays for | Access for a period | What they consume |
| Predictability for the buyer | High | Lower, unless capped |
| Fits best | Application software used by people | Infrastructure and APIs |
| Main risk | Paying for shelfware | A surprise bill |
Neither column says anything about whether the customer got what they needed. That is the gap outcome pricing tries to close.
What outcome pricing changes
Outcome pricing ties the bill to a result instead of activity. Retell AI's comparison describes usage as something that "measures activity rather than success," while outcome pricing "ties the billing unit to what the customer needs done, such as a resolved request."
The clearest published example is Intercom's Fin, priced at $0.99 per outcome. Intercom counts an outcome when a customer confirms the issue is resolved, when they do not ask for more help after Fin responds, or when Fin completes a workflow, and charges once per conversation.
Compare that with a usage price for an agent. Salesforce Agentforce sells Flex Credits at $500 per 100,000, and an Agentforce action costs 20 credits. Under that model, an agent that takes four actions to answer a question costs twice as much as one that takes two, whether or not either answer helped.
Retell makes the efficiency point with an example worth repeating: if a provider uses automation to cut the agents it needs from 100 to 70, a per-agent price means the provider loses 30% of its revenue, "essentially punished for becoming more efficient." Retell also lands close to the test this post argues for: "when customers control the agent, usage-based pricing offers transparency," and "when the vendor owns the result, outcome-based pricing creates alignment."
We would push that one step further. The question is not only who controls the agent. It is who controls how much usage a result takes.
Who controls the meter
Run every pricing decision through that one question.
The customer controls the meter. They write the queries, send the messages, or point their own AI agent at your API. Usage pricing is honest here. The customer can see what drove the bill and can change it. Charging per outcome would be strange, because you do not own the result: you cannot control whether their agent asked the right question.
You control the meter. Your AI does the work inside your product on the customer's behalf. It decides how many steps to take and how often to check back. Usage pricing is now awkward in two directions. If your agent is wasteful, the customer pays for your waste. If you make it efficient, your revenue drops, which is Retell's 100-to-70 problem. In this case the customer should pay for the result, and you should carry the cost of producing it.
This is why the same software company can need both models. The usage on your API, your MCP server or your gateway, where customers and their own agents call you, is customer-driven. The work your AI owns for each customer is vendor-driven. Pricing both the same way gets one of them wrong.
We covered the risk side of each model in AI agent pricing models, compared by who pays when it fails. Who controls the meter is the earlier question: it tells you which of those risks you are signing up for.
Outcome pricing is a promise to deliver
Outcome pricing sounds like the safe choice for buyers, and often it is. It is also a much bigger commitment for the vendor than a meter. You need to be able to do the work in your own product, define "done" in your own data, and show the customer what happened. We wrote about that in outcome-based pricing: delivering the outcome is the hard half.
The Intercom definition also shows where outcome pricing gets argued about. "They don't ask for more help after Fin responds" counts as an outcome. Sometimes that is a resolution. Sometimes it is a customer who gave up. Every outcome price is only as good as its definition of done, and the vendor writes that definition.
For ongoing work there is a cleaner unit than a per-event outcome: the job. A per-event price works for a single answer. It works less well for work that never really ends, like keeping every location of a customer compliant or getting every new hire through onboarding. That work does not happen once. It holds a state, for example 11 of 12 locations compliant, and needs attention whenever that state slips. Customers understand paying a monthly price for a job kept done, the same way they would pay a person or an agency to own it.
An illustrative example: an LMS like Lessonfield could sell its customer Pellmark Training a job, "get every new hire through onboarding," as a monthly subscription. Pellmark pays for the job. How many reminders, enrollments and manager nudges the AI needs that month is Lessonfield's problem, not Pellmark's. The price is outcome-based in spirit and subscription in form, which is also the easiest shape for a finance team to approve.
How to choose
A short checklist:
- Who decides how much activity happens? If the customer does, start with usage pricing and add caps or tiers to remove the surprise bill.
- Can you define done in your own data? If you cannot tell from your product whether the result happened, you cannot charge for it. Use usage or a subscription until you can.
- Is the work a single event or an ongoing job? Single events suit a per-outcome price. Ongoing jobs suit a subscription for the job.
- Will efficiency gains help or hurt you? If getting better at the work would lower your revenue, the price is attached to the wrong thing.
- Can the customer see what they paid for? Usage needs a clear meter. Outcomes need a record of what was done. Either way, the bill should never be a mystery.
Where Aimdoc fits
Aimdoc connects to your product and your systems and delivers the work your customers need, so you can sell that work as a service. There are two kinds of money here, and they stay separate. What you charge your customers for a job is your price, set by you and billed through your own Stripe account, usually as a subscription for the job. See selling services.
What you pay Aimdoc is prepaid credits for the AI's work, with spend caps you control. That is usage-shaped on purpose, and it passes the test above: you decide which jobs to run and set their budgets, so you control the meter. Aimdoc never charges you per outcome.
FAQ
What is usage-based pricing?
A model where customers pay for what they consume, such as API calls, messages, compute time or credits, instead of a fixed fee. Common forms are pay as you go, per-unit pricing and tiered allowances.
What is the difference between usage-based and outcome-based pricing?
Usage-based pricing charges for activity. Outcome-based pricing charges for a result, such as a resolved request. Usage fits when the customer controls how much activity happens. Outcome pricing fits when the vendor does the work and owns the result.
Is usage-based pricing better than a subscription?
It depends on how much usage varies and who drives it. Tunguz notes that application software usually favors seats for predictability, while infrastructure suits usage pricing. Caps and tiers can make usage pricing as predictable as a subscription.
Should AI agents be priced by usage or by outcome?
If the customer runs the agent, usage is the honest choice. If your own AI does the work for the customer, charge for the result or for the job, and carry the cost of producing it yourself.
Your customers want the work done, not a meter to watch. Aimdoc delivers that work through your product and lets you sell it as a service at a price you set. Start free, or book a demo.