What does an AI feature cost per user? Multiply the provider cost of one use by the number of uses each customer makes in a month. For most features the average comes out small. The trouble is that AI usage is skewed: a few heavy users, and any feature that runs an agent, can cost more than their subscription while the average still looks fine. This guide sets out the formula, a worked example of the skew, and the levers that move the margin.
Why AI features change SaaS margins
Classic SaaS gross margins rest on software whose cost per extra user is close to zero: the hundredth customer barely moves the hosting bill. An AI feature does not work that way. Every use sends tokens to a model provider, and the provider bills for every one of them. The cost of revenue now scales with how much customers use the product, not just how many customers there are.
That has three consequences:
- Cost depends on behaviour you do not control. The same plan can cost you a few cents for one customer and many dollars for another.
- Cost can change without a deploy. When a provider changes a rate, your margin changes. Google's pricing page already lists Gemini 3.8 Flash doubling from $0.75 and $3.75 to $1.50 and $7.50 per million tokens on 1 January 20271.
- New feature types multiply cost per use. An agent that runs twenty model calls to finish a task costs twenty times what a single answer does.
The formula
cost_per_use = Σ over calls (input_tokens × input_rate
+ cached_tokens × cached_rate
+ output_tokens × output_rate)
ai_cost_customer = cost_per_use × uses_per_month
ai_margin = revenue_customer − ai_cost_customer − other_cost_of_revenueTwo notes on the inputs:
- Use the rate you actually pay. If your company has a negotiated rate with a provider, a list-rate figure is wrong on every request by the size of your discount.
- Count all the calls behind one use. A "use" of a retrieval-augmented answer can include an embedding call, a rerank call and the answer itself. A use of an agent includes every step.
A worked example of the skew
The example is invented, but its shape is the normal one: a long tail of light users and a small group that uses the feature as a core workflow. A dashboard that shows only the average will report a healthy feature right up to the month a few accounts start automating against it.
Agent features: cost per task, not cost per call
Agent-style features — research assistants, coding agents, workflow automations — run many calls per task, and each call re-sends a growing context. The unit worth measuring is the cost of a finished task.
Two consequences for pricing. Agent features usually need a usage-based component so revenue grows with cost, and every task needs a ceiling: a step limit, a token limit and a spend limit, so one stuck loop cannot cost what a hundred normal tasks do. Bounding AI agent loops covers the limits.
The levers, in order of effect
| Lever | What it changes | Typical trade-off |
|---|---|---|
| Model tier | Rate per token, often by 10x or more between tiers | Quality on harder requests |
| Output length | Output tokens, usually the most expensive meter | Answer completeness |
| Prompt caching | Input cost of long, repeated prefixes | Cache writes cost more than plain input on some models |
| Batch processing | Half the rate on OpenAI, Anthropic and Gemini | Results arrive later |
| Routing by difficulty | Sends easy requests to a small model | Needs a classifier or rules, and evaluation |
| Limits per plan | Caps the cost of the heaviest customers | Some customers hit a wall |
The rates behind the table are on each provider's page: Batch is half the standard rate on OpenAI's text models, on Anthropic's Batch API and on Gemini's Batch tier231. Background work — summarising yesterday's tickets, tagging documents, generating reports — is the first thing to move.
Output length deserves more attention than it gets. On most current models output costs five times input per token, so an assistant that answers in 300 tokens instead of 900 has cut most of its per-use cost without touching the model. Measure cost per successful task when you change a lever: a smaller model that needs two attempts is not a saving.
Pricing patterns that protect margin
- Included allowance plus a limit. Each plan includes a monthly amount of AI use sized so the plan's heaviest normal customer stays profitable; beyond it the feature slows, stops, or asks for an upgrade. This keeps pricing simple and caps the tail.
- Allowance plus usage price. The same allowance, with metered usage above it at a price that covers provider cost plus your margin. This suits agent features and API products. Metering AI usage for usage-based billing covers the plumbing.
- Separate AI add-on. A paid add-on with its own allowance keeps the base plan's margin intact and makes AI cost visible as its own line in revenue.
Whichever you choose, the allowance should be stated in a unit customers understand (answers, tasks, documents, minutes of audio), not in tokens, and converted to provider cost internally.
Measuring it in practice
You cannot manage a per-customer margin you do not measure. Three things make the numbers reliable:
- Tag every request with an opaque customer id. Send it with the request so cost can be summed per customer later. Anthropic's
metadata.user_idand OpenAI'ssafety_identifiertake an opaque id for abuse detection; for your own accounting you need the same id recorded beside the cost. - Record cost at the time of the request, at the rate in force then, so last quarter's margin does not change when a rate does.
- Report percentiles. Median, 90th, 99th and maximum cost per customer per plan, every month. The 99th percentile is where pricing decisions are made.
Then check the total against the provider's invoice once a month. A per-customer figure is always an estimate, because provider cost APIs report organization totals; the total is what reconciles.
Measuring per-customer cost with INFRO
INFRO records each request your application sends with the end-customer id you pass in metadata.user_id or the X-INFRO-User-Id header, and an estimated provider cost at the vendor's list rate or, from the Team plan, your negotiated rate. The console's Customers page lists your most expensive end customers with cost per request and the change against the previous period, on every plan. From the Team plan you can cap what each end customer may spend per day, week or month, refused before the provider is called, and export usage per end customer, project and model to load into your own billing system. INFRO bills you a subscription; it never bills your customers and adds nothing to the provider's rate.
Summary
Work out cost per use for each AI feature, multiply by real usage per customer, and look at the distribution rather than the average. Put a ceiling on every agent task and every plan, move background work to batch rates, keep answers as short as they can usefully be, and review the numbers whenever a provider changes a price.