Pricing an AI Feature: Credits, Seats or Usage?

Classic SaaS has a lovely property. Once the software is built, the cost of serving one more user is close to zero, so a flat per-seat price lands you gross margins in the 80s. You can be sloppy about packaging and still make money.

AI features take that away. Every request to a model costs real money, and the cost scales with how much your customers actually use the feature, not with how many seats they bought. A seat-priced customer who runs 40 agent tasks a day costs you many times more than one who runs two. Both pay the same $30.

We see this on scoping calls constantly. A founder ships an AI assistant inside an existing product, prices it as a $15 per seat add-on because that is what the competitor charges, and three months later finance notices that the top 5% of users generate most of the inference bill. Nobody chose that outcome. It just fell out of copying a pricing model built for a different cost structure.

This post gives you a way to choose. We will cover the four models that actually ship (seats, usage, credits, outcomes), what each does to margin and sales friction, what real vendors do, and a decision rule. If you want the cost side first, read our founder's guide to AI agent unit economics and come back.

Do not pick a pricing model until you can answer one question: what does it cost you to deliver one unit of the thing the customer cares about? A drafted email, a summarized call, a resolved support ticket, a generated report. Not tokens. The customer does not think in tokens.

Measure it from production logs, not from a spreadsheet guess. Run the feature for two weeks with a real cohort and record, per task, the model spend, the retrieval and tool-call costs, and any third-party API fees. Then look at the distribution, not the average. AI workloads have a long tail. The median task might cost $0.02 and the 95th percentile $0.60, because some users paste in a 200-page document or trigger a multi-step agent loop that retries.

The three numbers to write down

• Median cost per unit. This sets your floor price per unit.
• 95th percentile cost per unit. This tells you how exposed you are to heavy users.
• Units per active user per month, by decile. This tells you how unequal usage is. If the top decile does 10 times the median, a flat seat price subsidizes them with everyone else's money.

Model prices also fall fast and change with each release, which cuts both ways. You can often drop your cost per unit by routing easy tasks to a smaller model, and our post on prompt caching and smart routing covers how. But do not price on a hoped-for future cost. Price on today's number and keep the savings as margin you can later pass on or keep.

A reasonable target for the AI portion of your product is a gross margin at or above the margin of the rest of the business, though many teams accept something lower in year one while they learn usage patterns. Decide your floor before you pick a model. We usually start the conversation at 60% gross margin on the AI feature in isolation and move from there.

The simplest option is to fold AI into your existing per-seat plan, perhaps nudging up the top tier. Customers understand it, procurement understands it, and there is no meter to explain.

It works when the AI feature has bounded, predictable cost per user. Autocomplete in a text field, a classification step that runs once per record, a small model summarizing short inputs. If the 95th percentile user costs you less than 3 times the median, a seat price absorbs the variance.

It fails when the feature is open-ended: a chat assistant over the customer's whole data set, agents that run multi-step jobs, anything that reads long documents. A single enthusiastic power user can cost more than the whole account pays.

Guardrails if you go this route

Add a fair-use cap in the terms and a soft limit in the product. Something like "includes up to 500 AI actions per seat per month, then slows to a smaller model" protects you without a meter on the invoice. Notion, Microsoft and others have moved in this direction at various points, bundling AI into higher tiers instead of selling it separately, because a separate $10 add-on kills attach rate. Expect your own attach rate on a paid add-on to be low unless the value is obvious on day one.

Our view: seat-bundled is the right default for a feature that makes your core product stickier but is not the reason people buy it. If the AI is the reason people buy, pick one of the next three.

Charge per unit consumed. Per summarized call, per thousand records enriched, per generated image. Your revenue tracks your cost, so your margin is predictable by construction.

This is the honest model and the one engineers like. It is also the hardest to sell to a finance team that wants a predictable bill. Customers hate surprise invoices, and an uncapped meter reads as a blank check.

What makes usage pricing work

• A unit the customer understands. "Per resolved ticket" or "per document processed" works. "Per 1,000 tokens" does not, unless your buyers are developers.
• Real-time visibility. A usage dashboard and spend alerts inside the product, not a PDF at month end.
• Commit tiers. Offer a monthly commitment with a discounted unit rate. It gives you forecastable revenue and gives them a price they can budget.
• A spending cap they can set. Let admins hard-stop at a number.

The tooling matters more than people expect. Metering, rating and invoicing is a real engineering project, which is why vendors like Stripe Billing, Orb, Metronome and Lago exist. We compared them in our usage-based billing breakdown. Budget a few weeks of engineering for a clean metering pipeline, more if you need per-customer rate cards or credits that expire.

Pure usage works best for B2B infrastructure-style products and for any product whose buyers are technical. It works poorly for broad SMB tools where the buyer wants a flat number.

Credits sit between seats and usage. The customer buys a monthly plan that includes a pool of credits. Each AI action burns some credits. When the pool runs out, they buy a top-up or upgrade.

It gives finance a predictable base price and gives you a meter that tracks cost. Credits also let you charge different amounts for different actions without explaining model costs: a quick rewrite is 1 credit, a deep research run is 25.

The design decisions that matter

Anchor credits to your cost, not your feelings. Work out the cost of each action, add your target margin, and round to a credit value. If a credit is worth about a cent to you, a 25-credit action should cost you about 25 cents or less in real spend, with margin on top.

