Pricing AI Features: A Unit Economics Model for Product Managers

Classic SaaS has near-zero marginal cost. Once the code ships, the thousandth user costs you almost nothing more than the first. AI features break that assumption: every request burns tokens, and a small group of heavy users can consume more than everyone else combined. PMs who price an AI feature like a normal toggle often find out two quarters later that their best customers are their least profitable.

This post gives you a model you can build in a spreadsheet this week: cost per task, a usage distribution, and a pricing structure that fits it.

The problem: cost scales with behaviour, not seats

A seat-based price assumes cost is roughly flat per seat. For AI features it isn't, for three reasons:

1. Cost is per task, and tasks vary wildly. A one-line summary and a 40-page document analysis may differ in cost by 50x.
2. Agents multiply calls. One user request can trigger many model calls (planning, tool use, retries). Cost per task is a distribution, not a number.
3. Usage is heavily skewed. In most products a small percentage of users generate a large share of volume. Your average-cost figure hides this.

Provider prices change often, so always pull current per-token rates from your provider's pricing page. The model below uses placeholders you replace.

Step 1: Compute cost per task

Break one task into its model calls and sum them. Include everything: retrieval embeddings, reranking, the main generation, a judge or guardrail call, and expected retries.

from dataclasses import dataclass

@dataclass
class Call:
    name: str
    input_tokens: int
    output_tokens: int
    in_price_per_m: float   # USD per 1M input tokens - check provider docs
    out_price_per_m: float  # USD per 1M output tokens
    cached_fraction: float = 0.0   # share of input served from prompt cache
    cache_discount: float = 0.9    # discount on cached input; varies by provider

    def cost(self) -> float:
        cached = self.input_tokens * self.cached_fraction
        fresh = self.input_tokens - cached
        in_cost = (fresh + cached * (1 - self.cache_discount)) * self.in_price_per_m / 1e6
        out_cost = self.output_tokens * self.out_price_per_m / 1e6
        return in_cost + out_cost

def task_cost(calls: list[Call], retry_rate: float = 0.05) -> float:
    base = sum(c.cost() for c in calls)
    return base * (1 + retry_rate)

# Placeholder prices - replace with your provider's current rates
task = [
    Call("rewrite_query", 800, 60, 1.0, 4.0),
    Call("main_answer", 6000, 500, 3.0, 15.0, cached_fraction=0.5),
    Call("groundedness_judge", 2000, 100, 0.5, 2.0),
]
print(f"cost per task: ${task_cost(task):.4f}")

Measure token counts from real traces rather than guessing. If you have tracing in place, sample a few hundred production tasks and compute the p50, p90 and p99 cost, not just the mean.

Step 2: Model the usage distribution

Now combine cost per task with how often users trigger it. Segment users into tiers based on tasks per month.

import numpy as np

rng = np.random.default_rng(42)

# Heavy-tailed usage: most users light, a few very heavy (lognormal is a common fit)
users = 1000
tasks_per_user = rng.lognormal(mean=2.5, sigma=1.1, size=users).astype(int) + 1

cost_per_task = 0.035   # from Step 1 (p50); use p90 for a conservative case
monthly_cost = tasks_per_user * cost_per_task

price = 20.0  # flat monthly price per user
margin = price - monthly_cost

print(f"mean cost/user:  ${monthly_cost.mean():.2f}")
print(f"p95 cost/user:   ${np.percentile(monthly_cost, 95):.2f}")
print(f"top 5% share of total cost: "
      f"{np.sort(monthly_cost)[-users//20:].sum() / monthly_cost.sum():.0%}")
print(f"users with negative margin: {(margin < 0).mean():.1%}")

The numbers here are synthetic, but the shape is the lesson: look at the top-5% cost share and the share of users with negative margin. Replace the lognormal assumption with your actual usage logs as soon as you have them.

Step 3: Choose a pricing structure

Structure	How it works	Best when	Risk
Flat seat price	One price, unlimited use	Cost per task is tiny and usage is bounded	Heavy users erode margin
Seat + fair-use cap	Flat price with a soft limit	Usage is skewed but most users are light	Cap feels arbitrary; support load
Credits / metered	Pay per task or token bundle	Cost varies a lot per task	Buyers dislike unpredictable bills
Hybrid (base + overage)	Included allowance, then metered	Mixed customer base, enterprise deals	More billing complexity
Outcome-based	Pay per resolved ticket, qualified lead, etc.	Value is clear and measurable	Needs reliable outcome attribution

A practical default for many B2B products is the hybrid: a base price that includes an allowance covering your median user comfortably, with overage or an upgrade path for the tail.

Step 4: Add cost levers before you add price

Before raising prices, check whether you can lower the cost per task. Typical levers, each worth its own analysis:

• Prompt caching for long, repeated prefixes.
• Model routing: send easy requests to a cheaper model.
• Batch APIs for work that isn't latency-sensitive.
• Semantic caching for repeated questions.
• Context discipline: don't send 30k tokens when 6k will do.

Each lever trades cost against quality or latency, so re-run your evals after every change. A cost cut that drops task success by a few points can cost more in churn than it saves.

Step 5: Set guardrails on the downside

• Per-user and per-tenant budgets with alerts at 50%, 80% and 100%.
• Hard limits on agent loops (max steps, max tokens per task) so one runaway task can't cost a month of revenue.
• Cost attribution by feature and customer so finance and product see the same numbers.
• A margin dashboard: cost per task, tasks per user, gross margin per tier, reviewed weekly at launch.

Pitfalls to avoid

• Pricing off the mean. The mean cost per user hides the tail. Always look at p95 and the top-decile share.
• Forgetting the non-generation costs. Embeddings, vector storage, reranking, judges, observability and human review all count.
• Using launch-day prices as a constant. Model prices and your model mix change. Rebuild the model quarterly.
• Ignoring retries and failures. Failed or repeated tasks cost money and rarely show up in napkin math.
• Free tiers with no cap. A generous free tier on a metered cost is a customer acquisition cost with no ceiling.
• Measuring cost but not value. If you can't tie a task to an outcome the customer cares about, you can't defend the price in a negotiation.
• Hard-coding price into the architecture. Keep metering and pricing rules configurable so you can change plans without a deploy.

A checklist before you ship pricing

• Cost per task measured from real traces (p50, p90, p99)
• Usage distribution modelled, with top-5% cost share known
• Gross margin calculated per tier, including the heavy tail
• Budgets, caps and agent loop limits in place
• Metering and attribution wired to billing
• Plan to revisit pricing after 30, 60 and 90 days of real data

Next steps

This week, pull 200 real traces for your AI feature, compute the cost-per-task distribution, and run the simulation above with your actual usage logs. If the top 5% of users account for more than a third of your cost, you have a pricing-structure decision to make before you scale.

If you're a PM who wants to practise this kind of thinking on real AI product problems, scoping, evaluating and pricing AI-native features alongside other PMs, take a look at Joinloop's PM cohort.