Pricing AI Features: A Founder's Guide to Per-Seat vs Usage-Based Models

You're about to put a price on your AI feature, and both options feel like a trap. Charge per seat and a single power user running the feature all day can wipe out the margin on their whole team. Charge per use and your pricing page reads like a phone bill — nobody can predict what they'll pay, so nobody buys.

This is the part of shipping AI that founders consistently underthink. Traditional SaaS pricing assumes your cost of goods is basically flat: one more login costs you fractions of a cent. AI flips that. Every interaction has a real, variable token cost that scales with usage — so the choice between AI feature pricing models, per-seat vs usage-based, is really a choice about who absorbs the variance. Get it wrong and you either cap your own growth or quietly sell dollars for ninety cents.

Here's how to reason about it with actual numbers instead of vibes.

Why AI pricing isn't just SaaS pricing

In classic SaaS, price and cost are decoupled. You charge $20/seat, your marginal cost per seat is maybe $0.50, and gross margin sits at 80-90% no matter how heavily someone uses the product. Usage barely moves your costs, so you're free to price on value.

AI breaks that decoupling. Your cost of goods sold (COGS) now scales with how much people use the thing. A chatty user costs you 50x what a light user does. So the pricing question becomes: how do you keep gross margin healthy when your costs are a moving target?

Three numbers drive every decision here:

• Cost per action — what one unit of AI work costs you in tokens (and any infra around it).
• Actions per user per month — and, critically, the distribution, not just the average.
• Price — per seat, per action, or some hybrid.

If you haven't nailed down cost per action yet, stop and read The Real Cost of Running an AI Feature in Production first. Everything below assumes you know what one interaction costs you.

The two models, honestly

Per-seat: predictable for the buyer, risky for you

Per-seat means a flat monthly price per user. Buyers love it because it's predictable and it maps to how they already budget for software. Procurement understands it. It bundles cleanly into existing plans.

The risk is all yours: usage variance. Price a $30/seat plan around the average user and your top 5% of users — the ones who actually love the feature — can each cost you more than they pay. You've built a plan that's most expensive to serve precisely for the people getting the most value.

Per-seat works when:

• Usage is naturally bounded by the workflow (the feature runs once per task, and there are only so many tasks in a day).
• Variance between users is low — most people use it a similar amount.
• The feature is sticky and embedded, so the seat is worth paying for regardless of usage.

Usage-based: aligns cost and revenue, scares buyers

Usage-based means you charge per unit of work — per message, per generation, per 1,000 tokens, per "credit." It aligns your revenue with your costs almost perfectly: heavy users pay more, so they can't blow up your margin.

The downside is buyer psychology. Unpredictable bills kill conversion. Engineers and founders building on your API might tolerate it, but a marketing manager evaluating your tool does not want to explain a variable line item to their boss every month. Usage-based pricing also punishes engagement — the exact behavior you want to encourage now makes users nervous about cost.

Usage-based works when:

• Usage variance is huge (some users do 10x what others do).
• Your buyer is technical or already thinks in consumption (infra, dev tools, API products).
• The value of each action is high enough that the per-unit price feels fair.

The hybrid that most products land on

In practice, the answer for most SaaS AI features is neither pure model — it's a base + included allowance + overage. You charge a per-seat (or per-plan) price that includes a generous bucket of AI actions, then meter overage above that. Notion AI, GitHub Copilot's usage tiers, and most "AI credits" systems are variants of this.

This gives buyers the predictability of a seat price for normal use, while protecting your margin against the power user who'd otherwise eat you alive. The included allowance is sized so that ~90-95% of users never hit it, and the 5% who do are the ones getting enough value to happily pay more.

The math: three real products

Let's run the numbers. I'll use round, current-ish model prices — assume a blended cost of $5 per million input tokens and $15 per million output tokens (roughly a mid-tier frontier model in mid-2026). Your real numbers will differ; that's what the calculator at the end is for.

Product 1: AI writing assistant (per-seat)

A writing tool where the AI drafts and edits. Say an average action is 2K input + 1K output tokens.

• Cost per action: (2000 × $5 + 1000 × $15) / 1,000,000 = $0.025
• Average user: 200 actions/month → $5.00 COGS
• Price: $20/seat/month
• Gross margin: (20 − 5) / 20 = 75% ✅

Healthy. But look at the power user doing 1,000 actions/month: $25 COGS against $20 revenue → −25% margin. If even 8% of your users are power users, your blended margin craters. This is why per-seat needs either bounded usage or an overage valve.

Product 2: AI sales assistant (usage-based)

A tool that researches leads and drafts outreach. Each action is heavier: 8K input (CRM context) + 2K output.

• Cost per action: (8000 × $5 + 2000 × $15) / 1,000,000 = $0.07
• Price: $0.50/action (or sold as credits)
• Gross margin per action: (0.50 − 0.07) / 0.50 = 86% ✅

Usage-based shines here because variance is enormous — one rep researches 50 leads a week, another does 500. Per-seat would force you to price for the heavy rep and overcharge everyone else. Per-action, everyone pays for what they use and your margin is constant regardless of who's heavy.

Product 3: AI code reviewer (hybrid)

Reviews pull requests. A review is expensive — large diffs mean 20K input + 4K output.

• Cost per action: (20000 × $5 + 4000 × $15) / 1,000,000 = $0.16
• Plan: $40/seat/month, includes 150 reviews, then $0.30/review overage
• Average user (100 reviews): COGS = 100 × $0.16 = $16 → margin (40 − 16) / 40 = 60% ✅
• Power user (400 reviews): revenue = $40 + (250 × $0.30) = $115; COGS = 400 × $0.16 = $64 → margin 44% ✅