Decide expiry on purpose. Monthly credits that expire at renewal are simple and protect your forecast. Rollover feels friendlier but creates a liability on your balance sheet and a messy accounting story. Top-up credits bought separately can reasonably last 12 months.

Keep the exchange rate stable. Several AI tools have drawn customer anger by quietly changing how many credits an action burns. If you must change it, announce it, grandfather existing plans for a window, and show the before and after.

Show the balance everywhere. A credit counter in the UI near the action, a warning at 80% used, a clear upgrade path at zero.

The failure mode of credits is opacity. If customers cannot predict how many credits a task will cost, you have rebuilt the surprise invoice with extra steps. Show an estimate before the action runs whenever the cost varies.

We recommend credits for most horizontal SaaS products that add generative features to an existing seat plan: the seat covers the product, the credit pool covers the AI. Your margin is protected, and the base price stays familiar.

Charge only when the AI delivers a result. Intercom's Fin charges $0.99 per resolved conversation, the best-known example. The customer pays for the resolution, not for the attempts, the retries or the tokens.

It is the easiest model to justify to a buyer and the riskiest to run. Your cost is variable and your revenue is conditional, so you carry the quality risk. If your resolution rate is 40% and each attempt costs money, you pay for the 60% that fail.

Preconditions before you try it

• An outcome you can define and verify. A ticket closed without the customer reopening it within 72 hours is checkable. "Better marketing copy" is not.
• A cost per attempt well below the price per outcome. You need room for failures. A rule of thumb: price at least 3 to 4 times your cost per outcome, counting the failed attempts.
• Agreement on disputes. Decide in writing who judges whether an outcome counted.

We went deep on this in our outcome-based pricing guide. The short version: it is a strong fit for support, collections, scheduling and lead qualification, where the result is binary and the value per result is obvious. For anything creative or advisory, stay with credits.

Look at how the vendors your buyers already pay have settled. The patterns are consistent enough to learn from.

Coding tools started on flat monthly fees and moved toward metering. GitHub Copilot added premium requests that count against a monthly allowance, and other AI coding products have moved from request limits to usage-based billing. We covered the budgeting side of that shift in our post on AI coding tool billing. The lesson is that flat pricing survives only until your heaviest users get good at using the product.

Support automation went to outcomes, because the buyer's alternative is a human agent with a known cost per ticket. The comparison anchors the price.

Horizontal productivity tools mostly bundled AI into higher tiers and used soft caps, because attach rates on separate add-ons were poor and the products had a strong core reason to buy.

Developer platforms stayed on pure usage with commit discounts, because their buyers want a meter and know how to read one.

The shared logic: price follows the buyer's mental model. If your buyer compares you to a human doing the task, price per outcome. If they compare you to another software subscription, use seats plus a pool. If they compare you to cloud infrastructure, meter it.

Run these checks in order and stop at the first one that applies.

1. Is the 95th percentile cost per user under 3 times the median, and is the AI a supporting feature? Bundle it into seats with a fair-use cap.
2. Is there a binary, verifiable outcome, and is your cost per outcome under a quarter of the price you would charge? Price per outcome.
3. Are your buyers technical and used to meters? Pure usage with commit tiers.
4. Everything else. Seats for the product, a monthly credit pool for the AI, top-ups on demand.

Then pressure-test whichever you picked against three scenarios before you publish the page. First, your heaviest user doubles their usage. Second, your model vendor raises prices by 30%. Third, a competitor drops their AI price to zero. If any scenario sends the feature to negative margin with no lever for you to pull, change the design.

Mistakes we see repeatedly

• Launching with unlimited usage "to drive adoption" and no plan to end it. Taking away a generous plan is far harder than starting with a limit.
• Pricing from a competitor's page without knowing your own unit cost.
• Building the meter after launch. Instrument usage from the first request even if you do not bill on it yet.
• Hiding the cost of expensive actions behind the same button as cheap ones.

For a team with a working AI feature and an existing billing system, a sensible rollout looks like this.

Weeks 1 and 2: measure

Log cost per request with customer and feature tags. Pull the usage distribution. Compute your three numbers from step zero. This costs a few days of engineering and saves you from pricing on a guess.

Weeks 3 and 4: design and test

Pick the model with the decision rule. Draft two price points and show them to five to ten customers in conversation. Ask what they would expect to pay and what would worry them. You are looking for surprise, not agreement.

Weeks 5 to 8: build

Meter events, a usage view in the product, spend alerts, plan limits and an upgrade path. If you use credits, build the ledger as an append-only table so every deduction and top-up is auditable. Use an existing billing vendor unless you have a strong reason not to. Rebuilding rating and invoicing in-house is a classic way to lose a quarter.

Week 9 onward: launch to new customers first

Apply new pricing to new signups and new add-on purchases first. Move existing customers at renewal with notice, and grandfather the heaviest accounts for a defined period while you talk to them directly. Review margin per cohort monthly for the first quarter.

The cost to do all of this ranges widely. A small team adding credits to an existing Stripe setup is looking at a modest engineering project, while a full usage platform with rate cards, invoicing and dashboards for enterprise buyers is a larger one. Scope it against your billing stack before you commit to a date.

Pricing an AI feature is a product decision as much as a finance one, and it is cheaper to get right before launch than after. If you want a second pair of eyes on your unit costs and packaging, or help building the metering and billing behind it, book a free strategy call.