How to Build a Unit Economics Model for an AI Product

Cursor was running a negative 23 percent gross margin in the quarter ending January 2026, at roughly $2 billion in annualized revenue. Read that again. A company most founders would kill to be was losing money on every single dollar customers handed over, because the models underneath cost more than the subscriptions on top.

That's not a Cursor problem. It's an arithmetic problem, and it shows up in almost every AI product built by someone who learned software economics from the SaaS era. A unit economics model for an AI product has to answer one question that classic SaaS never had to take seriously: what does it cost me, in cash, every time somebody uses this thing?

Most first-time founders skip the model entirely and find out the answer from their credit card statement. Let's do it the other way round.

What is a unit economics model for an AI product?

A unit economics model for an AI product is a per-customer profit and loss statement: revenue from one customer, minus everything it costs to acquire and serve that one customer, over the time they stay. The difference from SaaS is that "serve" now includes a variable cost that scales with usage rather than a fixed cost that scales with headcount.

In traditional SaaS, cost of goods sold ran 15 to 25 percent of revenue and barely moved when a customer got enthusiastic. Hosting was mostly paid for either way. In AI-first companies, COGS commonly lands at 40 to 50 percent of revenue once you count model hosting, inference, and data. Inference alone eats about 23 percent of revenue at scaling-stage AI B2B companies.

So the model isn't optional bookkeeping. It's the thing that tells you whether growth makes you richer or poorer.

What counts as a "unit" when usage varies wildly?

Your unit is one paying customer, but you can only model it with any accuracy if you first model one action: one query, one agent run, one generated document, one resolved ticket. Cost per action times actions per customer gives you cost per customer. Trying to skip to the customer level is where the model goes wrong.

Here's the thing nobody warns you about. You need three versions of "actions per customer," not one. The median user, the 95th percentile user, and the blended average. Modeling only the average is how founders end up with a spreadsheet that says 70 percent margin while the finance reality says 40.

Write down these numbers before you touch a formula:

