The margin question every AI deal should start with

Classic SaaS trained investors to expect gross margins near 80 percent, because serving one more customer cost almost nothing. LLM products broke that assumption. Every request carries an inference cost, paid per token to a model provider or per GPU-hour to a cloud, and that cost scales with usage in a way SaaS hosting never did. An AI startup’s gross margin is not a line to check at the end of diligence. It is where the analysis should start, because it tells you whether growth makes this business better or worse.

The question is easy to pose: what does one unit of product cost to serve (a request, a document processed, a task completed), and what is it sold for. Teams running a real business answer in seconds, with a number. Teams that answer in adjectives have just handed you your first finding.

What one request actually costs

The naive calculation is input tokens plus output tokens, times the price sheet. Production is more expensive than that. One user-visible action typically triggers several model calls: planning, tool use, validation, retries. Each call carries assembled context (system prompt, retrieved documents, conversation history) that often outweighs the user’s actual input several times over. Around the model sit embeddings, reranking, and the fallbacks that reliability requires. Then come the costs that never make it into the demo math: logging and observability, evaluation runs, and human review wherever the stakes demand it.

So we ask for cost per completed task, measured in production, and we ask for the distribution rather than the average. Averages hide the customer whose agent loops forty times per document, and heavy tails are where margins go to die.

Gross margin at scale is a design property

Margin at the current scale is an observation; margin at ten times the volume is an architecture question. Caching, routing cheap requests to cheap models, context discipline, batching: these are engineering choices, and a team has either made them or still holds headroom it has not claimed. The distinction matters for what you underwrite. A margin problem is fixable when the architecture allows routing and caching; it is structural when the product only works on the most expensive model with the context window full. What disciplined cost engineering looks like is its own subject, covered in your AI bill at ten times the volume.

Pricing design is the other half. Usage-based costs under seat-based pricing means the most enthusiastic customers can be the least profitable ones. Ask for margin by customer and by plan: if the answer is a single blended number, nobody has looked.

Sensitivity to model pricing

Per-token prices have fallen repeatedly, and every AI deck extrapolates that fall into its margin projections. Three forces eat the windfall. Products migrate to newer, more capable, more expensive models to stay competitive. Reasoning-heavy features consume far more tokens per task than their predecessors. And usage per customer grows as the product improves. We do not underwrite margin improvement on price declines alone, and we test the other direction: what happens to unit economics if the primary provider raises prices or a committed-use discount fails to renew. That is a dependency question as much as a margin one, treated in model provider dependency.

What to ask for in the data room

• Cost per completed task by month for the last year, with the measurement method
• Gross margin by customer and by plan, with model and infrastructure costs actually allocated, not pooled
• The inference bill by provider, next to revenue, for the same months
• Retry, fallback and human-review rates on the main workflows
• Pricing assumptions: usage per seat assumed at signing versus observed
• Provider contracts: committed spend, discounts, and their expiry dates

None of this is exotic. A team that measures its business produces it in a day.

How teams that know their numbers answer

Immediately, consistently, and from a dashboard rather than a spreadsheet built for the data room. The CFO’s number matches the CTO’s number. They know which customer has the worst margin, and they have fixed it, repriced it, or decided to carry it for a reason they can state.

The answers that concern us: "inference costs are basically negligible", which nearly always means nobody has measured; a healthy blended margin propped up by a legacy revenue line while the AI product loses money per request; and projections that assume model prices fall while usage per task stays flat. Any of these moves unit economics up the risk register, alongside the other areas in the AI due diligence checklist we use.

Margins are the fastest test of whether an AI company is a business or a subsidized demo, and the data to answer the question already sits in the target’s billing consoles. Pulling that thread properly is one of the first things we do in an AI due diligence.