Research-backed calculator guide

AI SaaS Unit Economics: Build a Feature-Level COGS and Margin Model

Build an AI SaaS unit-economics model that attributes feature-level COGS, shared costs, usage distribution, contribution, and gross margin to plans and customers.

What to include in an AI SaaS unit-economics model

1. Define the unit before choosing the formula

Use the unit that matches the business decision. A plan-level monthly model is useful for pricing. A feature-level model is useful for product prioritization. A customer-level model is useful for account profitability. Cost per accepted task is useful when retries, human review, or quality gates determine whether a request created value.

Do not assume that “per user” is always the right denominator. A document-processing feature may be better measured per document, page, or approved document. A support agent may be better measured per resolved ticket. A voice feature may need seconds or minutes. FinOps guidance recommends metrics that are close to the user workflow, actionable for the team, and correlated with the resources being consumed.^[4]

A practical ledger therefore keeps at least these dimensions:

• tenant_id, plan, and customer segment
• feature and workflow version
• model, provider, region, and service tier
• input, output, cached, audio, image, retrieval, and tool quantities
• request status, retry count, and fallback path
• direct cost, allocation key, and price-table version
• revenue allocation and accepted-outcome count

2. Separate direct, shared, and operating costs

Direct feature COGS are costs you can attribute to a request or feature without an arbitrary split. Examples include provider token usage, a per-request search charge, a vector lookup charge, or storage that is metered by tenant. Shared costs support multiple features. Examples include a common API gateway, an observability platform, a warm GPU pool, or a support queue.

Use a documented allocation key for shared costs. Good keys include model-call count, tokens processed, active minutes, storage bytes, or support minutes when those measures are causally related to cost. A flat “divide cloud spend by customer count” method can be a useful first approximation, but it can hide which customer or feature drives spend. FinOps specifically warns that one usage-based metric is often more informative than a broad allocation spread across all customers.^[4]

Keep sales, marketing, general administration, and most new-product research outside gross COGS unless your accounting policy deliberately defines a different management metric. Stripe’s SaaS gross-margin guidance distinguishes direct delivery costs such as hosting, support, maintenance, infrastructure, and directly related third-party services from sales and marketing, general administration, and most product-development expenses.^[5] Publish the policy beside the model so a finance review can reproduce it.

3. Use distributions, not only averages

An average cost per customer can look safe while a small group of power users consumes the margin. Store usage by customer and summarize at least p50, p75, p90, and p95 for the main cost driver. For a flat $249 plan, compare the plan’s included allowance with the p95 cost of an active account. If the p95 account is loss-making, decide whether to change the allowance, add an overage, route some tasks to a cheaper model, or accept the subsidy as a deliberate acquisition expense.

Do not use a vendor’s public price as if it were your invoice. Discounts, enterprise commitments, regional processing, taxes, marketplace fees, minimums, batch discounts, and negotiated rates can change the amount paid. Keep a price_source, effective_date, and assumption_status for every rate. The result should distinguish a vendor quote or provider-reported amount from an internal estimate.

A feature-level model you can maintain

Build one row per feature and month, with a separate detail table for requests. The monthly feature row can contain:

1. Allocated revenue for the plan or feature.
2. Input and output token quantities, plus cached quantities where applicable.
3. Non-token units such as seconds, images, pages, retrieval operations, or tool calls.
4. Direct provider cost calculated from the matching dated rate card.
5. Retry and fallback cost, counted only when usage was accepted or otherwise billable under the provider’s evidence.
6. Shared platform and observability allocations with their keys.
7. Direct support or review labor if your management COGS policy includes it.
8. Contribution dollars and gross-margin percentage.
9. Usage distribution and a confidence or reconciliation status.

The status matters. An estimated amount calculated from logs is not the same as a provider-reported amount. A provider-reported amount is not necessarily reconciled to an invoice row. Retain the original estimate and append a variance record when later billing evidence arrives.

Worked cost example: one AI feature and one plan

Assume a US-dollar B2B plan priced at $249 per month. The plan includes an AI research feature. This is an illustrative management model, not a vendor quote. It uses the OpenAI pricing page’s displayed standard rate for GPT-6.1 Sol checked on 2026-11-02: $2.00 per 1 million input tokens and $10.00 per 1 million output tokens.^[1]

Assume the median active account generates 1,500 feature requests each month. Each request averages 12,000 input tokens and 2,500 output tokens. The feature also uses $18 per account for retrieval and storage, $12 for observability and evaluation, $25 of directly attributable support or review time, and $20 of shared platform cost allocated by model-call volume. These non-provider figures are explicit internal estimates.

