Usage-based pricing: models and real examples

Usage-based pricing means the customer's bill depends on how much they used: requests, tokens, emails, credits or compute seconds, multiplied by a price per unit. A pure unit price is the simplest version, and many APIs add a free allowance, tiers, a monthly base fee or prepaid credits on top. This page shows how each model turns usage into a bill, with worked numbers and the real prices of six public APIs (checked October 2026).

What is usage-based pricing?

With usage-based pricing, the amount on the invoice follows a counted quantity. The simplest form is units times price: 250,000 requests at $0.40 per 1,000 is $100. Real plans add fixed parts, like a monthly fee or a minimum, and let the unit price change with volume, but the bill still moves with usage.

Seat pricing follows the number of users instead, and a flat plan stays the same until the customer switches plans. Usage-based billing is the machinery behind the price (counting, rating and invoicing), which our usage-based billing guide covers. The business side, such as free plans and marketplaces, is in the API monetization guide.

Choosing a value metric

The value metric is the thing you count. Choose it before you set any prices, because changing it later means re-pricing every customer. A good one:

• grows as the customer gets more out of your API,
• can be estimated from the customer's own traffic,
• tracks your costs, so big customers stay profitable,
• can be counted exactly, by you and by the customer,
• is hard to game, for example by packing 1,000 records into one request.

Our rule of thumb: charge per request unless your most expensive calls cost you several times more than the cheap ones. When they do, price the expensive operation separately or switch to weighted credits.

Usage-based pricing models

The prices in this section are made up to keep the arithmetic simple; real ones follow in the next section.

Per-unit pricing

One price for every unit: at $0.50 per 1,000 requests, a million requests cost $500. Quote the price per 1,000 or per million when a single unit costs a fraction of a cent, and round once, on the total, rather than per request.

It's the easiest model to explain and to check. It doesn't reward volume, so large customers will ask for discounts, and it gives you no floor. A customer who sends 2,000 requests owes $1.00, and about a third of that goes to Stripe at standard US rates.

Tiered pricing: graduated vs. volume

Tiers change the unit price as usage grows. Take these three, priced per 1,000 requests:

For a customer who sends 1,500,000 requests:

• Graduated tiers price each slice at its own rate: 100 × $1.00 + 900 × $0.60 + 500 × $0.30 = $790.
• Volume tiers price every request at the rate of the tier the total lands in: 1,500 × $0.30 = $450.

Volume tiers have a cliff. A customer at 950,000 requests pays $570, but at 1,000,001 they'd pay $300, so sending 50,001 junk requests saves them $270. Stripe's documentation points out the same effect: under volume pricing, the total can go down as usage goes up. With graduated tiers the same customer pays $610 at 950,000 and $640 at 1,000,001, and every extra request adds to the bill.

Use graduated tiers on self-serve plans. Volume pricing is safer when the tier is set by a volume the customer commits to in advance, not by whatever they happen to send.

Package pricing

Package pricing sells usage in blocks and rounds up. At $10 per package of 10,000 requests, 23,500 requests bill as three packages, or $30. Resend bills email overage this way, in blocks of 1,000. In Stripe it's a price with transform_quantity (divide usage by 10,000, round up), which can't be combined with tiers.

Prepaid credits

The customer buys a balance, say $50 for 100,000 credits, and each call draws it down, with expensive operations costing more credits. Settle four rules before you sell the first pack:

1. What happens at zero. Either requests fail until the customer tops up, or you charge a saved card when the balance drops below a threshold. Anthropic does both: its API stops working at zero, and customers can turn on auto-reload.
2. When credits expire. Anthropic's purchased API credits expire a year after purchase, and the date can't be extended. Whatever you choose, show it at checkout.
3. Which credits get used first. Stripe's credit grants apply by the priority you set, then by earliest expiry, then promotional before paid.
4. Whether unused credits can be refunded. Anthropic's credit purchases are non-refundable. If you do refund, limit it to paid credits.

Hybrid: base fee, included usage and overage

A monthly fee buys an included amount, and usage above it is billed per unit. With $49 including 250,000 requests and $0.40 per 1,000 over, a customer who sends 410,000 requests pays $49 + 160 × $0.40 = $113.

Size the included amount so a typical customer stays inside it and gets a flat bill. Then decide what the overage price is for. $49 for 250,000 works out to $0.196 per 1,000, so a $0.40 overage pushes heavy users toward the next plan, while about $0.20 just bills them. Resend does both: its $20 Pro plan ($0.40 per 1,000 included) charges $0.90 per 1,000 over, while its Scale plans charge overage at roughly the plan's own rate. The API monetization guide has a calculator for this model.

Minimums and commitments

A minimum is a floor, not a fee. With a $100 monthly minimum, a customer who uses $60 worth pays $100, and one who uses $140 worth pays $140. A base fee works differently: it's always charged, and usage above the included amount is added on top.

A commitment is a minimum over a longer term, usually traded for a discount. A customer agrees to spend $12,000 over a year at 20% below list prices, usage draws the commitment down, and any shortfall is invoiced at the end of the term. Twilio offers this on SMS: customers who commit to annual message volumes get a discount beyond its standard volume tiers.

Offer commitments when customers ask for them, usually larger companies with a procurement process; for self-serve developers they're just friction. Stripe's basic usage-based billing doesn't support commits or minimums, and its docs send you to Metronome for those.

Usage-based pricing examples from real APIs

Six public APIs from different categories, with prices from their official pricing pages and docs (checked October 2026):

