Is usage-based pricing becoming the norm for AI tools?
Hey everyone,
I've built my product around traditional SaaS pricing (monthly tiers), but I’m starting to wonder if that model is getting outdated, especially with more AI-powered and compute-heavy tools entering the market.
That shift requires real architectural changes, instrumentation, metering, billing logic, and UI changes, not just pricing tweaks. It’s something I’m starting to seriously think about for my own product.
In particular, AI usage has real COGs (every prompt costs money), and I’m seeing more platforms experimenting with usage-based models, or hybrids like “SaaS base + usage + overage.”
For those of you building AI or compute-intensive tools:
Are you sticking with SaaS pricing?
Have you considered switching to usage-based or hybrid models?
Is it helping or hurting conversions?
Would love to hear what others are doing and whether you're seeing buyer preferences shift, too.
Replies
I’m seeing more teams move toward a hybrid model rather than pure usage-based.
A flat SaaS base helps buyers feel anchored and predictable, while usage pricing makes sense for AI-heavy features where COGs spike. Pure usage can scare non-technical buyers if it’s not tightly scoped.
What’s made the biggest difference from what I’ve seen isn’t the pricing model itself, but how visible and controllable usage feels (clear limits, alerts, and caps). When teams can’t predict spend, churn follows quickly.
Curious how you’re thinking about guardrails if you do go usage-based.
@dansaki_samuel Thanks for affirming, I will say that the comments in this thread make me feel a bit more comfortable rather than jumping the gun and going all in on usage billing only.
And that is is a great point on putting the right guardrails on the platform to communicate when an overage may be occurring.
Totally agree — it’s not the model, it’s the perceived control.
Even if I go hybrid, I’d prioritize hard caps, real-time alerts, and a “pause if over budget” toggle.
No one wants surprise bills, especially when every token costs real money 😅
@zypressen when you are a prosumer or consumer paying the bill from your own funds, the shock can be rough and you might have regrets. But at least you both racked up the bill and have to pay the bill.
Now consider how it goes when you're an end user who works in a business where you do not have the final say on budgets...can't autonomously approve new spend. Now you have to hand that surprise bill to your boss or stakeholders and explain how and why it happened and how you'll ensure it won't happen again. That's 10x worse than when you eat it yourself.
Exactly. When it’s your own money, you learn fast.
But in a team? That surprise bill isn’t just a cost — it’s a credibility hit.
That’s why guardrails like hard caps and auto-pause aren’t “nice-to-have” — they’re non-negotiable for orgs.
Triforce Todos
This is one of those decisions that looks small but touches the entire system, pricing, UX, and infra.
@abod_rehman yup, the more I dig into it the more I realize it. This realization is what made me want to socialize to the broader community.
Meteroid
Switching to pure usage can be scary due to lack of predictability. A hybrid model (Base + Overage) is often the sweet spot: it secures your baseline while offering an accessible entry point. With the relevant threasholds, it boosts conversions by lowering the barrier to entry.
The keys to avoiding "bill shock" is (i) choosing the right Value Metric and (ii) transparency. If your billing unit (tokens, API calls or anything else) follows perceived value and you provide real-time visibility to your users, friction disappears.
Indeed, that shift requires real architectural changes in terms of metering, billing logic etc. That's why we're launching Meteroid on PH (hopefully next Thursday) to solve this: an open-source engine that unifies metering and billing so you can swap pricing models without rewriting your backend.
If you want to further discuss your use case, feel free to reach out directly to me at donatien[@]meteroid.com
@ddu Yeah I agree, I've heard stories of people not charging properly and ending up with multi-thousand dollar integration bills.
Thanks Donatien, and congrats on your product launch, what has your strategy been to prepare for it?
Meteroid
@jake_friedberg, thanks! Well, honestly, it's my first launch and it's not always easy to understand what drives a successful launch. Basically, we focused on:
adapting our story to builders (I think it's the majority of folks in PH), highlighted our specificities and launched a specific "visionary" plan a few weeks ago to make it a no-brainer for people starting out.
pitching a few active hunter who care about open-source, dev tools or growth hacking to see if they’d be willing to support us
engaging with the community
We'll see if it works ;)
@ddu solid plan and good look - I'll be following along and rooting for you! Check out my project One Pager if you get a chance as well!
https://one-pager.io
Been thinking about this a lot while building a PM platform ... my opinion: architecture matters more than trends.
If your product works fine without AI (but AI makes it faster/smarter), stick with SaaS tiers. Usage-based makes sense when AI is the product, not when it's an accelerator.
The "credit anxiety" is real ... I really hate watching meters on everyday tools.
What seems to work:
SaaS tiers with generous AI quotas included
Soft caps (nudge to upgrade, not hard blocks)
Usage-based only for heavy compute stuff where the value is obvious
The test: Remove AI tomorrow – does your product still work?
Yes → SaaS pricing
No → probably need usage-based
For B2B especially, predictable costs -> perfect unit economics. Finance teams need fixed budgets ;)
vibecoder.date
Saas subscriptions were appealing because they offered predictable billing. But fixed costs were known and variable costs scaled predictably too. Pricing was easier to model.
Unless you own your AI infra you can't do that anymore without heavily investing into analytics to determine price viability, or hedging by raising prices.
Usage based pricing starts to make sense with AI and agentic work, but it's not as easy to adopt as we think.
Neither is a system of buying credits every month. When workloads vary so much it is hard to know how to accurately price.
I see this playing out two ways.
A) MSP style, managed service provider, owns the vertical, bills on outcomes.
B) Baseline allowance + overage. With incentives to take advantage of off peak hours.
@build_with_aj interesting and what you mentioned about it not being as easy to adopt as we think is exactly what spurred this question in the first place as we'll all be facing the reality of turning around our SaaS pricing ships to keep out products and services competitive in today's landscape.
I'm beginning to think about this now as there are architecture, business, and process ramifications.
We recently introduced generative voice and video into our Camtasia bundled subscription plans while retaining a traditional SaaS pricing model. Why?
Sticking with the SaaS model helps us differentiate from competitors by offering unlimited AI under a very clear, predictable, easy-to-explain model.
Some competitors have built not just one but two credit currencies (core feature use credits + AI credits) that their end users have to learn, navigate, and explain to their approvers. We think video creation is demanding enough without needing to learn and master the game of how to conserve credits. That's all noise and friction that has nothing to do with video creation.
With inherently creative applications like Camtasia, we believe there's another more subtle benefit: unlimited AI frees end users to play around and try out various AI capabilities to decide whether and how to evolve their video creation workflows...rather than clutching their credits for fear of running out. We believe this kind of creative experimentation leads to better outcomes for our users.
The simplicity and predictability of standard SaaS pricing is also valued by our enterprise customers who really don't like surprise bills or extra invoices and POs to manage.
It's possible that our company is in a bit of a unique position due to our customer base being large, established, very horizontal, and more heavily enterprise-oriented than the typical startup. Within our broader product portfolio, AI capabilities are additive...so are not used by every user every time they use our products. All of which means we can absorb the spikes and trust the law of averages when it comes to costs.
I love this question and I think every software maker is asking it right now. I think there's a real risk of putting the profitability cart in front of the user experience horse.
Meteroid
@dpfoster Unlike traditional SaaS, AI has high marginal costs. In an unlimited model as you described, the top 5% of users can consume 80% of your AI costs. Basically, you are essentially using margins from casual users to subsidize power users, who really find value in your product and don't pay for that.
Moreover, without a usage link, curious to know how you preserve margins if a feature goes viral.
@dpfoster thanks for the comment, I was a big Camtasia and Snagit user in a previous role when I was creating training videos.
It’s been interesting to hear how AI has made its way into these products as well. I agree that credit-based pricing can quickly become confusing, especially when working with multiple vendors who structure credits differently. Most customers simply don’t want to think about usage mechanics unless they absolutely have to.
@ddu and yes, as I’ve mentioned in a few replies below, there’s definitely risk around AI usage spikes. That said, even companies like OpenAI and Claude are still sticking with standard SaaS-style pricing models, likely after observing the same dynamic you mentioned (where a small percentage of users drive the majority of compute costs).
As more modalities emerge that are cheaper to run than the latest frontier models, we may see approaches similar to what service providers do when usage exceeds thresholds — for example, “unlimited” plans that introduce throttling after a certain point (like mobile carriers slowing speeds after ~22GB of usage).
Meteroid
@jake_friedberg exactly even if OpenAI offers subscritpion-based plans to retail customers, unlimited access is subject to abuse guardrails.
I’ve seen more AI tools moving towards usage-based pricing, especially when compute costs scale up quickly. It’s definitely more accurate and fair, but I do wounder if it impacts long-term user retention. The predictability of monthly SaaS models can be a big draw for customers.
@olive_loren the feedback of the comments section suggests there is plenty of interest in keeping MRC pricing with usage as an add-on. Which tools have you seen using purely as usages, have any of them gone through the change transitioned from MRC?
Trophy 1.0
Not just AI tools, we've been usage-based from day 1. Lots of tools that serve consumers in particular also have naturally spiky usage patterns and so paying a fixed cost usually overcharges most customers.
We have a couple of tiers all with a low base price with overages based on usage.
Also note that volume discounts come into effect for tools like us, but not seen examples of this paradigm in any AI tools yet.
@charlie_hb interesting, and your website looks great. What type of volume discounts do you offer? I suppose in order to do that you really need to understand your compute costs.
Trophy 1.0
@jake_friedberg We reduce the per-user cost above 100K users, then above 1M too. Really just passing on our savings from economies of scale, compute costs per user lower with more users. So we find its a good model where everyone wins.
Pretty Prompt
Hey! We went for a simple approach: Monthly/yearly subscription with 2 options:
- Lite plan (100 prompts)
- Pro plan (unlimited)
I'd rather give more value today, than capping too much the tool with usage-based tiers.
Though probably we'll experiment with that soon as well! It's till a very interesting area for us at @Pretty Prompt
For context, Pretty Prompt is a Chrome Extension that works like Grammarly, but for prompting. Improves prompts in one click inside ChatGPT, Claude, Gemini, etc.
@ilaiszp thanks for your feedback here and I remember seeing Pretty Prompt as a featured product, so its cool to have you comment on the thread!
I like your pricing, its very easy to understand and doesn't gate the user. Is this something you've applied to the other products you've launched? Honestly I'd love the chance to discuss more some lessons you've learned along the way if you'd be open to it?
Pretty Prompt
Coming from a UX background and now building an AI startup, I think we often overlook the trust factor. For an early-stage product, asking users to commit to a purely usage-based model can be a hard sell. They don't know your brand yet, and 'pay-as-you-go' introduces a lot of cognitive friction—people hate not knowing exactly what they’ll pay at the end of the month.
That’s why the hybrid model feels like the sweet spot for startups in beta. It builds trust through a predictable subscription while acting as a safety net for the company once tokens are exhausted.
I'm curious—for those of you who tried hybrid vs. pure usage, did you see a difference in user retention? Do users actually prefer the 'safety' of a sub, or are they starting to demand more flexibility in the AI era?
@valeriia_kuna thanks for commenting! I’m seeing a mix of approaches across companies right now. Personally, I’d much rather pay straightforward SaaS pricing than deal with unpredictable, bloated usage charge, especially for products where AI is either core to functionality or something I need to use regardless.
It also looks like you’ve worked on quite a few projects, which one are you spending most of your time on right now?
On your point about trust, that’s exactly what my company One Pager aims to support. Customers increasingly want to know the people behind the product, and we’re building around that idea.