The model says the plan contributes $100.50 before sales, marketing, general administration, and other excluded operating costs. It does not say the plan is “40.4% profitable.” Gross margin is a delivery-cost measure, not net profit. It also does not say every account costs $148.50. The next step is to replace the average with a distribution. If p95 usage is 2.4 times the median, the provider-token portion alone becomes $176.40 before other lines. Under the same $249 price, that p95 account would produce a negative contribution after the other assumed costs. That is a pricing and guardrail signal, not a reason to hide the tail in an average.

If prompt caching reduces the billed input quantity, model the cache-read meter separately. If a batch or discounted tier changes the rate, store the effective rate and workload eligibility. Anthropic’s documentation, for example, lists cache writes and cache hits as separate meters and notes that batch and prompt-caching discounts can combine.^[2] Google similarly documents batch reductions and caching availability by tier and model.^[3] These mechanisms can improve contribution, but only if the workload actually qualifies and the saved tokens or requests are measured.

Turning the model into pricing decisions

Use the model to compare options, not to produce one magic price. First, calculate the current plan’s median and p95 contribution. Next, simulate a base fee plus included usage and an overage. Finally, test a feature-specific route or model change. Keep service quality, latency, and reliability in the decision. A cheaper model that causes more retries or human review may have a higher effective cost.

A useful decision table looks like this:

• Positive median and positive p95 contribution: keep the plan, but monitor the distribution as usage changes.
• Positive median and negative p95 contribution: add guardrails, an allowance, an overage, or a higher tier before scaling acquisition.
• Negative median and negative p95 contribution: reprice, redesign, or reduce the feature’s cost before treating volume as growth.
• Positive provider margin but negative total feature margin: investigate retrieval, support, review, observability, or shared-cost allocation.
• High margin but low adoption: do not cut cost blindly; the feature may need better activation or a different packaging decision.

Review the model monthly and after any model, prompt, routing, pricing, or support-policy change. Reconcile provider usage against the feature ledger. The AI API invoice reconciliation calculator is useful when modeled spend and billed spend diverge. For a full-system estimate that includes development and run costs, use the AI agent development cost estimator. If observability spend is growing, compare its cost with incident and triage savings in the AI observability ROI calculator.

What this model excludes and why that matters

This article’s worked example excludes sales and marketing, corporate overhead, taxes, financing, depreciation, and the cost of building the original product. It also treats retrieval, support, evaluation, and shared platform values as internal estimates. Those exclusions are intentional: the goal is a repeatable feature-level contribution model, not a GAAP income statement.

The boundary should be stable enough to compare periods. If you change the boundary, restate prior periods or label the break. Do not compare a gross margin that includes support labor with one that excludes it and call the difference a pricing improvement. Similarly, do not compare a provider list-price estimate with an invoice total that includes a commitment discount without showing the units and assumptions.

FAQ

What is AI SaaS unit economics?

It is the revenue and cost analysis of an AI software business at a useful unit such as a customer, plan, feature, request, document, or accepted outcome. Unlike a traditional SaaS model that may treat marginal delivery cost as nearly flat, an AI model must account for variable tokens, compute, storage, retrieval, tool calls, retries, and human review where they are part of delivery.

What belongs in AI SaaS COGS?

Include direct costs required to deliver the service, such as model usage, hosting, inference, storage, bandwidth, retrieval, directly used third-party APIs, and support or review labor if your accounting or management policy treats it as a delivery cost. Keep a written boundary. Stripe’s guidance lists hosting, infrastructure, support, maintenance, and direct third-party delivery costs as typical SaaS COGS while distinguishing them from sales and marketing and general administration.^[5]

Should I price AI SaaS per seat or by usage?

It depends on usage variance and how closely customer value follows consumption. Seat pricing is simple when usage is predictable. Usage pricing aligns revenue with variable cost but can be harder for customers to forecast. A hybrid base fee with an included allowance and a transparent overage often gives a team both budget predictability and protection against extreme usage. Test the model against p50 and p95 customers, not just the average.

How do I calculate AI cost per customer?

Sum the customer’s direct model and tool meters, add documented allocations for shared platform costs, and include delivery labor if your policy requires it. Divide by the customer period, such as one month, or by accepted outcomes if the decision is cost per successful task. Keep the raw quantities and rate version beside the dollar amount so a later invoice or usage export can be reconciled.

Are public model prices enough to forecast margin?

No. Public rates are a starting assumption. Your effective cost can differ because of cache hits, batch eligibility, service tier, regional or marketplace pricing, negotiated discounts, minimums, taxes, failed-but-billable attempts, and tokenization differences. Date every rate and label it as a vendor-published rate, quote, provider-reported amount, or internal estimate.

How often should an AI SaaS margin model be updated?

Refresh provider rates and usage data whenever a vendor changes pricing or your routing changes, and review the feature ledger at least monthly. Recheck after a prompt change, new model, cache policy, retry-policy change, or pricing experiment. A quarterly review can be too slow when usage or model mix is changing rapidly.