How Should You Price an AI Feature?

How Should You Price an AI Feature?

Pick the unit your costs actually follow, then decide how much of the variability the customer should see. AI features have real marginal cost, so pure per-seat pricing quietly turns your heaviest users into your least profitable ones. The three live models are seats, credits and outcomes, and each fits a different product.

We work with B2B teams shipping AI into existing products, and pricing is where most of them stall. The feature works, the demo lands, and then nobody can agree whether it is included, an add-on or metered.

This is the framework we use, grounded in what shipped products actually charge today.

Why Can You Not Just Add It to the Existing Plan?

Because your unit economics change underneath you. Traditional software has near-zero marginal cost per additional use, so seats work: one more login costs you nothing. An AI feature costs you money every time it runs, and heavy users can cost multiples of light ones on the same plan.

Bundling it in anyway is a legitimate strategic choice if the feature is a retention play and you can absorb the cost. It stops being legitimate when nobody has modelled what happens if usage triples, which is the normal outcome of a feature people like.

So the first question is not what to charge. It is what a heavy user costs you, and whether you could survive every customer becoming one.

What Are the Three Models in Practice?

Seats with included allowances, credits that meter the expensive parts, and outcome pricing that charges per completed job. All three are shipping today at real companies with public prices.

Model	What the customer buys	Fits when
Seat plus allowance	A monthly credit balance per user	Usage correlates with headcount
Pure credits	A balance consumed by actions	Usage varies wildly between accounts
Per outcome	A completed job, not an attempt	The outcome is countable and clearly valuable

The distinction that matters most is between charging for effort and charging for result. Credits charge for effort, including effort that failed. Outcomes charge only when something worked, which is harder to build and much easier to sell.

What Does Seat Plus Allowance Look Like?

GitHub Copilot is the clearest public example. Its plans list a free tier at $0 with 2,000 completions per month and limited chat and agent usage, Pro at $10 per user per month including $15 in monthly credits, Pro+ at $39 per user per month with $70 in credits, and Max at $100 per user per month with $200 in credits.

The design detail worth copying is what does not consume credits. GitHub's documentation states that on paid plans, code completions and next edit suggestions do not use credits and remain unlimited, while premium features such as chat, agents, code review and CLI usage draw from the monthly allowance.

That split is the whole trick. The cheap, high-frequency action stays unlimited so the product still feels generous, and only the expensive, lower-frequency actions are metered. Customers never feel a meter running on the thing they do every minute.

What Does Outcome Pricing Look Like?

Fin AI publishes one of the cleanest examples. Its pricing is $0.99 per outcome with a minimum of 50 outcomes per month for non-Intercom helpdesks, and it defines precisely what counts.

A resolution is when no further help is requested after Fin's last answer. A procedure handoff is when it completes a configured procedure that hands off to a human. Disqualification is when it decides a prospect does not match the criteria. Qualification, when it matches a prospect to the criteria, is priced higher at $9.99. For Intercom customers the model combines helpdesk seats at $29 per month with the same per-outcome fee.

Notice how much definitional work sits behind those four words. Outcome pricing only functions if both sides agree what an outcome is, in writing, before the first invoice.

How Do You Choose Between Them?

Ask what your customer would count if they were building the business case themselves. If a buyer justifies the purchase by headcount, sell seats. If they justify it by volume of work, sell credits. If they justify it by work no longer done by a person, sell outcomes.

Then check whether you can measure that unit reliably. A model you cannot instrument accurately produces billing disputes, and billing disputes with your best customers cost more than the pricing upside.

The third test is your own cost curve. If your cost per action varies by ten times depending on the input, a flat per-action price is a bet, and you need either a wide margin or a cap.

Should It Be an Add-On or Included?

Add-on first, included later. An add-on gives you real demand data, lets you change the price without renegotiating every contract, and makes the value legible because someone had to choose to buy it.

Folding it into the base plan is the right move once adoption is high enough that the feature is part of why people stay. At that point metering it is friction working against your own retention, and the cost belongs in the plan price.

The sequence matters because it is much easier to fold an add-on in than to pull a feature out of a plan and start charging for it. Our piece on raising prices with existing customers covers why the second move is so expensive.

How Do You Stop Customers Fearing the Bill?

Make the meter visible and make overruns impossible by accident. Uncapped consumption pricing is the single biggest objection buyers raise, and it is usually raised by finance rather than by the user who wants the feature.

Three things defuse it: a clear dashboard showing usage against allowance, alerts before the limit rather than after, and a hard cap the customer controls. Being able to say "you cannot accidentally spend more than this" closes deals that a lower price would not.

Pair that with predictable annual pricing for the base and metering only the variable part. Buyers will accept variability on a line they understand and reject it on a line they do not.

What Should the Pricing Page Say?

The unit, the price, what counts, and what happens when you run out. Vague AI pricing is now a competitive disadvantage, because buyers compare these models directly and an unclear page reads as something to be negotiated rather than bought.

Define your unit in one sentence a non-technical buyer can repeat. Fin's definitions are worth studying for this: each one is a single sentence describing an observable event, not a description of the technology.

Show the arithmetic with a realistic example. Our piece on pricing page design covers how to lay this out without the page turning into a tariff document.

What Would We Do on a First Release?

Ship it as a paid add-on with a generous allowance, meter only the expensive actions, cap the downside, and publish the definitions. Then watch for three months and look at the distribution rather than the average, because the average customer does not exist and the heavy tail is what determines your margin.

Revisit once you can see the shape. Most teams find the model was roughly right and the price was too low, which is a far better problem than the reverse. Our piece on pricing and packaging tiers covers how to restructure once you know.

If you want help pressure-testing an AI pricing model, or the page that has to explain it, we are happy to walk through it. You can reach our team at phoenix.studio.