Anthropic: separate prices for input and output

On Claude Sonnet 5.5, output tokens cost five times as much as input tokens, and reading a cached prompt costs $0.10 per million tokens instead of $2. Separate prices give customers a way to lower their own bill, for example by caching a long system prompt. Usage is paid from prepaid credits, and failed requests aren't charged.

Twilio: billed per SMS segment

Twilio's US rate is $0.0083 per SMS segment. One segment holds 160 standard GSM-7 characters; a longer text is split into segments of 153, so a 300-character message costs two. Texts with characters outside GSM-7, such as emoji, fit 70 characters, or 67 per segment once split. Carrier fees are passed through on top, such as $0.0035 per outbound SMS on AT&T and $0.0045 on T-Mobile, and even a message that ends in a "Failed" status costs a $0.001 processing fee. Listing pass-through costs separately keeps the headline rate stable.

Resend: pick a monthly volume

Resend sells email volume as monthly plans, and on its Scale plans the price per 1,000 falls from $0.90 at 100,000 emails to $0.46 at 2,500,000. Overage is opt-in: with pay-as-you-go turned on, extra emails are billed in blocks of 1,000 at the plan's overage rate, and without it Resend notifies you and offers a bigger plan. The free plan also caps sending at 100 emails a day.

Google Maps Platform: free cap, then graduated tiers

The first 10,000 geocoding requests each month are free. After that the price per 1,000 drops as volume grows: $5.00 up to 100,000 requests, $4.00 up to 500,000, $3.00 up to 1 million, $1.50 up to 5 million and $0.38 beyond. Google bills the usage in each range at that range's price, so 250,000 requests in a month cost $450 for the paid requests up to 100,000 plus $600 for the next 150,000, or $1,050. The free usage resets on the first of each month.

ScrapingBee: credits weighted by effort

A ScrapingBee plan is a monthly credit allowance, such as $49 for 250,000 credits on Freelance. A request costs 1 credit without JavaScript rendering, 5 with it (the default), 10 or 25 with premium proxies (without or with JavaScript) and 75 with stealth proxies. The same 250,000 credits buy 250,000 plain fetches or 3,333 stealth ones. Its docs list which responses are billed: successful calls and 404s are, while 500s, 429s and out-of-credit errors aren't.

Replicate: paying for compute seconds

Replicate prices by the second, at a rate set by the hardware: a small CPU costs $0.000025 a second, an Nvidia A100 (80GB) 56 times that. On public models you pay only while your request is being processed. Private models run on dedicated hardware, so you also pay for the time they spend setting up and sitting idle. Who pays for idle capacity is part of the price.

How to pick a model for your API

Start from your costs and your buyers, then match the mechanics:

• If every request costs you about the same, use per-unit pricing with a free allowance, or a base fee with included usage for predictable revenue.
• If some operations cost far more than others, price them separately or use weighted credits.
• If customers worry about runaway bills, sell prepaid credits or let them choose between a hard stop and overage.
• If a few customers are much bigger than the rest, add graduated tiers, not volume tiers.
• If a customer wants a volume discount they can't prove yet, offer a commitment instead of a lower list price.

Showing usage so the bill isn't a surprise

A correct bill can still be hard to explain when it's twice what the customer expected. Usage-based pricing works when customers can watch the meter, which takes:

• a usage page with this period's count, the included amount or credits left, and the bill so far,
• a projection of the next invoice at the current pace,
• alerts at thresholds the customer picks, such as 80% of the included amount, by email and webhook,
• a hard stop or spending cap the customer controls, like Resend's opt-in overage,
• usage in the API itself, through an endpoint or response headers, so code can react before anyone reads an email,
• an invoice line that matches the usage page exactly.

A developer portal is the usual home for the usage page. Feed it from your own count rather than Stripe's: Stripe processes meter events asynchronously, so its usage summaries and upcoming invoices can lag behind what you've sent.

Usage-based pricing software: what it does and when you need it

Usage-based pricing software turns usage into invoices. Metering takes in usage events, drops duplicates and totals them per customer and period. Rating applies your price model to those totals. Invoicing bills the customer, collects payment and retries failed cards.

Stripe alone covers more of this than many teams expect. Its basic usage-based billing takes usage through Billing Meters and handles per-unit pricing, graduated and volume tiers, packages, a flat fee plus overage, and credit grants applied at invoice time. Checkout and usage alerts work with it too. The meter event endpoint accepts 1,000 calls a second per account in live mode, so a busy API should send totals rather than one event per request.

You'll want more than that if you sell:

• prepaid balances that must stop at zero in real time,
• commitments, minimums, true-ups or ramp schedules,
• prices that vary by an attribute on one meter, such as model or region,
• live usage that customers can see mid-period,
• event volumes too high to pre-aggregate.

Stripe's own answer is Metronome, a usage billing product it now owns and recommends for new integrations: Metronome meters, rates and invoices, and Stripe collects the payment. Stripe's comparison lists Metronome's Checkout support as limited, with no support for Connect, Workflows or the Stripe Dashboard. Other dedicated tools are compared in our usage-based billing software roundup.

Our view: for per-unit, tiered or base-fee-plus-overage plans, Stripe's basic usage-based billing is enough, unless you need real-time balances, commitments or the other features above.

Whichever model you choose, an invoice total won't stop the next API request: keys, rate limits and quota checks have to run before you serve it. That's the part UsageRail handles. Its SDK runs those checks inside your API process and puts each period's usage on the customer's invoice in your own Stripe account.