• Actions per customer per month at the median
• Actions per customer per month at the 95th percentile
• Input tokens per action, including system prompt, retrieved context, and conversation history
• Output tokens per action
• Retries and failed runs as a percentage (most teams forget this one entirely, and it's rarely under 5 percent)
• Non-model costs per action, like web search calls, vector database reads, or third-party APIs

If you don't have real usage data yet, estimate by running the workload yourself fifty times and logging what happened. Fifty real runs beat any assumption you could reason your way to.

How do you calculate cost to serve one AI customer?

Multiply tokens per action by your model's per-token price, add every non-model variable cost, multiply by actions per month, then add the per-customer allocated costs like storage, observability, support, and payment processing. That total is your cost to serve.

Let's work a real example instead of waving at one.

Say you're building a research agent that finds prospect information and drafts outreach. You charge $99 a month and include 500 prospects. Each prospect run makes roughly eight model calls, burning about 25,000 input tokens (mostly web page content getting stuffed into context) and producing about 3,000 output tokens.

On a mid-tier model at $2 per million input tokens and $10 per million output:

• Input: 25,000 / 1,000,000 x $2 = $0.050
• Output: 3,000 / 1,000,000 x $10 = $0.030
• Model cost per run: $0.080
• Web search API at five searches per run: $0.020
• Run total: $0.10

Now the monthly customer:

Line item	Cost per customer per month
Inference, 500 runs x $0.08	$40.00
Web search, 500 runs x $0.02	$10.00
Storage, vector DB, observability	$3.00
Payment processing (2.9% + $0.30)	$3.17
Total cost to serve	$56.17
Revenue	$99.00
Gross profit	$42.83
Gross margin	43.3%

Forty-three percent. Not a disaster, but below the 50 to 70 percent band AI-native companies are expected to hit in 2026, and a long way from the 80 percent number that lives rent free in every founder's head.

Now change one variable. Run the identical product on a flagship model at $5 input and $25 output, and your cost per run goes from $0.08 to $0.20. Five hundred runs becomes $100 of inference against $99 of revenue. You are underwater before you've paid for anything else. Move up to a top-tier model at $10 and $50 and it's $200 of inference on $99 of revenue.

The output price gap between the cheapest usable models and the frontier ones is roughly one hundred to one right now, from about $0.50 to about $50 per million tokens. Model choice is almost always the single biggest lever in the whole model. Test whether the cheap one is good enough before you assume it isn't.

What gross margin should your model produce?

Target 60 percent or better, accept 50 percent, and treat anything below 40 percent as a design flaw rather than a phase you'll grow out of. The average AI product gross margin in 2026 sits around 52 percent, against the 70 to 90 percent that mature SaaS delivers.

Two things to keep straight. First, put inference in COGS, not in operating expenses. Plenty of AI startups park model spend in R&D because it started life as an experiment, which makes gross margin look beautiful and makes the number useless. Investors unpick this in about four minutes.

Second, margin should improve with scale, and you should be able to say exactly why. Committed spend discounts, caching, smaller fine-tuned models for the common path, batching. If your model shows margin improving because "we'll optimize," that's not a model, it's a wish.

You can build this in a spreadsheet, in Notion, or in a planning tool like Foundra that walks first-time founders through cost structure and financial projections section by section. The format matters much less than whether the assumptions underneath are written down where someone can argue with them.

How do CAC and payback change when delivery costs real money?

CAC barely changes, but payback period nearly doubles, because payback is calculated on gross profit rather than revenue. This is the part of AI unit economics that catches founders completely off guard.

Back to the research agent. Median B2B SaaS customer acquisition cost in 2026 runs $500 to $2,000, with self-serve product-led motions coming in under $700. Take $700.

• At 43 percent margin: $42.83 gross profit per month. Payback = 16.3 months.
• At classic 80 percent SaaS margin: $79.20 per month. Payback = 8.8 months.

Same product, same price, same CAC. The token bill added seven and a half months to how long your cash is tied up. Median SaaS payback in 2026 is 15 to 18 months, so 16.3 isn't alarming on its own. What's alarming is the lifetime value math.

At 4 percent monthly churn, average customer lifetime is 25 months. Lifetime gross profit is 25 x $42.83 = $1,071. Against $700 CAC, that's an LTV to CAC ratio of 1.5 to 1. Investors want 3 to 1. To get there you'd need CAC down near $355, or churn cut roughly in half, or margin up around 60 percent. Probably some of each.

Run this calculation before you spend a dollar on paid acquisition. The median SaaS company now spends $2.00 to acquire $1 of new ARR. On AI margins, that math gets tight fast.

How do you model the free tier without lying to yourself?

Add free tier inference cost into your cost to serve, allocated across paying users. This is the single most common omission in AI unit economics models, and it's the one that quietly kills companies.

The arithmetic is unforgiving. If 3 percent of your users convert to paid, every paying customer is carrying the AI bill for about 33 free users. Give those free users a generous allowance and you can wipe out your entire gross profit without a single line item looking wrong.

Take the research agent again. Suppose the free tier allows 10 runs a month, costing $0.80 of inference. Thirty-three free users at $0.80 is $26.40 of cost sitting against $42.83 of gross profit from the one paying customer. You're left with $16.43. Alive, but thin. Now imagine the free tier allowed 50 runs. That's $132 of free-user cost against $42.83 of gross profit, and the business is structurally dead no matter how fast it grows.

So cap the free tier by cost, not by feature. Decide what you're willing to spend acquiring one trial user, convert that into a number of actions, and set the limit there. Then watch the free-to-paid rate. Below 2 to 3 percent and you're funding a very expensive hobby.

The same logic applies to paid tiers. Set your included allowance so 70 to 80 percent of users stay comfortably under it, and meter or throttle above that. Caps are not hostile to users. They're what lets you keep the price low for the majority.

What happens to your model when token prices fall?

Assume nothing. Model at today's prices and treat any price decline as upside, not as a plan. Token prices dropped roughly 80 percent year over year for equivalent capability, and total AI spend still grew 320 percent over the same period, because cheaper tokens mean people use more of them.

That's the trap. Founders look at the a16z observation that inference cost for a given performance level falls about tenfold per year and conclude their margin problem solves itself. It doesn't, for two reasons. Your competitors get the same price cut, so it lands in the customer's pocket through price competition rather than yours. And cheaper tokens change user behavior: features you'd have rationed become features you ship, and consumption per customer climbs.

Build the model with a usage growth assumption alongside the price decline assumption. If price per token falls 50 percent and usage per customer rises 60 percent, your cost per customer went up.

What are the most common AI unit economics mistakes?

The big five, in the order they show up:

1. Modeling the average user only. Your median user might be 82 percent margin while your top 5 percent are negative. Blended averages hide this until the heavy users churn in and the light ones churn out.
2. Forgetting retries, evals, and internal usage. Failed runs cost the same as successful ones. So do your own team's testing, your eval suites, and every demo you give.
3. Filing inference under R&D. It's COGS. Putting it anywhere else produces a gross margin number that means nothing.
4. Ignoring the free tier. Covered above, and worth repeating because it's the most expensive mistake on this list.
5. Assuming optimization later. Caching, smaller models, and prompt compression are real levers worth 30 to 60 percent. But "we'll optimize" without a named technique and an estimated saving is not a financial assumption.

One more, and it's the one that separates the founders who make it. Don't build this model once. Rebuild it monthly against actual spend. Your token bill is the only honest auditor you have.

Key takeaways

• Build the model bottom up: cost per action, then actions per customer, then cost to serve.
• Model three usage profiles, median, 95th percentile, and blended. Never just the average.
• Target 60 percent gross margin, accept 50, treat below 40 as a design problem.
• Model choice is usually your biggest lever. The price gap between cheap and frontier models is about 100 to 1 on output tokens.
• Calculate CAC payback on gross profit, not revenue. AI margins can nearly double your payback period at identical CAC.
• Cap free tiers by cost, not features. At 3 percent conversion, every paying user funds about 33 free ones.
• Model at today's token prices. Cheaper tokens historically lead to more usage, not lower bills.

If you want the surrounding pieces, the free calculators at foundra.ai/tools/ cover burn rate, runway, and startup costs, which feed the same financial model this sits inside.

FAQ

What gross margin do investors expect from an AI startup in 2026?
Between 50 and 70 percent, with 60 percent generally treated as the floor for a credible Series A story. The 2026 average across AI products is about 52 percent. Below 40 percent you'll be asked to explain your path to improvement in detail.

Should inference costs go in COGS or operating expenses?
COGS. Inference scales with usage and is a direct cost of delivering your product. Classifying it as R&D inflates gross margin and is the first thing a diligence process corrects.

How do I estimate cost per action before I have users?
Run the workload yourself fifty times and log token counts from your provider's API response. Every major provider returns input and output token counts per call. Fifty runs gives you a usable median and a rough spread.

What's a healthy LTV to CAC ratio for an AI product?
The same 3 to 1 that applies to SaaS, but it's harder to hit because the gross profit side of LTV is smaller. If your ratio is under 2 to 1, fix margin or churn before spending on acquisition.

Do I need a different model if I self-host instead of using an API?
The structure is identical, but your costs shift from variable to fixed, which means idle GPU time becomes the thing to watch. For most products spending under about $5 million a year on inference, hosted APIs come out cheaper once you price in the operations work.

How often should I update my unit economics model?
Monthly, against actual provider invoices. Assumptions drift fast when model prices, usage patterns, and your own prompt lengths all change quarter to quarter.