By Mehdi HassanWhat makes an AI pricing page different?
An AI pricing page is different because the unit of cost is something the buyer has never counted: tokens, credits, GPU time or resolutions. A seat price is easy to judge. "10,000 credits per month" is not, until the page says what 10,000 credits gets done. The design job is translation, not decoration.
This article looks at how well-known AI products present usage pricing, what each pattern does well, and how to apply it to your own page. For the wider context on how pricing fits the rest of an AI site, see our hub on AI startup website design, and for general pricing-page structure, our SaaS pricing page guide.
How do well-known AI products show usage-based pricing?
Well-known AI products use five main patterns: per-token tables, credit allowances, compute-time plans, per-second hardware billing and per-outcome pricing. Each fits a different buyer. The table summarises who uses which pattern and why it works for them. Prices and plan structures change often, so we describe the pattern, not the numbers; check each product's current pricing page before you copy it.
Product | Pricing unit | What the page does well | Best for |
|---|---|---|---|
OpenAI API | Price per million input and output tokens, per model | One clean table per model, input and output priced separately | Developers comparing models |
Anthropic API | Price per million tokens, per model | Side-by-side model rows make cost versus capability easy to scan | Developers choosing a model tier |
ElevenLabs | Monthly credit allowance tied to characters of text | Plans state an allowance in a unit creators can picture | Creators and small teams |
Midjourney | Plans by GPU time (fast hours) | Ties price to speed, a trade-off users already feel | Individual creative users |
Replicate | Per-second billing by hardware type | Lists hardware tiers so cost follows the model you run | Developers running open models |
GitHub Copilot | Per-seat plans with an allowance of premium requests | Seats first, usage second, which fits company budgeting | Engineering teams |
Intercom Fin | Price per resolved conversation | Charges for the outcome the buyer cares about | Support leaders |
Notice the split. Products sold to developers publish raw unit prices because developers can do the math. Products sold to business teams wrap usage in seats, allowances or outcomes, because the person signing the budget wants a monthly number.
What can you learn from per-token pricing tables?
Per-token tables teach clarity of structure: one row per model, input and output prices in separate columns, the same unit everywhere. They work because the audience already knows what a token is and how many their app uses.
They fail when copied onto a product for non-developers. A marketing lead can't estimate tokens per blog post. If your product is built on a model API but sold to business users, don't pass the token price through to the page. Price in their unit and absorb the token math yourself. Our guide to devtools pricing pages covers when raw usage pricing is the right call.
How should an AI pricing page explain credits?
An AI pricing page should explain credits by converting them into real tasks next to every plan. On its own, "5,000 credits" means nothing. Add the conversion, such as "5,000 credits, about 250 contract reviews" (an illustrative figure), and the buyer can judge it. Put the conversion in the plan card, not in a help article.
- State the exchange rate. Say what one credit buys for each action, in a small table under the plans.
- Give a typical-use line per plan. A line such as "Fits a team reviewing about 50 contracts a week" (use your own measured figure) helps buyers self-select.
- Say what happens at zero. Hard stop, overage at a published rate, or a prompt to upgrade.
- Say whether credits roll over. Buyers will ask, and a hidden answer looks like a hidden fee.
- Show different actions cost different amounts. If a long video costs more than a short one, say so with an example.
Hypothetical example: rewriting a credits plan card
For example, suppose an AI tool for legal teams sells a plan as "Pro: 20,000 credits, $400/month".
A clearer card reads: "Pro, $400/month. 20,000 credits, about 400 contract reviews. One review of a 20-page contract uses about 50 credits; a clause search uses 2. Unused credits roll over for one month. If you run out, extra credits are billed at the published rate, and we email you at 80%."
Nothing about the price changed. The buyer can now judge it against their own workload, and the questions sales used to answer by email are on the page.
Should an AI pricing page include a calculator?
An AI pricing page should include a calculator when usage varies a lot between customers and the buyer can estimate their own volume. A slider for documents, minutes or conversations per month, with the plan and total updating live, answers the main question faster than any table.
Pros
- Turns an abstract unit into a monthly number the buyer can take to finance
- Lets buyers self-select a plan without a sales call
- Gives sales a shared reference when quoting larger deals
Cons
- A calculator with the wrong inputs gives confidently wrong answers
- It must be updated every time unit prices or model costs change
- Built in a page builder, it can be slow or hard to keep accurate; it often needs custom code
Base the calculator on the task, not the unit. Ask "How many calls do you transcribe a month?" and convert behind the scenes. If you can't map a task to a predictable cost, show a range and say why, rather than a single number you can't stand behind.
How should seats and usage appear on the same AI pricing page?
Show seats first and usage second when you sell to teams. Lead each plan with a per-seat price and an included usage allowance, then show overage pricing below. That gives the budget holder a predictable number and keeps usage honest for heavy users.
Model | Clear to buyers? | Predictable spend? | Use it when |
|---|---|---|---|
Pure per-token or per-second | Only to developers | No | You sell an API |
Credits allowance | Yes, with task conversions | Mostly | Actions vary in cost |
Seats plus allowance | Yes | Yes | You sell to teams with a budget owner |
Per outcome | Very clear | Depends on volume | The outcome is countable and agreed |
Flat plans, fair use | Very clear | Yes | Usage costs are low or averaged out |
Usage pricing has a fuller treatment in our guide to pricing pages for usage-based and AI products, and our pricing page examples teardown shows the same structures on non-AI products.
What are the most common AI pricing page mistakes?
The most common mistakes are unexplained units, hidden limits and pricing that's out of date. All three make a careful buyer assume the worst about the bill.
- Units with no translation. Credits or tokens with no task equivalent.
- Limits in the terms only. Rate limits, caps and overage rates belong on the page.
- Model names that went stale. If the plan says it includes a model you retired, buyers stop trusting the rest.
- "Contact sales" for every plan. Fine for enterprise, but publish at least one self-serve price so buyers can anchor.
- No data terms near pricing. Business buyers want to know if their data trains the model on the plan they're choosing. Link the AI trust page from the plan table.
Keep model names, unit prices and allowances as CMS fields, not hard-coded text. AI pricing changes faster than any other page on your site, and the cost of a stale number is a support ticket, or a lost deal. For what the rest of the build costs, see AI startup website cost.
