Skip to main content
A pricing model defines what your customer pays for. It is separate from the way an inference provider charges you. You can buy tokens while selling seats, a subscription, credits, or completed tasks. Choose a customer-facing unit that is understandable and measurable, then check whether the revenue covers your cost distribution.

Overview

AI products often have variable inference costs, but those costs do not make subscriptions or seats inherently unsuitable. A fixed fee can work when usage is predictable or the plan includes an allowance. The risk is variation: a small number of heavy users can consume much more than the average customer. Measure that distribution before setting a price or allowance. Include the cost boundary that matters to your business. Model calls are one part of COGS; retrieval, storage, other compute, and human review may also contribute. Narev Cloud request pricing helps estimate inference cost, while Narev Self-Hosted provides an infrastructure cost path. Neither defines the price your customer should pay.

Pricing models for AI

Use this comparison to choose which contract you can explain and operate reliably. These are pricing approaches, not Narev plan entitlements. For example, a support product might sell a monthly subscription with an included number of resolved conversations. You still meter inference internally to see whether long conversations consume the margin. If you add overage pricing, define what constitutes one conversation and whether a reopened case counts again. Credit pricing can simplify several kinds of usage into one visible balance, but the conversion must remain understandable. Specify how many credits an action consumes and how pricing changes affect existing balances. Outcome pricing aligns the bill with a result the customer values, but it requires a reliable completion definition. A model’s assertion that a task succeeded is not always enough evidence to bill it.

Separate cost measurement from customer charges

An inference cost event answers how much a generation cost under a particular rate. An invoice line answers how much the customer owes under your contract. You may apply an allowance, markup, or different selling unit between those stages. Do not label a raw provider-cost total as customer revenue. As an illustrative calculation, if you charge 10foragroupoftasksandtheirincludedCOGSis10 for a group of tasks and their included COGS is 4, gross margin is 60% of revenue. Adding a 60% markup to 4insteadproducesa4 instead produces a 6.40 price. Margin and markup are different calculations, so state which one your billing configuration implements. Before launching, test a light user, a typical user, and a heavy user against the proposed contract. Check what each pays and what each costs to serve. Continue with usage-based billing to understand how usage records become customer charges, or use the FinOps framework to establish the measurement process first.