The overage keeps the power user profitable instead of underwater. Notice this only works because cost per review is well under the overage price — if your COGS ever exceeds your overage rate, you're selling losses at the margin. That's the one inviolable rule: overage price must comfortably exceed cost per action.

A margin calculator you can adapt

Drop this into a Node script and plug in your own token counts and prices. It models per-seat, usage-based, and hybrid in one pass, and — most importantly — it stresses the margin against a power user, not just the average.

// scripts/ai-margin.ts
interface PricingInput {
    inputTokens: number // per action
    outputTokens: number // per action
    inputPricePerM: number // $ per 1M input tokens
    outputPricePerM: number // $ per 1M output tokens
    avgActions: number // average user, per month
    powerActions: number // power user (e.g. p95), per month
}

interface PlanResult {
    costPerAction: number
    avgMargin: number
    powerMargin: number
}

function costPerAction(p: PricingInput): number {
    return (
        (p.inputTokens * p.inputPricePerM +
            p.outputTokens * p.outputPricePerM) /
        1_000_000
    )
}

function margin(revenue: number, cogs: number): number {
    if (revenue <= 0) return 0
    return (revenue - cogs) / revenue
}

export function perSeat(p: PricingInput, seatPrice: number): PlanResult {
    const cpa = costPerAction(p)
    return {
        costPerAction: cpa,
        avgMargin: margin(seatPrice, cpa * p.avgActions),
        powerMargin: margin(seatPrice, cpa * p.powerActions),
    }
}

export function usageBased(p: PricingInput, pricePerAction: number): PlanResult {
    const cpa = costPerAction(p)
    // Margin is constant per action, so avg === power.
    const m = margin(pricePerAction, cpa)
    return { costPerAction: cpa, avgMargin: m, powerMargin: m }
}

export function hybrid(
    p: PricingInput,
    seatPrice: number,
    includedActions: number,
    overagePerAction: number
): PlanResult {
    const cpa = costPerAction(p)
    const revenue = (actions: number) =>
        seatPrice + Math.max(0, actions - includedActions) * overagePerAction
    return {
        costPerAction: cpa,
        avgMargin: margin(revenue(p.avgActions), cpa * p.avgActions),
        powerMargin: margin(revenue(p.powerActions), cpa * p.powerActions),
    }
}

// --- Code reviewer example ---
const codeReviewer: PricingInput = {
    inputTokens: 20_000,
    outputTokens: 4_000,
    inputPricePerM: 5,
    outputPricePerM: 15,
    avgActions: 100,
    powerActions: 400,
}

const pct = (n: number) => `${(n * 100).toFixed(0)}%`

for (const [label, result] of [
    ['per-seat $40', perSeat(codeReviewer, 40)],
    ['usage $0.30/review', usageBased(codeReviewer, 0.3)],
    ['hybrid $40 + 150 incl', hybrid(codeReviewer, 40, 150, 0.3)],
] as const) {
    console.log(
        `${label.padEnd(24)} avg=${pct(result.avgMargin).padStart(5)} ` +
            `power=${pct(result.powerMargin).padStart(5)} ` +
            `cost/action=$${result.costPerAction.toFixed(3)}`
    )
}

Run it with npx tsx scripts/ai-margin.ts. The output makes the power-user trap obvious:

per-seat $40             avg=  60% power= -60% cost/action=$0.160
usage $0.30/review       avg=  47% power=  47% cost/action=$0.160
hybrid $40 + 150 incl    avg=  60% power=  44% cost/action=$0.160

Per-seat looks healthy on the average and is catastrophic on the power user — same $40 plan, margin swings from +60% to −60% depending on who's holding the seat. Usage-based is flat but lower. Hybrid matches per-seat on the average user and stays comfortably positive on the power user. That power=-60% cell is the number founders never compute before launch — and it's the one that decides whether scale makes you money or bankrupts you.

The levers that change the answer

Pricing isn't the only knob. Before you commit to a model, remember that your costs are also negotiable:

• Prompt caching can cut input costs by up to 90% on repeated context (system prompts, RAG chunks, conversation history). That single change can move per-seat from unviable to comfortable. See Cut Your Claude API Bill by 90% Using Prompt Caching.
• Model routing sends simple actions to a cheap model and only escalates hard ones. If 70% of your traffic can run on a small model, your blended cost per action drops hard — details in How to Route LLM Requests to Cheap vs Expensive Models.
• Step caps and allowances bound the worst case so a single user can't run away with your margin.

Lower your cost per action first, then price. Pricing around an unoptimized cost base means you're either overcharging customers or undercutting yourself — both fixable before launch.

What I'd actually do

If you're shipping a SaaS AI feature to non-technical buyers, default to hybrid: a seat price with a generous included allowance and metered overage. It gives buyers the predictability they need to say yes, and gives you the valve you need to stay profitable when usage is lopsided — which it always is.

Go pure usage-based only if your buyer is technical and your usage variance is extreme. Go pure per-seat only if usage is genuinely bounded by the workflow and you've confirmed your p95 user is still profitable (run the calculator — don't guess).

And whatever you pick, size your allowances against the distribution of usage, not the average. The average user is not the one who breaks your pricing.

What's next

Pricing a single-call AI feature is one thing. Pricing an agent — multi-step loops, tool calls, retries, reasoning tokens — is a different beast, because cost per task can be 10-50x higher and far less predictable. That's the upcoming companion piece, The Real Cost of AI Agents: A Founder's Guide to Agent Economics and Margins. In the meantime, if you haven't decided whether to build the feature at all, Should You Build or Buy AI Features for Your SaaS? walks through that call with the same kind of math.