Every Request Costs You Money: Pricing an AI Feature Without Bleeding Margin

Price an AI feature the way you'd price cloud infrastructure, not the way you priced software: start from the real cost of a single request, then choose seat, usage, or outcome pricing based on how tightly that cost tracks customer value. Skip that step and your heaviest users become your biggest loss.

Quick answer: An AI feature's marginal cost is never zero, so pricing has to start with a per-request cost model, not a per-seat habit. Match the pricing mechanism — seat, usage, or outcome — to how usage actually varies across your customer base, then add caps, tiers, and rate limits as structural insurance, not an afterthought.

Why an AI Feature's Marginal Cost Rewrites the Pricing Playbook

Traditional software has near-zero marginal cost — the 10,000th user costs almost nothing beyond hosting and support. An AI feature costs real money every single time it runs: every model call burns tokens, every retrieval query hits a vector database, every agentic step adds compute and latency. That per-request cost has to sit underneath any pricing decision, or growth quietly turns into a liability.

This is the single biggest mental shift required of anyone pricing an AI product. SaaS pricing models were built on an assumption that's been true for two decades: once you've built the feature, serving one more customer is nearly free. That assumption is false for anything that calls a language model. Every request has a bill attached to it — model inference, embeddings, orchestration, storage — and that bill scales with usage, not with headcount.

A few real cost drivers worth naming explicitly:

• Inference tokens. Both input tokens (the prompt, retrieved context, chat history) and output tokens (the generated response) are metered and billed by model providers, with output tokens typically priced several times higher than input tokens.
• Retrieval and embeddings. Vector search, document chunking, and re-ranking add compute cost on top of the model call itself, especially for RAG-style features.
• Orchestration and tool calls. Agentic features that chain multiple model calls, call external tools, or loop until a task is "done" multiply the base cost per user action, sometimes by an order of magnitude.
• Latency-driven infrastructure. Faster inference (dedicated capacity, smaller distilled models, caching layers) usually costs more per request, not less — speed and cost trade against each other.

Three research organizations have flagged this shift from three different angles:

• a16z argues AI-native companies need to track gross margin per query the way SaaS companies once tracked gross margin per account — the query, not the account, is where the marginal cost actually lives.
• McKinsey's research on generative AI economics has flagged inference cost as one of the largest new line items in software COGS, compressing gross margins that SaaS investors have long expected to sit near 80%.
• Gartner has cautioned that vendors bundling AI capabilities into flat-rate plans risk absorbing highly variable compute costs invisibly, with no clear trigger point at which someone notices margin eroding.

None of this means AI features are unprofitable. It means the pricing conversation has to start one step earlier than it used to: not "what will customers pay," but "what does one unit of this actually cost me, and how does that cost move as usage grows." Everything else in this article builds on that starting point — which is also, not coincidentally, the same discipline behind the broader shift in what the AI PM role now owns.

Seat-Based, Usage-Based, or Outcome-Based: Matching Price to the Cost Curve

Three pricing mechanisms map onto an AI feature's cost curve in different ways. Seat-based pricing bets that usage stays roughly uniform across users, usage-based pricing charges in rough proportion to the actual cost drivers, and outcome-based pricing charges for a result regardless of how many requests it took to produce. The right choice depends on how predictable — and how value-correlated — usage actually is.

Seat-based pricing

This is the SaaS-native default: one price per user per month, usage included. It's simple to sell, easy for buyers to budget, and familiar to procurement teams. The problem is structural, not cosmetic: seat pricing assumes every seat costs roughly the same to serve, which was true when "usage" meant clicking through a UI and became false the moment usage means "generate as many AI responses as you want."

Seat pricing still works well when the AI feature is naturally usage-capped — one summary per document, one draft per ticket, a bounded action a user does a handful of times per day. It breaks down when the feature is open-ended: a chat interface, an agent that can loop, anything a power user could plausibly run thousands of times a month.

Usage-based pricing

