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
Usage-based is definitely the direction, but I think there's a deeper shift underneath: AI agents are starting to become the paying customers, not just the tools.
When an agent can autonomously call an API and pay per invocation — no human approval loop, no credit card swipe — the traditional seat-based model breaks down completely. The billing entity isn't a human user anymore; it's a process running in a container somewhere. Your pricing UI, your auth flow, your invoicing — none of it was designed for that.
The x402 standard is trying to solve exactly this — machine-to-machine payments where an agent pays fractional amounts per API call. It changes what 'usage-based' even means.
For SaaS founders: have you thought about what your pricing looks like when one 'customer' is actually 50 agents running 24/7, rather than 50 humans who use the tool occasionally?
I'm leaning toward a hybrid model.
A predictable monthly plan makes it easier for customers to understand what they're paying for, while usage-based pricing helps cover the cost of heavier users.
The challenge is keeping it simple. If customers have to think too much about credits, tokens, or usage limits, it creates friction. My preference is to hide the complexity as much as possible and make pricing feel predictable, even if the billing model behind the scenes isn't.
I'm interested to see if hybrid pricing becomes the standard over the next few years.
I went through this exact debate. My tool has real per-run COGS (each run hits a bunch of paid APIs) so flat monthly tiers felt wrong, you either eat the cost on heavy users or overcharge the light ones. I landed on charging only when a run actually succeeds, summing the real cost, nothing if it fails. The hard part was never the pricing page, it was the metering and making 'what counts as success' airtight in code. If your per-action cost is real and variable, I'd lean usage. If it's mostly fixed infra, tiers are simpler to reason about. What does one action actually cost you?