AI Made Pricing Difficult Again

Why cheaper models don’t mean cheaper businesses—and how to fix your unit economics before they fix you

Sam Altman made an observation that should make every software founder concerned.

AI query costs have decreased significantly. Industry benchmarks suggest that GPT-4-level inference that cost around $30 per million tokens in early 2024 now runs under $5 for equivalent-capability models. Some newer models are cheaper.

But usage hasn’t stayed flat. Features that triggered one API call now trigger ten. Users who sent a few prompts a week now send dozens a day. Internal data from AI startups suggests average queries per active user have increased significantly as products added more AI-native capabilities.

AI is getting cheaper, but your bill isn’t.

For the first time in twenty years, software companies have to care about marginal cost again. Most founders I talk to haven’t fully understood what that means for their pricing, growth, and survival.

Why was SaaS pricing straightforward?

If you started a software company between 2005 and 2020, you inherited a strong economic model without realizing it.

Your costs were mostly fixed: servers, salaries, office space. Once you built the product, the cost of serving one more customer was nearly zero. A user in Tokyo and a user in Toronto cost you the same: almost nothing.

There were exceptions—video streaming, heavy compute workloads, early machine learning products. But for most SaaS, the marginal cost was minimal.

Pricing was a one-time decision, not a weekly conversation. You picked a number, tested it once or twice, then forgot about it. The goal was growth because it was safe. Every new customer improved margins. Every expansion deal made the business healthier.

That era trained a generation of founders to view pricing as a marketing problem. It was about psychology, not economics. What number converts people? What tier structure reduces friction?

Then AI appeared.

MoviePass wasn’t reckless. It was inaccurately priced.

Before discussing AI, I want to talk about MoviePass. It’s the clearest example of what happens when your pricing model ignores your cost structure.

The pitch was straightforward: $9.95 per month for unlimited movies in theaters. Customers loved it. Growth was explosive. The company looked like a rocketship.

Here’s what was happening: MoviePass was paying full ticket price to theaters for every movie their subscribers watched. The average 2017 movie ticket was around $9. A customer who saw two movies a month was costing MoviePass $18 against $10 in revenue. A customer who saw four movies was generating $36 in costs. The company was losing $26 per month on that user—and that user was the kind of engaged customer the growth team was celebrating.

MoviePass didn’t fail due to rapid growth. It failed because every additional customer worsened the business. The superfans and power users drained the company financially.

The lesson from MoviePass was “don’t be reckless.” But the real lesson is: don’t build a pricing model where demand and cost scale together while revenue remains unchanged.

That dynamic now exists in AI products, obscured by tokens and APIs.

When your best users become your biggest issue

It becomes uneasy.

In traditional SaaS, power users were invaluable. They drove word of mouth, expanded contracts, and became case studies. The customer success team loved them. Sales used them to close new deals.

In AI-native products, power users can harm your business.

Look at Replit. They charged per seat—a familiar SaaS model. But they paid per token. When usage exploded and their most engaged users leaned into AI-assisted coding, costs scaled faster than revenue. Based on public commentary and industry estimates, their heaviest users generated ten times the inference costs of average users—while paying the same fee.

The users who loved Replit most were the most costly to serve. Since it wasn’t charging for usage, there was no circuit breaker—no rate limit, tier bump, or overage charge to moderate runaway consumption. There was an expanding gap between what customers paid and consumed.

I’ve seen three AI startups with negative gross margins on their best customers. None knew until month eight. By then, they’d raised on metrics assuming those were valuable.

In AI businesses, you must know—at the unit level—whether your most engaged users are valuable or dangerous. This isn’t optional. It’s essential.

The math you need to perform.

Here’s a straightforward formula for understanding your unit economics under usage growth:

Real margin per customer = Revenue − Fixed cost per customer − (Variable cost per query × Average queries)

Three components. That’s all.

