Pricing AI features

Why this matters #

Pricing decides whether an AI feature is a growth engine or a cost center. Price it like traditional software, with unlimited use for a flat fee, and your heaviest users can erase your margin. Price it purely by usage, and many customers hesitate to try it, because they can’t predict the bill.

There’s no single right answer, but there is a right way to decide: start from your unit economics, match the pricing model to how customers get value, and design limits people understand. This article covers the common pricing models, how to set a floor from cost, a credit calculator, fair limits, and how to test prices before committing.

Pricing models #

Many products combine them: a plan that includes a generous allowance (bundled), with higher tiers or paid top-ups (tiered or credits) for heavy use.

Matching price to value and cost #

Two numbers bound the price:

• The floor is cost. Cost per successful task, plus other costs to serve, plus the margin your business needs. Below that, every use loses money.
• The ceiling is value. What a success is worth to the customer: time saved, revenue enabled, cost avoided. Above that, customers won’t pay or won’t stay.

Price somewhere between, usually far closer to value than to cost when the value is clear. If the floor is above the ceiling, pricing can’t fix the feature: you need to make it cheaper to run or more valuable to use first.

For credit-based pricing, the floor can be computed per action. This calculator converts measured cost per action into credits, given the price of a credit and a target gross margin:

interface Action {
  name: string;
  /** Measured average model cost per successful action, including retries, from traces. */
  costPerSuccessUsd: number;
}

const PRICE_PER_CREDIT_USD = 0.01;
const TARGET_GROSS_MARGIN = 0.75; // Keep 75% of revenue after model cost.

/** Credits to charge per action so the target margin holds, rounded up to a whole credit. */
export function creditsFor(action: Action): number {
  const minimumRevenue = action.costPerSuccessUsd / (1 - TARGET_GROSS_MARGIN);
  return Math.max(1, Math.ceil(minimumRevenue / PRICE_PER_CREDIT_USD));
}

const actions: Action[] = [
  { name: 'Draft a reply', costPerSuccessUsd: 0.025 },
  { name: 'Summarize a thread', costPerSuccessUsd: 0.012 },
  { name: 'Analyze a long document', costPerSuccessUsd: 0.18 },
];

for (const a of actions) console.log(`${a.name.padEnd(24)} ${creditsFor(a)} credits`);

// Check a plan: 2,000 included credits. What does each usage segment actually use?
const INCLUDED_CREDITS = 2_000;
const usage = { light: 150, regular: 1_400, heavy: 6_500 }; // credits per month, from analytics
for (const [segment, credits] of Object.entries(usage)) {
  const over = Math.max(0, credits - INCLUDED_CREDITS);
  console.log(`${segment.padEnd(8)} uses ${credits} credits: ${over === 0 ? 'within plan' : `${over} over, top-up of $${(over * PRICE_PER_CREDIT_USD).toFixed(2)}`}`);
}

The output does two things. It sets credit costs per action that protect your margin, and it shows whether the included allowance covers most users while heavy users pay for what they use. If regular users regularly go over, the allowance is too small; if nobody ever does, you may be underpricing heavy use.

Limits users understand #

Every AI plan has limits, stated or not. Stated, fair limits build trust; surprises destroy it.

• Show usage where it matters. A small “1,240 of 2,000 credits used this month” in the feature, not only on a billing page.
• Warn before the limit, at 80% and 100%, with what happens next.
• Prefer soft limits. Slow down, offer a top-up, or move to a lighter model before stopping entirely, especially mid-task.
• Explain fair use concretely. “Unlimited within fair use (typically up to 500 drafts a month)” is honest; “unlimited” followed by a surprise block isn’t.
• Never charge for failures. If a request errors, is cut off or declines, don’t deduct credits. It’s fair, and customers notice.

Testing prices #

Pricing is hard to change once customers rely on it, so test before committing:

• Talk to customers about how they’d budget for the feature, and what they compare it with, using the interview techniques from Stage 2.
• Test willingness to pay with a pricing page variant or a waitlist for a paid tier, measuring sign-ups rather than asking hypothetically.
• Start with a beta price clearly marked as introductory, so you can adjust.
• Watch the economics after launch: margin per segment, top-up rates, and how often people hit limits.

Common mistakes #

Try it #

Check your understanding #

Key takeaways #