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 pricing the way some early commentary predicted.

Per-seat pricing was built for a world of predictable, bounded service cost. That's a clean mental model for a customer's finance department. They know exactly what next month's bill looks like, budget it once, and forget about it. Usage-based pricing breaks that model, and it turns out most buyers still don't love it. Look at what's actually shipped: the dominant AI products in market, from coding assistants to general chat tools, mostly still sell flat-rate subscriptions with usage caps or credit pools, not raw metered billing. Companies have largely chosen to absorb the cost volatility internally rather than pass the anxiety onto the customer, precisely because that volatility is so hard to predict right now. If your own cost basis might swing fivefold in either direction over the next two years, handing that uncertainty directly to a customer's monthly bill is a hard sell.

That doesn't mean usage-based pricing is going away. Heavy, high-volume, clearly billable workflows are still moving that direction, especially at the API and platform layer. But for most end-user-facing products, the near-term answer looks like generous flat allowances with metered overages at the edges, not wholesale exposure of the meter to the user.

Designing for Usage Anxiety

Put yourself in the shoes of the end user, not the buyer signing the contract, but the person actually using the product day to day. Under per-seat pricing, that person never thought about cost. They used the tool as much as they wanted because the bill didn't move. Their only job was to get value out of the software.

Wherever usage-based elements do show up, even inside a flat plan with overages, every interaction can carry a faint, background question: is this going to cost my company money? Am I going to get an email from IT about overage? Did I burn through this month's allotment because I asked the assistant to redraft something for the third time?

That's a genuinely new kind of friction, and it's a product design problem, not just a pricing model problem. If your users are quietly rationing use of a feature because they're worried about cost, you've built a product that discourages the exact behavior you're trying to encourage. The best teams I've seen handle this with real transparency. They show users where they stand relative to their usage allowance, in the product, in real time, not buried in a monthly invoice. They give predictable, generous baseline usage so everyday, high-value interactions feel free, and reserve metering for genuinely heavy, power-user behavior. They avoid UI that silently triggers expensive model calls behind an innocuous-looking button. If a click costs real money at scale, the experience should make the value of that click obvious, not disguise it.

This is exactly the kind of judgment call that separates product management from feature delivery. Anyone can ship an AI button. It takes real product thinking to design the economics and the experience around that button, so neither the company nor the customer ends up resentful, and to do it in a way that still works if the underlying cost moves significantly in either direction over the next year.

What This Means for How Product Teams Operate

A few practical shifts I'd encourage any product leader to make right now, given the uncertainty rather than despite it.

Put cost per interaction on the same dashboard as engagement and retention, and revisit it monthly rather than annually. This is a fast-moving number, and product shouldn't be the last to know it moved.

Build model and vendor flexibility into your architecture from the start. Being locked into a single provider's current pricing is the biggest way to turn cost uncertainty into an existential risk instead of a manageable one.

Get engineering, finance, and product genuinely in the room together, early, not after a feature has shipped and costs have already surprised everyone. Model selection, caching strategy, and fallback logic are product decisions now, because they directly determine unit economics and which pricing model is even viable.

Price your product with a real margin cushion, not margin that only works if inference costs keep falling on schedule. Treat any pricing model that depends on continued cost deflation as a bet, and know that you're making it.

Protect the end user from raw cost exposure wherever you can. Generous allowances and clear, in-product usage visibility build trust. A meter ticking in the background while someone tries to do their job does not, and it doesn't matter whether that meter reflects the true cost or a temporarily subsidized one. The anxiety is the same either way.

Be honest with yourself about which AI features are genuinely worth the marginal cost versus which ones are AI for the sake of a press release. Not every workflow needs a large model call. Discipline here is a competitive advantage, because competitors who aren't exercising it will eventually be forced to raise prices or degrade the experience to cover their costs.

The Real Shift

For most of the SaaS era, product management could treat cost as an operational detail handled downstream, because the ground underneath it wasn't moving. AI has moved cost upstream into the product decision itself, at exactly the moment when the ground beneath it is moving the most, with falling model efficiency pulling costs down and platform subsidies quietly masking the fully burdened costs. Nobody, including the people running the model companies, can tell you with confidence which force wins over the next two years.

That's uncomfortable, and it's also the honest state of play. The teams that pretend otherwise, whether by ignoring cost entirely or by making a confident bet on where it's headed, will be surprised. The teams that build for the uncertainty with flexible architecture, real margin, and a product experience that shields the end user from volatility they didn't sign up for, are going to be the ones still standing when the picture finally clears up.

If you're building an AI-powered product today and you can't say what an interaction costs you, or your plan only works under one version of where that cost goes next, that's worth fixing before you ship the next feature, not after.