The Meter Is Running

Why AI Breaks the SaaS Pricing Playbook

A few months ago, I sat in on a product review at a Series B SaaS company. The team was proud. They had shipped an AI assistant feature, customers loved it, and usage was climbing every week. The VP of Product was showing a chart of engagement going up and to the right.

Then the CFO asked a simple question: “What does this feature cost us per active user, per month?”

Nobody in the room knew. Not the PM. Not the engineering lead. Not the head of design who had championed the feature. They had shipped something customers loved and had no idea whether it was making or losing the company money.

This is happening in product organizations everywhere right now, and it’s not a finance problem. It’s a product problem. For twenty years, SaaS product teams have been trained to think about cost as someone else’s job. AI is ending that, or at least threatening to. And the teams that don’t understand the shift, including its genuine uncertainty, are going to find out the hard way, usually in a board meeting.

The Old Model: Cost Was a Rounding Error

Think about how most of us learned to build SaaS products. You built the software once. The marginal cost of serving the next customer was close to zero. A few dollars of AWS spend, maybe some support overhead, and that was it. The economics of the business were almost entirely about acquisition and retention, not about the cost of serving any individual request.

This shaped everything about how product teams operated. We priced per seat because seats were a decent proxy for value and dead simple to bill. We didn’t build cost dashboards into our product analytics because cost wasn’t a meaningful variable in the product decision. A PM could ship a feature used by five customers or five thousand, and the incremental infrastructure cost barely moved the needle. Product managers optimized for engagement, retention, and expansion. Cost sat quietly in a spreadsheet owned by finance.

That model made sense for compiled software running on commodity infrastructure. It does not obviously make sense for a product where every interaction calls out to a model. I say “not obviously” deliberately, because this is where the story most product teams tell themselves gets ahead of the facts.

Why AI Changes the Math

With AI-powered features, the cost of serving a customer is no longer a rounding error. It’s a line item that scales directly with usage, and usage is exactly what you’re trying to grow.

Every prompt costs tokens. Every token costs money. A customer who loves your AI assistant and uses it 50 times a day is not free marginal usage of an already-built product. That customer is 50 API calls a day, each with a real cost, and that cost lands on your income statement whether or not you’ve figured out how to charge for it.

This inverts a habit that’s been baked into product thinking for two decades. We used to celebrate usage as pure signal of value with no downside. Now usage is value and cost, tangled together, and a product team that only tracks the first half is flying blind.

Inference Costs Are Falling, Fast

The cost to run a given unit of model intelligence has been dropping at a remarkable rate, something in the neighborhood of an order of magnitude a year on a cost-per-token basis for a fixed level of capability. What cost a dollar to generate two years ago costs a fraction of that today, and the trend line hasn’t shown real signs of stopping.

That matters enormously, because it means the anxiety a lot of product teams feel right now, “our AI feature costs are going to eat us alive as we scale,” is not a stable, permanent state of the world. It might be a temporary condition tied to where we are in the model cost curve. A feature that looks financially reckless today, at today’s inference prices, may look completely ordinary in eighteen months.

So which is it? Is the marginal cost of AI a permanent structural shift in how software economics work? Or is it a transitional cost problem that mostly resolves itself if you’re patient and your architecture doesn’t lock you into an expensive dead end?

Honestly, I don’t think anyone knows yet. There’s a second wrinkle that makes it even harder to answer, and it’s the one that gets talked about the least: the price you’re paying today for inference is not necessarily based on the actual cost of producing it. The major model providers are in a period of aggressive investment to build adoption, lock in developer mindshare, and win the platform war before the market settles. Some of that shows up as pricing pushed well below what the compute, energy, and capital costs would suggest on a fully loaded basis. Nobody outside those companies knows exactly how large that gap is, and they have no incentive to make it visible. It would be naive to assume the API price you see today is a clean, sustainable number rather than, in part, a subsidized one designed to get you building on their platform before anyone raises prices.

So the net effect of efficiency driving falling per-token costs vs. platform subsidies quietly hiding the true total costs is genuinely unclear. That uncertainty, not a confident prediction in either direction, is the actual condition product leaders need to plan around.

Why the Uncertainty Doesn’t Let You Off the Hook

None of that is a reason to go back to ignoring cost as we did in the pure SaaS era. It’s a reason to hold two things at once: real cost discipline today, and real humility about where the cost curve goes.

Every prompt still costs tokens right now, at today’s prices, whatever their true underlying economics might be. Customers who love your AI assistant drive many API calls a day, with a real, current, billable cost, whether or not that cost is subsidized and whether or not it falls next year. That cost lands on your income statement this quarter. The fact that it might be a smaller number next year doesn’t help you if it sinks your unit economics between now and then.

I’ve started asking product teams two questions instead of one. First, what is your current cost per interaction? Second, how sensitive is your business model to a 2-fold to 5-fold swing of that cost in either direction? A team that can only answer the first question is still ahead of most of the market. A team that can answer both is actually managing the risk.

Two Teams

I see two very different types of teams handle this moment, and the distinction isn’t about who’s more bullish on falling costs. It’s about who’s built for the uncertainty rather than betting the business on a single guess.

The first team picks a lane and holds it rigidly. Either they assume costs will keep collapsing and give away generous AI usage because “it’ll be cheap soon anyway,” or they overcorrect, treat every model call as precious, throttle features aggressively, and ship a worse product than a competitor willing to be more generous. Both are bets on a single future nobody can actually see, and when the bet is wrong, the damage shows up in the customer relationship. Usage gets quietly capped in ways nobody explained, or a feature gets buried behind a paywall with no warning.

The second team builds optionality instead of conviction. They design their architecture so they can swap models, downgrade to cheaper ones for lower-stakes tasks, and cache aggressively, so their cost structure isn’t hostage to any one provider’s pricing decisions. They price their own product with enough margin cushion to absorb a swing in either direction. They treat the current inference price as a snapshot, not a forecast, and build a product and pricing model that survives being wrong about which way it moves. That’s the real skill right now. Not predicting the cost curve, but building a product organization that doesn’t need to.

The Pricing Shift, Complicated By the Same Uncertainty

All of this bleeds directly into the customer-facing pricing question, and it’s worth being honest that the market hasn’t settled on usage-based…