A feature that costs $150 a month in beta can cost $4,000 a month once real customers are on it. A vendor swaps its default model overnight, and a customer's bill triples without a single change on the customer's side.
AI decisions are pricing decisions.
Any choice that changes what a customer pays for the same outcome is a pricing decision, and in an AI product, nearly every engineering choice qualifies. Every model swap, every prompt change, every new feature, every workflow tweak shifts your unit economics. Sometimes the shift comes from things outside your control, and sometimes it's just the inherent nondeterministic nature of AI. Either way, most companies cannot tell you by how much.
The pricing conversation has become the most ambiguous part of an AI investment that is otherwise run with rigor. That's not a small gap that can keep being ignored. It's the gap that's festering.
A shift no one priced for
For two decades, the SaaS pricing model assumed a stable consumer: a human, sitting at a dashboard, clicking. Cost-to-serve was bounded by what a human could do in a day, and seat pricing worked because seats were a proxy for that bound.
That assumption is now wrong, and most products are still priced as if it were true.
The new consumer is an agent acting on behalf of a human, and the agent does the expensive preparation work. It calls APIs, runs CLIs, and queries MCPs (Model Context Protocol servers that expose tools to agents). Sometimes that agent belongs to the provider, sometimes to the customer. Either way, the customer consumes the outcome.
This isn't the future. This is 2026. Every customer support AI drafts responses a human verifies and sends. Every sales AI prepares lists of humans to reach out to and the copy to use. The hybrid pattern exists already.
The granular cost per customer driving each of those outcomes is far less clear.
The cost shape that broke the model
Picture a customer support AI product. The vendor rolls out a quality improvement: better reasoning, sharper sentiment analysis. Resolution accuracy moves from seventy-five percent to eighty-five percent, a real product gain. The token consumption to deliver each resolution doubles.
Now consider the customer. Their support queue didn't grow. Their behavior didn't change, their staff didn't change, their workflows didn't change. Yet the bill doubled.
A few days before the cycle closes, they get a notification that they're near their limit, too late and too vague to act on. They can't tell why the bill went up, or whether this is a spike or the new baseline. They're not pricing-fluent, and frankly, they shouldn't have to be.
So who pays for the difference?
In every AI product priced per token, the answer is the customer. The vendor improved quality, the provider charged more for the better reasoning, the vendor forwarded the difference, and the customer absorbed it. A product improvement arrived as a billing surprise.
Vendors across the AI software industry are doing this right now: running quality experiments, swapping models, tuning prompts, expanding context windows, adding retries. Each of those is a pricing decision the customer never consented to. The customer is eating the cost of someone else's reckless adoption of AI.
Cursor learned this the hard way. When it switched its Pro plan to token-based billing in mid-2025, users who budgeted $20/month saw invoices hit $60 to $100, and one five-person team spent $4,600 in six weeks. The customers hadn't changed their behavior. Cursor had changed its math, and the customers absorbed the difference.
And the customer can't walk away, because the feature is now load-bearing for their business. So they pay. They expense the surprise bill, post a review that says the pricing is opaque, and tell their network. Next quarter the bill spikes again, and the renewal conversation gets more skeptical.
This is how trust compounds in the wrong direction. The customer hasn't yet churned. The reputation has.
The pricing model that breaks centuries of business practice
Step back and look at this structurally. For most of commerce, when you buy something, the price is known before the transaction. A rubber ducky costs ten dollars. You buy a hundred ducks, pay a thousand dollars, paint them, sell them in your store for thirty each. The math works. The business works.
Usage-based AI pricing breaks that contract. Today's rubber ducky costs ten dollars. Tomorrow's costs a hundred, because a caching issue spiked the token usage required to deliver "one ducky." The duck is identical. The price is ten-times-higher because of something happening inside the vendor's infrastructure that the customer has no visibility into and no agency over.
Now try to run a store on that, setting retail prices on painted ducks while the wholesale duck price swings ten-times week to week. You can't. The input cost isn't a price anymore. It's a roulette wheel the vendor spins on a schedule you can't see.
The same thing happens up the supply chain. A woodcrafter buys raw materials from a producer, and the wood arrives at varying prices. The variance isn't supply and demand. It's decisions inside the producer's workshop that the woodcrafter never sees. The producer might call this "transparent pricing" because every gram of wood is metered and itemized, but to the woodcrafter, transparency without consistency is a tax dressed up as a meter. The producer's internal decisions become the woodcrafter's external margin problem.
Centuries of commerce solved this by stabilizing the unit of trade. You buy a ducky for ten dollars, a board-foot of oak at six dollars, a kilowatt-hour at fifteen cents. The unit is known, the price is known, and the buyer can build a business on top of it. Per-token AI pricing reverses that. The unit floats. The price floats. The customer absorbs the float.
That's why this has to change. Companies building AI products need per-customer pricing transparency that delivers consistency: the vendor takes on the variance internally, and the customer sees a stable price for the outcome they care about. That's the goal.
Customers don't want transparency. They want consistency.
Half the pricing industry is selling transparency as the answer: per-token meters, real-time dashboards, line-item invoices. None of that is what the customer actually wants. The customer wants a bill stable enough to budget against. Think about how you'd feel if your electric bill came with a per-electron line item. You wouldn't feel informed. You'd feel taxed.
Token pricing is the vendor's unit of measurement sold to the customer as if it were their own. Easy for the vendor, because tokens are how the provider bills them. Hard for the customer, who has to do conversion math to figure out what they actually bought. And when the vendor's model changes shift that math, the customer can't tell whether they got a worse deal or a different product.
Consistency is what trust is built on. A customer who can predict next quarter's cost trusts you. A customer who can't is shopping for an alternative even when they like the product.
The two models split cleanly:
| Pricing model | Who absorbs the variance? | Customer can budget? | Vendor IP exposure |
|---|---|---|---|
| Per-token | Customer | No (token-to-outcome ratio is unstable) | Required for any real transparency |
| Per-outcome | Vendor | Yes (price per resolved ticket, drafted brief, etc.) | Stays internal |
There's also a reason most vendors don't provide real transparency into how tokens are spent: it would expose the workflows that make the product good. The prompts, the retry logic, the context strategies, the model selection rules: these workflows are the product, and they're the IP. A customer who can see how each token was used can reverse-engineer most of how the product works.
So per-token pricing forces an impossible choice. The customer experiences opacity as risk transfer, the vendor experiences disclosure as IP loss, and there's no middle ground at the token layer. "We'll add a better cost dashboard" doesn't solve this, because the unit of measurement is the IP itself.
Outcome pricing dissolves the paradox. The unit becomes a plain-language customer-facing artifact: a resolved ticket, a drafted email, a qualified lead, a generated brief. The cost to produce that outcome stays opaque on the vendor side, where it belongs. The customer gets consistency, the vendor keeps the IP, and it's the only model I've seen that satisfies both parties.
Who absorbs the variance?
Every AI pricing model should pass one test. When your product decisions shift cost, who absorbs the variance?
If you change a model and your customer's bill goes up, that's risk transfer. Not pricing.
If you tune a prompt that adds tokens and your customer's bill goes up, that's risk transfer. Not pricing.
If your workflow improvement adds retries and your customer's bill goes up, you can say it with me by now. Risk transfer.
The product mistake belongs to the builder. The bill shouldn't.
This is the integrity test, and the fairness test too. A builder who absorbs variance is acting in good faith. One who passes it through is asking the customer to insure the builder against its own decisions. That's not a pricing model. That's a transfer of risk dressed up as a meter.
The same decision from three seats
That test sounds abstract, so let me put it at three desks.
A product manager ships a deep-research mode. Adoption climbs. What her dashboard doesn't show: cost per generated brief moved from $0.08 to $0.31, and the flat-rate Growth tier now costs more to serve than it bills for the heaviest accounts. She hears about it from finance, six weeks later.
An engineer rewrites a retrieval prompt and trims average context from 12,000 tokens to 7,000. Cost per resolved ticket drops about 35 percent while quality holds. It might be the best pricing decision the company makes all quarter, and nobody logs it as one.
Before a board meeting, a finance lead gets asked for gross margin by customer segment. She has provider invoices and a Stripe export, so she reports one blended number: 61 percent. Whether the largest account runs at 80 percent margin or 12, she can't say.
Same product, same month, three pricing decisions. None of them measured as pricing decisions.
What builders need to do
The way out has three parts, and each one depends on the one before it.
Price the outcome, not the work
What does your customer actually buy? A resolved ticket, a drafted email, a built dashboard, a qualified lead, a generated brief, a completed workflow. That's the unit. Price that. The variance in producing it is your problem to manage, not your customer's.
Own the margins
Pricing the outcome only works if you know what each outcome costs to produce under current model conditions, and how that cost is moving over time. Owning margins also means absorbing the variance from your AI decisions on your own P&L (profit and loss), and saying no to product decisions that would compromise unit economics, even when they'd be otherwise interesting.
Instrument the pricing impact of every AI decision
And you can only own margins you can see. This is the part almost nobody is doing. When you swap a model, your dashboard should show you the per-outcome cost shift across every customer segment. When you tune a prompt, you should see the cost-per-completion delta. When you launch a feature, you should know which outcomes it added and what each one costs to produce.
Without that instrumentation, you're running an AI business by intuition. That's the same as running it blind.
The market has spent eighteen months arguing about which pricing model is right: seats, usage, credits, outcomes. The answer is downstream of one decision. Are your customers going to pay for the variance of your AI decisions, or are you?
If your answer is "the customer," you're not in a pricing conversation. You're in a risk-transfer conversation.
Why I'm writing this
I'm building Bear Lumen because the instrumentation layer I just described exists in disjointed forms and is largely incomplete.
Billing platforms like Lago, Metronome (now part of Stripe), and Orb capture the wallet. They tell you what to invoice, but not what each invoice cost you to deliver. Observability platforms like Helicone, Langfuse, and Arize trace per-request cost. They tell you which API call cost what, but not which customer outcome that call was producing. There's no single tool for product, finance, and engineering to come together on, and the gaps between the existing ones are exactly where the margin questions live.
Industry voices like Anh-Tho Chuong at Lago, Steven Forth on pricing innovation, and Rob Litterst at Good Better Best each describe a piece of the same elephant from different angles. Almost none of them have named the underlying problem this directly: the customer is paying for the vendor's product decisions, and the unit of measurement (the token) is also the IP. No amount of "better transparency" changes that.
Bear Lumen measures cost-to-serve outcomes for your users, products, and features. Not just tokens, not just requests, not only traces. The cost of producing each thing the customer actually values, attributed to the customer who consumed it, grouped by the product or feature that produced it. The dataset everyone's been pricing against without ever measuring it.
That's the instrumentation layer. It's the prerequisite for outcome pricing, which is the prerequisite for the kind of accountability this post is arguing for.
Your AI product decisions are pricing decisions.
Are they benefiting your customer, or hurting them? Are you making them with integrity and fairness? Are your customers actually happy with the way you're pricing your product?