Let me walk through an example. Say you charge $50 per month. Your fixed cost per customer—support allocation, infrastructure, account management—is $10. Your variable cost per AI query is $0.02. Your average customer sends 500 queries per month.

Real margin = $50 − $10 − ($0.02 × 500) Real margin = $50 − $10 − $10 Real margin = $30

That’s a healthy 60% gross margin. Now run the same math on your 90th percentile user—the power user who sends 2,000 queries monthly.

Real margin = $50 − $10 − ($0.02 × 2,000) Real margin = $50 − $10 − $40 Real margin = $0

Your power user is break-even. If they push to 3,000 queries—which your most engaged users will—the math looks like this:

Real margin = $50 − $10 − ($0.02 × 3,000) Real margin = $50 − $10 − $60 Real margin = −$20

You’re losing $20 per month to serve your best customer.

This math destroys AI companies. The averages look fine. The tails are bleeding.

Run this calculation for three cohorts: your median user, your 75th percentile user, and your 90th percentile user. If the spread is wide, you need a pricing model that accounts for it. If your 90th percentile user is underwater, you don’t have a growth problem. You have a pricing problem.

Pricing is a system design issue.

Here’s the shift most founders haven’t internalized yet: pricing used to be a spreadsheet decision. Now it’s a strategic decision.

In traditional SaaS, the finance team owned pricing. They analyzed, chose tiers, and A/B tested a landing page. Engineering and Product didn’t need to care. Growth was a shared responsibility; margins were someone else’s problem.

In AI-native companies, that separation is eliminated.

Every feature you ship has a cost. Every “smart” capability triggers an inference. Every time you make the product more useful, you increase running costs. The engineer who adds a helpful AI assistant to your onboarding flow made a pricing decision, whether they realize it or not.

Pricing needs to be treated like architecture. Three principles help:

Meter at the value moment. Don’t just track total API calls. Track which features generate cost and value. Instrument your AI features like a payments flow—with clear attribution to customer, feature, and outcome. If your most expensive feature is also your stickiest, price around it confidently. If it has weak engagement, you’re subsidizing a feature nobody appreciates.

Cap before the margin breaks. Know the usage level at which a customer becomes unprofitable. Build that threshold into your product as a soft limit—a visual warning in the UI at 80% allocation, a “you’re approaching your limit” email at 90%, a clear upgrade path at 100%. The cap shouldn’t feel like a punishment. It should feel like a choice.

Surface usage to users. When customers see their consumption in real time, they self-regulate. A simple progress bar showing “347 of 500 AI queries used this month” changes behavior. Hidden usage breeds resentment when the bill arrives. Visible usage creates accountability.

I’ve started asking founders: can you explain, in one sentence, what happens to your unit economics when usage doubles?

Most can’t. They know their MRR and growth rate, but they have no idea about their customer-level margins or how those change with engagement.

If you can’t answer that question, your pricing isn’t a strategy. It’s a guess.

---

Pricing Your AI Product

A practical guide to models, guardrails, and the mathematics that keeps you solvent.

Now that you understand the problem, what should we do?

The five pricing models, briefly

There’s no safe default anymore, but there are choices.

The most honest model is usage-based—costs and revenue scale together—but customers hate unpredictable bills. Seat-based is familiar but risky when one power user generates more cost than fifty casual users. Subscriptions with overages balance predictability and protection, but only with trust. Credit systems give customers control and you cash flow, but collapse if they require a calculator to understand. Outcome-based pricing—charging when customers get value—aligns incentives, but requires clear attribution and mutual trust that most early-stage companies can’t establish.

Most founders end up with a hybrid. Here’s one that works.

A pricing pattern to imitate.

Base subscription, included usage, and overage charges.

Start with a monthly subscription that covers a defined usage allocation. Make it generous enough that 70-80% of users never exceed it. This gives most customers predictability and a stable revenue baseline.

Set a clear cap. Notify users in-product when they approach it, not via an unexpected invoice. Show a usage meter in the dashboard. Let them see their real-time allocation consumption.