Usage-based pricing charges per unit of the actual cost driver — per token, per request, per generation, per API call — so price and cost move together by construction. OpenView Partners' ongoing SaaS benchmarking work has tracked a steady rise in the share of software companies adopting hybrid or fully usage-based pricing, largely driven by exactly this variable-cost pressure from AI features.

The trade-off is buyer experience: usage-based pricing is harder to budget against, introduces bill shock as a real risk, and requires metering and billing infrastructure that flat pricing never needed. Enterprise buyers in particular often want a predictable number, even if it means paying a premium over strict usage.

Outcome-based pricing

Outcome-based pricing charges for a completed result — a resolved support ticket, a generated report, a qualified lead — independent of how many model calls it took to get there. Done well, it's the tightest alignment between price and customer-perceived value, because the customer never has to think about tokens or requests at all.

It only works when the "outcome" is a discrete, countable unit the customer already recognizes as valuable — which is really a pricing-layer expression of the same question Jobs to Be Done forces you to answer: what job is the customer actually hiring this feature to do, and what does "done" look like? Get that definition wrong and outcome pricing either overcharges for trivial outcomes or undercharges for expensive ones.

Most mature AI products don't pick one lane — they blend a seat-based base fee (covers baseline access and a modest allotment) with usage-based overage past that allotment, and reserve outcome-based pricing for a narrower, high-confidence slice of the product where the outcome is unambiguous.

The Power-User Problem: A Worked Example of Margin Bleed

Flat pricing destroys margin because it charges every account the same price while some accounts consume the underlying resource at wildly different rates. The customers doing this hardest are often your best customers — the ones who found real value and pushed the feature into daily, high-volume use — which is precisely why the failure mode is so easy to miss until it's expensive.

Here's a simplified, illustrative model to make the mechanics concrete. Assume an AI feature costs roughly $0.03 per request (a blend of input and output token costs at typical frontier-model rates, plus a small retrieval overhead) and is sold as an unlimited add-on for $49 per month.

A typical user is wildly profitable at that price. A power user — someone running the feature inside an automated workflow, or simply living inside it all day — costs three times the plan price to serve. Multiply that pattern across a customer base and the picture gets worse as the feature succeeds, not better:

That table is the whole argument in one place. The more successful the feature is at driving deep, habitual usage, the faster flat pricing bleeds margin — because the accounts you should be celebrating (high engagement, high stickiness, low churn risk) are the same accounts quietly costing the most.

This is a textbook reinforcing loop: usage drives value, value drives more usage, and without a balancing mechanism the loop runs straight through your gross margin — the kind of dynamic systems thinking trains you to trace before it runs away from you.

It's also worth cross-checking against how those power users actually behave day to day. Usage logs alone won't tell you why someone runs 5,000 requests a month — mapping that behavior against a customer journey often reveals they've built the AI feature into a workflow you never designed for, which is valuable signal for the next tier or SKU, not just a cost problem to suppress.

Guardrails: Caps, Tiers, and Rate Limits That Keep the Feature Solvent

Guardrails are the mechanisms that keep a pricing model solvent between the moment you set the price and the moment you're forced to change it. A PM pricing an AI feature needs at least one structural lever beyond the sticker price, because no pricing model perfectly predicts usage distribution on day one — the guardrails are what absorb the gap.

The core toolkit:

