Is usage-based pricing becoming the norm for AI tools?

We're sticking with a flat free tier + flat paid tiers for now, mostly because our buyers (compliance teams) need predictable budget lines, not metered surprises. Usage-based makes sense when the buyer is technical and comfortable estimating their own load. Compliance buyers are the opposite, they want a number they can put in a budget line and not think about again.

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’m leaning toward a hybrid model because AI products have real variable costs, but customers still like the predictability of a subscription.

A base monthly plan can cover access, storage, memory, integrations, and core features, while credits or usage pricing handle the expensive actions. That keeps pricing easier to understand without forcing the company to absorb unlimited compute costs.

Running local models can also help depending on the size and needs of the project. Smaller or repetitive workloads can sometimes be handled locally, while larger models are reserved for tasks that require stronger reasoning or higher-quality output. That gives you more control over margins and reduces dependency on a single provider.

For me, the best model is usually subscription plus included usage, with transparent overages rather than purely usage-based pricing.

I think sadly it will become the norm, with alot of AI tools using API calls, rate limits and credit usage will probably be the one gating the tool itself, hence the need for usage-based pricing.

One thing that doesn't come up much here because most of this is web SaaS: on mobile, Apple and Google's own subscription APIs don't really support metered usage billing at all. So "fixed sub plus usage-based for the AI feature" isn't just a pricing philosophy on mobile, it's also a platform constraint. You end up doing app store tiers for the base product and rolling your own consumption tracking server-side for anything AI heavy, which becomes its own reconciliation problem since the store has no idea your usage numbers exist.

real friction with usage pricing is user paying for model mistakes. mid-task agent lost context and rebuilt helper that already existed two files away with new name) when you bill per token for context amnesia every bug feels like user is subsidzing bad memory

Pure usage is painful when you pay for the amnesia of the model. Mid task the agent lost the context. And it rebuilt a helper that was already there two files away under another name. Plus you pay for all the toknes it wasted duplicating your own codebase )

the thing usage pricing does to an agent product that it doesnt do to ordinary saas is change when people stop. on a seat price a user lets the agent try again. with a meter visibly running they kill it early and finish by hand, and then they conclude the agent just isnt very good. ive watched myself do exactly this. the moment i can see a number moving i start supervising instead of delegating, and supervising is the expensive mode for me and the useless mode for the thing im paying for. so if the cogs genuinely force metering, the bit id protect is the retry. price the outcome, or fold a generous retry allowance into the base, so the user never has to sit there deciding whether this particular attempt is worth it. i think thats the real argument for the hybrid you mentioned, more than revenue smoothing is.

Dansaki's answer is the one I would build on, and I would add one turn to it. Visibility and control matter more than the label on the plan, and before asking how usage is displayed I would ask which event the bill is attached to. For most AI tools that is already settled, since the expensive event is the model call, so caps and alerts are the right instrument there. My own case is the odd one out. I run usebravery.com, where the product is a prebuilt watch affiliate site, so this is the cost shape I have to price against. Every customer gets their own dedicated instance, so a busy site costs no more than a quiet one. What moves the variable side is the catalog growing. On my own site that is one narrow category, 975 products, roughly 950 live links per market. Since the number only moves when someone deliberately adds a product, a customer can see what a month will cost before it starts. Caps still matter, but they stop being the first line. Has anyone managed to attach the counter to something other than the call in an actual AI product?