Charge overages at a clear upfront rate for the 20-30% who exceed the cap. Put it on the pricing page and signup flow. No surprises. The rate should protect your margins but not feel punitive.

Here’s what this looks like:

“$99 per month includes 5,000 AI queries. Additional ones are $0.03 each. Your usage dashboard updates hourly.”

Predictable for most users, protected for you, clear for everyone.

One additional guardrail to consider is automatic plan upgrades. If a customer consistently exceeds their allocation, prompt them to move to the next tier at a per-query rate. “You’ve exceeded 5,000 queries three months in a row. Upgrade to Pro for 15,000 at a lower rate.” This converts your heaviest users into your highest-paying customers instead of your most costly problems.

Where this goes awry

Companies implement the structure, but they hide the dashboard, obscure the overage rate in fine print, or set the allocation so low that 60% of users hit overages in month one.

The model only works if visibility is real, not cosmetic. Customers should never be surprised by what they owe. If they hit overages, they should know why, when, and how much. If they feel tricked, you’ve lost more than margin—you’ve lost trust that takes time to rebuild.

Three questions you can’t delegate.

Pricing strategy boils down to three questions only you can address.

Does your pricing match your cost structure? If you’re paying per token and charging per seat, there’s a mismatch. Mismatches can work for a while, especially with low usage. They become problematic at scale.

Are you charging for value or mechanics? Customers don’t care about tokens. They care about problems solved. Consider creating a “unit map” that converts internal mechanics into customer-facing concepts: “one document analyzed,” “one call summarized,” “one lead scored.” Charging per lead scored beats charging per API call if you can make the economics work.

Does your pricing prioritize predictability or fairness? Usage-based pricing is fair but unpredictable, and CFOs dislike unpredictability. They will forgive inefficiency but not surprise.

Circuit breakers matter—they’re not restrictions. They’re the mechanism for predictability without unlimited downside: rate limits, soft caps, automatic tier upgrades. For enterprise sales, you need a pricing model that lets buyers forecast their spend: annual commits with defined usage caps, quarterly true-ups, or monthly buffers that roll over unused allocation.

What to do this week?

Pull the last 90 days of API costs. Segment by customer. Identify the most expensive user.

Run the unit economics calculation for your median, 75th percentile, and 90th percentile users: revenue minus fixed cost minus (variable cost × queries).

Is your 90th percentile user generating profit?

If your highest-cost customers are generating positive margin, you’re fine.

If you don’t, you have a pricing problem. No amount of fundraising or growth strategies will fix a model that loses money on every incremental power user.

You have four levers: raise your price, reduce included usage, add overage charges, or gate the costliest features behind a higher tier. Start by quantifying the gap, then work backward to the smallest change that closes it.

Note: this exercise assumes you have API costs segmented by customer. If not, your first task is to do that. Even rough approximations—sampling heavy users, estimating based on feature usage—will reveal problems that aggregate metrics hide.

This takes two hours. It is the most important two hours this quarter.

The rule

MoviePass collapsed because it ignored unit economics for growth. AI startups are making the same mistake, just slower and quieter. The losses hide in API bills and margin compression, not tabloid headlines.

If cost scales with delight, then price must scale with delight.

Analyze your power users this week. The remainder is execution.

---

What pricing model are you using? What’s working, what’s not working? Reply—I’m collecting real examples for a follow-up piece.

---

Did this post resonate with you? If you found value in these insights, let us know! Hit the 'like' button or share your thoughts in the comments. Your feedback not only motivates us but also helps shape future content. Together, we can build a community that empowers entrepreneurs to thrive. What was your biggest takeaway? We'd love to hear from you!

Interested in taking your startup to the next level? Wildfire Labs is looking for innovative founders like you! Don't miss out on the opportunity to accelerate your business with expert mentorship and resources. Apply now at Wildfire Labs Accelerator https://wildfirelabs.io/apply and ignite your startup's potential. We can't wait to see what you'll achieve!