AI unit economics tracks revenue per user against the cost of serving every AI-powered action, because inference cost scales with usage instead of staying flat like classic SaaS hosting. Treat every AI feature as its own variable-cost business: calculate cost per inference, design pricing around it, and govern margin continuously — not just once at launch.
Quick answer: Unit economics for an AI feature = revenue per user − cost-to-serve (driven mostly by cost per inference) = contribution margin. Recalculate it whenever you change a model, a prompt, or a pricing tier — all three move the number, sometimes overnight.
Why AI Features Are a Variable-Cost Business, Not a Fixed-Cost SaaS Line
Classic SaaS gross margins run in the 75–85% range because one more logged-in user costs almost nothing to serve. AI features break that assumption: every summary, chat turn, or agent step calls a metered model, so cost-to-serve rises with usage the way a marketplace's variable costs do — not the way a software module's costs do.
This isn't a philosophical distinction. It changes who has to own the number, and how often.
In a classic SaaS org, gross margin lives with finance and RevOps, revisited quarterly. In an AI feature, cost-to-serve moves every time engineering ships a longer system prompt, product adds a capability, or a model provider reprices — often week to week.
Stanford's HAI AI Index Report has tracked declines of more than 100x in the cost of achieving GPT-3.5-level performance in roughly a year. That's good news for margin, but only if a PM is actually watching the number closely enough to capture the drop instead of just absorbing whatever the last model migration cost.
| Dimension | Classic SaaS module | AI-powered feature |
|---|---|---|
| Marginal cost of one more user action | Near zero | Metered — tokens, GPU-seconds, or API calls |
| Primary cost driver | Support tickets, storage, edge cases | Model calls, context length, retries, tool use |
| Typical gross margin (directional) | 75–85% | Often 40–70%, compressed as usage grows |
| Who has historically owned the number | Finance / RevOps | Increasingly the PM, in near real time |
| What quietly breaks it | Support headcount, infra creep | Power users, longer context, silent model upgrades |
Investors have started underwriting this difference explicitly. a16z's research on enterprise AI adoption has flagged compressed gross margins as one of the defining risks of the category, distinct from the support-cost risk that used to dominate SaaS margin conversations. The practical implication for a PM: a feature's margin profile is now a product design constraint, on par with latency or accuracy — not a line item inherited from finance after the fact.
Gartner's own market forecasting has repeatedly flagged generative AI infrastructure spend as one of the fastest-growing lines in enterprise IT budgets, which cuts two ways for a PM. Total spend on inference is growing even as per-unit cost falls, meaning aggregate COGS can still climb for a fast-growing feature even while the underlying unit price improves. Budgeting off last quarter's per-call cost, without accounting for adoption growth, is a common way teams get surprised by a bill.
The mindset shift, in one sentence
If your pricing model assumes cost-to-serve is roughly flat across users, and your AI feature's cost-to-serve is not flat, your pricing is silently subsidizing your heaviest users at your lightest users' expense — until someone runs the numbers.
The AI Unit Economics Equation: Revenue Per User Minus Cost-to-Serve
The core equation is simple: revenue per user − cost-to-serve = contribution margin. What's hard is that cost-to-serve for an AI feature is a moving target, driven by calls per user, tokens per call, model choice, and every prompt change your team ships this sprint.
Each term deserves a precise definition, because vague definitions are how margin math quietly goes wrong:
- Revenue per user: the price or price uplift directly attributable to the AI feature — a plan price, an add-on fee, or an estimated share of a bundled price.
- Cost-to-serve: (cost per inference × calls per user per period) + orchestration and infrastructure overhead (vector stores, queues, logging) + human-in-the-loop review + incremental support load.
- Contribution margin: what's left to cover fixed costs and profit, expressed in dollars and as a percentage of revenue per user.
A running example: an AI summarization feature
Consider a hypothetical workflow tool that adds an "AI summarize this thread" feature to an existing $49/month seat. This is an illustrative model, not a reported result — the goal is to show how the arithmetic behaves, using round numbers.
Attributing revenue per user gets murkier the moment the feature is bundled rather than sold as a standalone add-on. One workable approach: price a research-backed uplift by A/B testing willingness to pay on a comparable cohort, or by treating the feature's launch-driven upgrade rate (free-to-paid, or lower-tier-to-higher-tier) as the revenue it unlocked. Either way, write the assumption down — an unexamined revenue-per-user number makes the rest of the equation meaningless.
| Line item | Illustrative value |
|---|---|
| Plan price attributable to the feature (per user/month) | $49 |
| Avg. summarization calls per user/month | 50 |
| Avg. input tokens per call (thread + prompt) | ~2,000 |
| Avg. output tokens per call | ~300 |
| Illustrative cost per call (input + output, blended) | ~$0.008 |
| Model cost per user/month | ~$0.40 |
| Infra & orchestration overhead per user/month | ~$0.15 |
| Total cost-to-serve | ~$0.55 |
| Contribution margin | ~$48.45 (≈98.9%) |
At this usage level, the feature looks like classic software margin. That's exactly why teams get comfortable — and exactly why the next table matters.
The same feature, after adoption succeeds
Now the feature is popular. Power users run it on every meeting transcript, average calls climb from 50 to 500 per month, and the team upgrades to a larger reasoning model for better summaries — roughly 6x the per-call cost.
| Line item | Post-adoption value |
|---|---|
| Avg. calls per user/month | 500 |
| Cost per call (larger model) | ~$0.048 |
| Model cost per user/month | ~$24.00 |
| Infra & orchestration overhead | ~$0.60 |
| Total cost-to-serve | ~$24.60 |
| Contribution margin | ~$24.40 (≈50%) |
Same price, same feature, half the margin — and this is the scenario that actually happens once a feature becomes a habit. For the full step-by-step formula, including how to handle shared infrastructure and amortized fine-tuning costs, the deep dive on calculating cost per inference for an AI feature walks through the math in detail.
Three questions this equation should force before you ship anything:
- What price or price uplift does this feature realistically justify, based on willingness to pay — not on what's technically easy to charge?
- What's the realistic cost per inference at p50 and p95 usage — not the demo, and not the average across a beta cohort that hasn't found the feature's edges yet?
- Where's the walk-away contribution margin threshold below which the feature gets re-scoped, re-priced, or re-modeled?
Cost Per Inference: What Actually Drives Your COGS
Cost per inference = (input tokens × input price) + (output tokens × output price), multiplied by retries and tool calls, and reshaped by model size, context length, and caching. Getting this number right — and re-checking it monthly — is the single highest-leverage habit an AI PM can build.
Both OpenAI and Anthropic publish tiered per-token pricing that separates input from output tokens and offers discounted rates for cached or repeated context. That structure is itself a signal: the model providers are telling you, through their own price sheets, that context reuse is the highest-leverage lever available to you.
The drivers that move cost per inference
- Model choice and size — a frontier reasoning model can cost an order of magnitude more per token than a smaller or open-weight model doing the same job adequately.
- Input context length — retrieved chunks, chat history, and system prompts are billed as input tokens whether or not they change the answer.
- Output length and verbosity — a chatty model burns output tokens on hedging and restatement that a tightly designed prompt can trim.
- Multimodal inputs — audio, image, and video inputs typically cost more per unit of content than equivalent text; see the complete guide to multimodal and voice AI for how those cost curves differ from text.
- Agentic loops and tool calls — every planning step, tool invocation, and self-correction in an agent workflow is a separate billable call, so a five-step agent can cost far more than its "one request" mental model suggests.
- Retries and error handling — timeouts, malformed outputs, and safety-triggered retries all re-bill the same request.
- Caching — prompt caching and retrieval caching can cut repeat-context cost substantially when the same system prompt or document recurs across calls.
- Amortized fine-tuning or embedding costs — if the feature depends on a fine-tuned model or a maintained embedding index, spread that one-time or recurring cost across expected call volume rather than ignoring it because it isn't a per-call line item.
| Cost driver | Lever to pull | Typical margin impact (directional) |
|---|---|---|
| Model size/tier | Route by task difficulty instead of one model for everything | High |
| Context length | Trim system prompts, retrieve only relevant chunks | High |
| Prompt design | Rewrite for concision and structured output | Medium |
| Caching | Cache stable system prompts and repeated documents | Medium–high |
| Agent step count | Cap planning loops, add early-exit conditions | High |
| Retries | Add validation before re-calling the model | Low–medium |
Prompt design is often the fastest lever a PM can pull without an engineering roadmap fight, because it's a content change, not an infrastructure change. The complete guide to prompt design covers the structural techniques — few-shot patterns, output schemas, instruction placement — that reduce both token count and variance in output length.
Cost per inference belongs on the same dashboard as adoption and retention, refreshed with the same cadence — not recalculated once in a spreadsheet before launch and forgotten.
The Cost-Latency-Quality Triangle: One Mental Model for Every AI Trade-off
Every AI product decision trades between three variables — cost, latency, and quality — and improving two typically degrades the third. A bigger model raises quality and cost, often raising latency too; a smaller model or aggressive caching lowers cost and latency at a quality cost. Naming the trade-off explicitly turns model-selection debates into a design decision, not a vibe check.
This isn't a new shape. Project management has used a version of it for decades: the "iron triangle" of scope, cost, and time, popularized by Dr. Martin Barnes in the late 1960s, made the same point — you can fix two corners, but the third one moves.
The one-screen version
| Corner you optimize for | What you gain | What you give up | Typical levers |
|---|---|---|---|
| Quality | Fewer wrong answers, more user trust | Cost, and often latency | Frontier model, longer context, multi-step verification |
| Cost | Better margin, room to under-price | Quality ceiling, sometimes latency | Small/open-weight model, aggressive caching, shorter context |
| Latency | Snappier UX, higher task completion | Cost or quality | Streaming responses, smaller model, pre-computation |
Most real feature decisions don't sit in a single corner — they triangulate. For the summarization example, a team might route short, well-structured documents to a small, cheap, fast model and only escalate long or ambiguous documents to a frontier model — buying quality selectively instead of paying for it on every call.
The triangle is most useful when it's visible at the same altitude as your PRD's adoption and quality targets, not buried three layers deep in an engineering design doc where a PM never sees the trade-off being made on their behalf.
AI Product Pricing Models: Usage-Based, Value-Based, or Blended Credits
Pricing model choice should follow your cost curve, not fashion. Usage-based pricing passes cost risk to the customer and protects your margin at the expense of predictability; seat-based pricing is predictable for both sides but erodes margin as usage climbs; value or outcome-based pricing captures the most value but is hardest to meter and to defend to a finance team.
| Pricing model | How it's metered | Margin protection | Customer predictability | Best fit |
|---|---|---|---|---|
| Usage-based (per call/token/credit) | Direct, transparent | High | Low — bills vary | Uneven or "power law" usage across users |
| Seat-based / flat | Indirect | Low as usage grows | High | Early-stage features, low-variance usage |
| Value/outcome-based | Tied to a business result | Highest, if defensible | Medium | Clear, measurable outcomes (e.g., tickets resolved) |
| Hybrid (base seat + usage overage or credit pool) | Blended | Medium–high | Medium–high | Most mature AI features |
For a rigorous side-by-side of the first two models — including how each performs under real usage distributions rather than theoretical ones — see the full comparison of usage-based and value-based AI pricing.
Credits have become a popular abstraction over this whole equation: a numeraire that hides raw token complexity from the customer while letting the vendor tune the internal cost-to-credit ratio as model prices shift. A credit system doesn't remove the unit economics problem — it just moves the exchange rate to a place a PM can adjust without renegotiating a contract.
Three questions to pick the right model
- Is usage concentrated in a small set of power users, or roughly even across the base? Power-law usage favors usage-based or hybrid pricing.
- Can you meter cheaply and transparently — in tokens, in credits, or in outcomes the customer already tracks?
- Is your cost curve improving faster than competitors' (via caching, model routing, or smaller fine-tuned models), letting you under-price on paper while protecting margin underneath?
Margin Governance: Monitoring, Guardrails, and the Levers That Actually Move Cost
Margin governance is the ongoing discipline of watching cost-to-serve per user, per segment, and per feature in near real time, and pulling levers before margin erodes — not a one-time model built at launch and filed away. The four highest-leverage levers are model routing, caching, tiered quotas, and prompt or context compression.
The levers, ranked by leverage
- Model routing — send easy or short requests to a small, cheap model and escalate only when a classifier or heuristic flags genuine difficulty.
- Caching — reuse cached system prompts and retrieved context instead of re-sending and re-billing the same tokens on every call.
- Tiered quotas and rate limits — cap usage on tiers where margin is negative or thin, and meter explicitly above the threshold.
- Prompt and context compression — trim system prompts, summarize long histories, and retrieve only the chunks the model actually needs. A disciplined data and retrieval strategy is often the difference between a lean context window and a bloated one, which is why the complete guide to AI data strategy is worth reading alongside your cost model.
- Human-in-the-loop and safety review — necessary, but not free; it adds latency and headcount cost that has to be budgeted into cost-to-serve, not treated as a rounding error. The complete guide to AI safety covers how to design review steps that don't quietly wreck your margin.
| Lever | Mechanism | Margin impact | Risk if overused |
|---|---|---|---|
| Model routing | Match model size to task difficulty | High | Under-routing hard cases to a cheap model, hurting quality |
| Caching | Reuse stable context instead of re-billing it | Medium–high | Stale cached context serving outdated answers |
| Tiered quotas | Cap usage where margin is negative | Medium | Frustrating power users who'd convert to a higher tier |
| Prompt/context compression | Send only what the model needs | High | Cutting context the model actually needed, hurting quality |
| Safety/review steps | Add verification before returning output | Negative on cost, positive on trust | Treating it as free and blowing the latency budget |
If nobody on your team can state this month's cost per active user for a specific AI feature, you don't have unit economics — you have a hope.
Bessemer Venture Partners' commentary on AI-native software has made a version of this point repeatedly: companies that treat gross margin as a monitored, governed metric recover it faster after a model migration or usage spike than companies that treat it as a launch-day calculation.
Common Unit Economics Mistakes That Quietly Wreck Margin
Most AI margin problems trace back to a handful of repeatable mistakes: pricing off a demo instead of realistic tail usage, treating a model upgrade as a pure quality decision, ignoring orchestration overhead, and letting free tiers absorb your heaviest users. Naming these patterns before they happen is far cheaper than discovering them in a board deck.
- Pricing off the demo, not the tail. A demo call is short and clean; production p95 usage — long threads, power users, retries — is what actually determines margin. Model the tail, not the happy path.
- Ignoring orchestration and "glue" cost. Vector database queries, embedding generation, logging, and retries are real, recurring cost that never appear on a model provider's pricing page but show up on your cloud bill.
- Treating model upgrades as a free quality win. A jump from a mid-tier to a frontier model can be a 5–10x cost multiplier per call — invisible in a product review, very visible in next month's invoice.
- Letting free or trial tiers absorb unlimited heavy usage. Uncapped free tiers are where negative-margin users concentrate, because the users most likely to max out a free plan are, almost by definition, your heaviest consumers of the metered resource.
- Not re-pricing after your cost curve improves. If caching and routing cut your cost per inference in half but your price stays flat, you've handed yourself margin — but a competitor who passes savings through as a better price or a bigger free tier can use the same improvement to take share instead.
- Treating safety and compliance review as a "later" cost. Guardrail and review layers bolted on after a launch scare are almost always more expensive, in both engineering time and ongoing latency, than the same layer budgeted in from the start; see the complete guide to AI safety for how to build review steps into the original cost model.
| Mistake | Why it happens | Fix |
|---|---|---|
| Pricing off the demo | Small test volumes look cheap | Model cost at p50 and p95 usage before pricing |
| Ignoring glue cost | Only the model line item gets scrutinized | Include vector DB, logging, and retries in cost-to-serve |
| Free model upgrades | Quality reviews don't see the price sheet | Require a cost delta alongside every model upgrade proposal |
| Unmetered free tiers | Free feels safe because it isn't billed to anyone | Cap usage or route free tier to a cheaper model |
| Stale pricing after cost drops | No trigger to revisit price once shipped | Schedule a pricing review tied to the margin dashboard, not just the roadmap |
| Safety cost deferred | Feels like a "someday" line item | Budget review and guardrail latency into the original margin model |
Operationalizing Unit Economics in the Product Organization
Unit economics fails as a spreadsheet nobody reopens after launch. It works as a recurring ritual — a monthly cost review with the same rigor as a roadmap review — with ownership split cleanly between product, engineering, and finance, so no single function is left holding the margin problem alone.
A workable split looks like this:
- Product owns the cost-quality-latency trade-off decisions and the pricing tier design.
- Engineering owns implementing the levers — routing, caching, compression — and instrumenting cost telemetry.
- Finance owns translating contribution margin into the company's broader margin and forecasting model.
The most durable version of this embeds cost per inference and contribution margin into the same living document that tracks adoption and quality — reviewed on the same cadence, not relegated to a one-time appendix a finance analyst built before launch and nobody has opened since.
What actually belongs on the margin dashboard
A short, honest list beats a sprawling one nobody checks. LLM observability tools such as Helicone and Langfuse, alongside standard cloud billing exports, can source most of these automatically once instrumented.
| Metric | Definition | Refresh cadence |
|---|---|---|
| Cost per inference (blended) | Average model cost per call, across all routed models | Weekly |
| Cost per active user | Total cost-to-serve for the feature ÷ active users | Weekly |
| Contribution margin by tier | Revenue per user minus cost-to-serve, segmented by pricing tier | Monthly |
| Model cost as % of revenue | Guardrail metric for when a feature's cost is eating its price | Monthly |
| Cache hit rate | Share of calls served from cached context instead of full re-billing | Weekly |
| p95 latency | Secondary metric tied directly to the cost-latency-quality triangle | Weekly |
Practicing these trade-offs before you build them
Most teams learn the cost-latency-quality triangle the expensive way — after launch, when finance asks why margin cratered on a feature that looked fine in the demo.
Key Takeaways
- AI features are variable-cost, not fixed-cost. Model every feature's cost-to-serve as a function of usage, not as a flat line item inherited from finance.
- The core equation never changes: revenue per user − cost-to-serve = contribution margin. What changes constantly is cost-to-serve, so recalculate it often.
- Cost per inference is a first-class product metric. Track it alongside adoption and retention, and re-check it every time a model, prompt, or context strategy changes.
- The cost-latency-quality triangle belongs on the PRD, not just the engineering doc. Naming the trade-off explicitly turns model selection into a design decision.
- Pricing model should follow the cost curve. Usage-based, seat-based, value-based, and hybrid credit models each protect margin differently — pick based on usage distribution and meterability.
- Margin governance is continuous, not a launch-day exercise. Model routing, caching, tiered quotas, and prompt compression are the highest-leverage levers, and someone has to own watching the dashboard.
- Ownership has to be explicit. Product, engineering, and finance each own a piece of the unit economics equation — and the review cadence should match the roadmap review, not a quarterly finance cycle.
Frequently Asked Questions
What is a good gross margin for an AI feature?
There's no universal number, but directionally, AI-native features often run 40–70% gross margin versus the 75–85% typical of classic SaaS, because inference is a variable cost that scales with usage. The right target depends on your pricing model, usage distribution, and how aggressively you've deployed levers like caching and model routing.
How do you calculate cost per inference?
Cost per inference is calculated as (input tokens × input token price) + (output tokens × output token price), then adjusted for retries, tool calls, and any caching discounts. Multiply by realistic calls-per-user at both median and heavy-usage levels, not just the demo scenario, to get a usable number for pricing and margin decisions.
Should I price an AI feature per seat or per usage?
Price per usage (or a hybrid with a usage overage) when usage is concentrated among power users or your cost curve is still volatile; price per seat when usage is even across users and predictability matters more to customers than precision. Most mature AI products land on a hybrid: a base seat price plus metered usage or credits above an included allowance.
What is contribution margin in an AI product, specifically?
Contribution margin is revenue per user minus cost-to-serve, where cost-to-serve is dominated by cost per inference plus orchestration overhead, human review, and incremental support. It's the number that should gate whether a feature ships as designed, gets re-scoped to a cheaper model, or gets re-priced before it reaches a broader rollout.
How often should a PM review AI unit economics?
Review cost per inference and contribution margin at least monthly, and immediately after any model upgrade, prompt rewrite, or usage spike, because all three can move the number materially and quickly. Treat the review with the same seriousness as a roadmap or adoption metrics review, not as an annual finance exercise.