1. Soft usage caps with overage billing. Include a generous allotment in the base price, then meter and bill anything beyond it. Customers rarely notice a soft cap they never hit, and it converts your heaviest users from a loss into revenue instead of a support ticket.
2. Hard caps and rate limits. For plans where overage billing isn't viable (free tiers, trial accounts, lower-margin SKUs), a hard request-per-day or requests-per-minute ceiling protects margin at the cost of a harder stop for the user.
3. Tiered plans with different allotments. Good/better/best tiers, each with a different included-usage number, let you segment power users into a plan priced for their actual consumption instead of subsidizing them out of the base tier.
4. Model routing by task complexity. Route routine requests to a smaller, cheaper model and reserve the frontier model for requests that actually need it. This is where cost, latency, and quality genuinely trade off against each other, and getting the routing logic right is often worth more to margin than any single pricing decision.
5. Context and prompt optimization. Caching repeated context, trimming unnecessary history, and compressing retrieved documents before they hit the model all reduce token spend without the customer noticing any difference in output.
6. Cost monitoring and anomaly alerts. Treat per-account cost like an SLO: alert when an account's spend trajectory diverges sharply from its plan, the same way you'd alert on error rate or latency.
7. Enterprise usage clauses. For large committed-usage contracts, explicit overage terms and fair-use language in the contract do at scale what a hard cap does for self-serve accounts.

None of these guardrails are "set once and forget." Model providers reprice, model capability shifts what a given task actually needs, and usage patterns evolve as customers get more sophisticated with the feature — which is exactly the territory owning a model's lifecycle after launch covers: pricing guardrails and model-version decisions are the same ongoing job, not two separate ones.

A cap that never gets hit is invisible to customers and does nothing for margin. A cap that gets hit constantly is a pricing problem wearing a rate-limit costume — it usually means the tier is priced below what that usage pattern actually costs.

Building the Unit-Economics Model — and the Judgment It Takes

A unit-economics model for an AI feature starts with defining the unit of work, pricing that unit against real provider costs, then modeling the full usage distribution — not just the average — before setting a target margin and working backward to price and caps. Skipping the distribution step is the single most common mistake.

A workable process looks like this:

1. Define the unit of work. One chat turn, one document generated, one workflow completed — pick the unit that maps cleanly to both a cost (tokens, compute) and a value (what the customer is actually paying for).
2. Price the unit. Add up token costs (input and output, at your actual model provider's rates), retrieval or embedding costs, and an amortized share of orchestration infrastructure.
3. Model the full distribution, not the average. Look at P50, P90, and P99 usage, not just mean usage — the worked example above shows why the tail is where margin actually breaks.
4. Set a target gross margin and back into price plus caps. Decide the margin floor you can tolerate (SaaS benchmarks generally target 70–80% gross margin; many AI-native products intentionally run lower, in the 50–70% range, to reflect real inference cost), then size the included allotment so the P90 user still clears it.
5. Re-run the model on a cadence, not once. Provider pricing changes, model swaps change the cost-per-token, and usage patterns shift as customers mature — a model built at launch and never revisited will silently drift wrong.

That third step — modeling quality against cost, not just cost in isolation — is where pricing decisions and product-quality decisions become the same decision. If a cheaper, faster model produces answers that fail your quality bar often enough to erode trust, the "savings" are illusory; if a bigger model clears the bar with room to spare, you're paying for headroom you don't need.

That's exactly the judgment eval-driven roadmap planning is built to sharpen — using measured quality scores, not intuition, to decide which model tier actually earns its cost.

Where this judgment gets built

Key Takeaways

• Marginal cost is the starting point, not an afterthought — every AI request has a real, metered cost (inference tokens, retrieval, orchestration), unlike the near-zero marginal cost of traditional software.
• Seat, usage, and outcome pricing sit differently on the cost curve — seat pricing is simplest but weakest on cost alignment, usage pricing tracks cost directly but is harder to budget, outcome pricing aligns tightest with value but demands a clean definition of "done."
• Flat pricing bleeds margin fastest on your best customers — the worked example shows a power user can flip a 94%-margin account into a deeply negative one, and the effect compounds as the feature succeeds and power-user share grows.
• Guardrails are structural, not punitive — soft caps, tiers, rate limits, and model routing keep a feature solvent without needing to reprice constantly or throttle every user equally.
• Model routing across the cost-latency-quality triangle is one of the highest-leverage margin levers available, often worth more than any single pricing tweak.
• Unit economics is a living model, not a one-time spreadsheet — provider pricing, model capability, and usage patterns all shift, so the model needs a revisit cadence, not a launch-day sign-off.