Here's the claim: the per-token price on the pricing page is almost irrelevant to your margin. What actually determines whether you have a business is the metering dimension the upstream provider chose — the unit they count in, the granularity of that unit, and how it maps to what your customers actually do. Most teams price their SaaS product by looking at the provider's advertised rate, slapping a multiplier on it, and calling it a margin model. That's not a margin model. That's a hope.
I've watched three separate teams get burned by this in the last year, and the pattern is identical every time. They benchmark cost using average-case usage, ship a flat-rate or seat-based plan, and then discover six months later that their power users are structurally unprofitable — not occasionally, not as an edge case, but by construction, because the billing dimension the provider uses doesn't compress the way the product's value does.
The mechanism
Providers don't sell you "intelligence." They sell you a metered unit — usually tokens, sometimes requests, sometimes seconds of compute, increasingly a blend of input tokens, output tokens, and cached tokens billed at different rates. The important thing is that this unit is chosen by them, optimized for their infrastructure economics, and it rarely aligns with the unit your customer perceives as "one use."
Your customer thinks in terms of "one summary," "one generated report," "one support ticket resolved." The provider bills you in tokens. The exchange rate between "one customer action" and "N billable units" is not fixed — it varies by input length, by how verbose the model gets, by whether the conversation has history, by whether you're using retrieval and stuffing context, by whether the customer's documents are long today and short next month. You are reselling a variable-cost input under a pricing structure that customers expect to be stable. That gap is the trap.
Worked example
Say you sell a "smart document review" feature at $49/month per seat, unlimited use, and you benchmarked cost using a sample document averaging 2,000 tokens in, 500 tokens out, at a blended rate of $6 per million tokens. Your internal model says: average cost per review ≈ $0.015. Seat does maybe 200 reviews a month in your usage logs. Cost per seat ≈ $3. At $49, that's a 94% gross margin. Beautiful. You ship it.
Three months in, your enterprise segment starts uploading 40-page contracts instead of 2-page memos. Same feature, same seat price. Input tokens per review jump from 2,000 to 35,000. Output doesn't grow much — the review is still a review — but now the input side of the metering dimension has moved 17x while your price stayed fixed. Cost per review is now roughly $0.21 instead of $0.015. At 200 reviews a month, that's $42 in provider cost against a $49 seat. Your 94% margin seat is now a 14% margin seat, and you didn't reprice anything — the provider's billing dimension just moved under you because your customer's usage pattern, not your product, changed.
Now compound this with a second detail people miss: many providers charge different rates for cached versus fresh context, or for input versus output tokens, at ratios like 4:1. If your product architecture re-sends the same system prompt and document context on every turn of a multi-turn interaction (which most naive implementations do), you're re-billing the expensive side of that ratio every single call. A customer who has a 10-turn conversation about the same document doesn't cost you 10x a single review — they cost you 10x the input-heavy portion, which is often the more expensive lever, not the cheap output-generation part you benchmarked on.
You didn't model this because your benchmark used single-turn requests. Production traffic is multi-turn. The gap between your benchmark's metering shape and your customer's real metering shape is where the margin goes to die.
The failure mode
The actual failure mode is not "we lost money on AI costs." It's worse: it's pricing inflexibility. Once you've shipped a flat-rate or seat-based plan built on an average-case cost assumption, you cannot easily reprice it. Customers anchor on the number. Sales has already sold annual contracts at that number. Support has fielded zero complaints about pricing because nothing looks broken from the outside — the invoice to your customer is stable. It's the invoice to you, from the provider, that's ballooning, quietly, denominated in a unit your customer never sees and your pricing page never mentions.
By the time finance flags that AI infrastructure cost as a percentage of revenue has tripled, you're locked into contracts you can't unilaterally reprice, your competitors who metered correctly from day one are quoting usage-based prices that look "more expensive" on paper but are actually sustainable, and you're stuck explaining to your board why a feature with a 94% margin on the pitch deck is now a 14% margin in production — and the honest answer is that you priced against the provider's sticker price instead of against their metering dimension.
What to actually do
The fix isn't "add usage caps," though that's a bandaid. The fix is to model cost distribution, not cost average — build your pricing against the 90th percentile usage shape, not the mean, and re-derive that shape separately for input tokens, output tokens, and cached tokens because they don't move together. If you want the fuller breakdown — how to reverse-engineer a provider's true billing dimension from their docs, how to stress-test a pricing plan against usage-shape drift before you ship it, and the specific contract clauses that protect you when a provider changes their metering structure — I wrote it up in detail here: https://dasdorf.gumroad.com/l/rqoiv
The sticker price was never the number that mattered. The metering dimension was.
Top comments (0)