AI SaaS pricing vs API costs: unit economics that survive real usage

Quick answer: price the distribution, not the average.

Your customers pay a flat monthly price. Your model provider bills you per token. Those two curves do not move together, and the gap between them is your gross margin. The mistake that quietly kills AI SaaS margins is pricing against the average user, because LLM usage is heavily skewed: most users barely touch the AI features while a small tail runs them constantly. At official list prices, a median assistant-style user costs anywhere from about eight cents to about four dollars per month in model calls, depending on which model you serve. The heaviest users in the same product can burn ten times that, which puts a flagship-model power user above the full price of a $19 seat on their own. The rest of this page works that math end to end: what actually drives per-user COGS, a worked unit-economics table for a $19 seat, the pricing structures that survive skewed usage, and the levers that protect margin, including the per-token rate itself.

Where per-user COGS actually comes from.

The visible chat message is a small minority of what you pay for. A user types 50 tokens; the request you actually send carries a system prompt, retrieved context, conversation history, and tool definitions, and lands closer to 3,000 input tokens. That ratio, not the model price sheet, is where most per-user cost estimates go wrong. Output pricing amplifies feature choices. On most price sheets output tokens cost five to six times input, so a drafting feature that writes 1,500-token documents has a completely different cost profile from a classifier that returns one label. Estimate each AI feature separately with three numbers: requests per month, input tokens per request, output tokens per request. Everything downstream in this article is that triple multiplied out.

• System prompt and tool definitions: resent with every single request, before the user has typed anything.
• Retrieval context: RAG chunks injected per request often outweigh the visible user message several times over.
• Conversation history: multi-turn sessions re-send prior turns, so input volume grows as engagement grows.
• Background calls: title generation, summarization, moderation checks, and embeddings all bill tokens the user never sees.
• Retries and regenerations: the same work billed twice, sometimes silently inside your own retry logic.

Worked example: the unit economics of a $19 seat.

Assume an assistant feature inside a product priced at $19 per user per month. The median active user sends 150 requests a month. Each request carries about 3,000 input tokens once the system prompt, retrieval, and history are counted, and returns about 400 output tokens. That is 450K input and 60K output tokens per median user per month. The P95 power user runs ten times that volume. The table prices that consumption at official list rates for models across the quality ladder.

Why AI SaaS margins surprise operators.

Two things fall out of the worked table above. On a mid-tier or budget model, AI COGS is a rounding error against a $19 seat and the margin story looks like classic SaaS. On a flagship model the tail eats you: one P95 user costs more than double their seat price. With 95 percent of users at the median and 5 percent at P95, blended COGS on gpt-5.5 comes to about $5.87 per user, roughly 69 percent gross margin before hosting, support, and payment fees. The same blend on gpt-5.4-mini is about $0.88, better than 95 percent. None of this shows up in a launch-week spreadsheet, because launch-week usage has no tail yet. Margin problems in AI SaaS are usually discovered around month three, after the product has found its heavy users and a feature shipped in month two quietly doubled input tokens per request. Instrument per-user cost from the first day and these surprises become alerts instead of write-offs.

• Averages hide the tail. Usage distributions are long-tailed, and the P95 cohort drives most of the model bill.
• Free tiers bill you for users who pay nothing, and free users have no reason to economize.
• Context creep: a feature that adds more history or bigger RAG chunks raises input tokens per request without any price change on either side.
• Output-heavy features flip the ratio. Long drafts and reports make expensive output tokens the dominant line.
• Annual plans lock your revenue while per-user usage keeps compounding month over month.
• Retries, regenerations, and eager background jobs double-bill work that produced one visible result.

Seat, usage, credits, or hybrid: pricing structures compared.

There is no universally correct structure. The deciding variable is the spread of your usage distribution: the wider the gap between median and P95, the more dangerous a pure flat seat becomes. A useful rule of thumb: if your P95 user consumes ten times your median user, a flat seat needs either a fair-use cap or a model-downgrade path, because the alternative is that your most engaged users are your least profitable ones. Hybrid structures, a seat with an included allowance plus metered overage, are the most common landing spot for AI SaaS precisely because they keep the predictable revenue of seats while capping tail risk.

Seven ways to protect gross margin.

The first six levers cut token volume. The last one cuts the price of every token that remains, which is why it compounds with all the others. One gateway option is APIsRouter, an OpenAI-compatible API with pay-as-you-go billing and no subscription: global models are priced 20% below official list, Chinese models sit below their official rates, the first top-up adds +100% balance, and the checkout at /topup takes payment first and emails the key. The ladder below shows what a tiered setup looks like at those rates, using the same median-user assumptions as the worked example.

• Meter per user from day one. Every OpenAI-compatible response returns token usage; store it with a computed dollar cost on each request row.
• Tier your models. Serve the flagship only where quality is customer-visible, and route classification, titles, and summaries to budget models.
• Cap the free tier hard. A cheap model plus a daily request limit turns free users from an open-ended leak into a fixed, forecastable acquisition cost.
• Trim the context. Cap history length, retrieve fewer and better chunks, and keep system prompts short: input tokens are the bulk of assistant-style bills.
• Cache aggressively. Prompt caching discounts repeated prefixes, and application-level caching answers repeated questions without a model call at all.
• Write fair-use terms into flat seats, and alert internally before any user crosses their seat price in COGS.
• Lower the per-token rate itself by routing through a cheaper OpenAI-compatible endpoint instead of paying official list prices.

Config example: route by plan and meter every request.

Model tiering and metering are one small wrapper, not a platform project. Point an OpenAI-compatible client at your gateway, map plans to model IDs, and persist the usage object that comes back on every response. Standard OpenAI SDKs work unchanged because only the base URL moves. A nightly query over the same table then tells you which users are approaching negative margin before the invoice does:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.apisrouter.com/v1",
    api_key="sk-...",  # server-side env var, never shipped to the client
)

MODEL_BY_PLAN = {
    "free": "deepseek-v4-flash",
    "pro": "gpt-5.4-mini",
    "escalation": "claude-sonnet-4-6",  # quality-critical paths only
}

def complete(user_id: str, plan: str, messages: list[dict]) -> str:
    resp = client.chat.completions.create(
        model=MODEL_BY_PLAN[plan],
        messages=messages,
        max_tokens=600,
    )
    u = resp.usage
    save_usage(user_id, resp.model, u.prompt_tokens, u.completion_tokens)
    return resp.choices[0].message.content

FAQ