Pay for What You Use: The Rise of Consumption Pricing

Not long ago, software pricing was simple. You bought a licence, you got the software, and the bill was the same every month whether you used it every hour or left it gathering dust. Predictable, maybe a bit wasteful, but easy to budget for.

That model is quietly being replaced. A growing share of the tools businesses rely on now bill by what you actually consume: compute seconds on Snowflake, messages sent through Twilio, API calls to an AI model, gigabytes transferred through AWS. For many services, the meter runs only while work is actively being processed. For others, such as a Snowflake virtual warehouse, it keeps running until the service auto-suspends, so idle time still costs money.

This shift has a name. Consumption pricing. Usage-based billing. Pay-as-you-go. Whatever you call it, it changes the relationship between what you pay and what you get in ways that are sometimes genuinely good and occasionally genuinely alarming.

How metering actually works

At its core, metering is just measurement. The vendor instruments their platform to track a unit of consumption, and your bill is that unit multiplied by a per-unit price.

The tricky bit is choosing the unit. Vendors pick one that correlates closely with the value you receive and that is difficult to game. A few common patterns:

• Compute time: AWS Lambda charges per millisecond of execution. Snowflake charges for virtual warehouse credits per second the warehouse is running, including any idle time after a query finishes until the warehouse auto-suspends. You pay for the warehouse being on, not just for the moments it is actively processing.
• Volume: Twilio charges per SMS sent or per voice minute. Stripe charges a percentage of each transaction. Postmark charges per email delivered.
• Tokens: OpenAI, Anthropic and most other AI providers bill per token, a rough proxy for text processed. Input tokens and output tokens are typically priced separately, with output costing more because generating text is computationally heavier than reading it.
• Seats plus usage: Some tools blend both. A base platform fee covers access, and consumption tiers kick in above certain thresholds. Vercel does this with bandwidth and build minutes.

The metering infrastructure behind all of this is non-trivial. Vendors track events in real time, aggregate them, apply pricing rules, and surface the totals in dashboards. When it works well, you can see exactly what is driving your bill. When it does not, you are left squinting at line items you do not recognise.

Why vendors love this model

From the vendor's side, consumption pricing is close to ideal. Revenue scales with usage, which means their best and most active customers automatically pay more without anyone having to renegotiate a contract. Growth is sticky. A customer who has integrated your API deeply is not going to switch easily, so increasing usage tends to translate directly into increasing revenue.

It also lowers the barrier to entry. A startup that sends a hundred messages a month pays almost nothing. When it grows to sending ten million, it pays a lot. The vendor gets to claim "start for free" while knowing the big accounts will come eventually. The pricing model does the upselling automatically.

There is also a margin argument. With flat subscriptions, a heavy user and a light user pay the same amount, but the heavy user costs the vendor significantly more to serve. Consumption pricing shifts that cost directly onto the customer generating it. From a unit-economics perspective, this is cleaner.

Where it genuinely is fairer

The criticisms of consumption pricing are real, but it is worth being honest that the alternative has problems too. A flat subscription often means you are paying for capacity you do not use. A team that runs one batch job a week on a data warehouse does not want to be paying for a dedicated instance sitting idle the other six and a half days.

Pay-as-you-go levels the playing field for smaller businesses. A solo developer experimenting with an AI API does not need to commit to a monthly spend before they know if the thing even works. The cost of exploration drops dramatically. That is a genuine benefit, not just marketing copy.

For workloads with spiky or unpredictable demand, consumption pricing also removes a real planning headache. You do not need to forecast usage twelve months in advance and then overprovision for peak loads. You just run, and the bill reflects reality.

The bill-shock problem

Here is where things get uncomfortable.

The same property that makes consumption pricing flexible (costs rise with usage) makes it dangerous when something unexpected happens. A misconfigured loop hits an API endpoint ten thousand times overnight. A viral moment drives traffic you were not expecting. A developer leaves a background job running against an expensive model. The bill arrives and it is nothing like the figure you had in your head.

This is not theoretical. Engineers share stories of AWS bills that jumped from tens of dollars to tens of thousands because of a single misconfiguration. AI API costs can accelerate quickly when prompts are verbose and the response requirements are generous. Snowflake's compute credits can drain fast if a query is not properly optimised or a warehouse is left running.

The problem is compounded by billing cycles. Many platforms aggregate usage and charge monthly. You might not see the damage until weeks after it happened, by which point the runaway process has been running for a long time.

A few practical ways to protect yourself:

• Set spending controls wherever the platform offers them. Most major cloud providers and AI APIs provide budget alerts and monitoring dashboards. Use them. Be aware, though, that an alert is not the same as a hard cap: AWS Budgets will notify you but will not stop charges by default, and not all platforms enforce hard spending limits. Check what your specific platform actually does before assuming an alert will protect you. Default to a conservative threshold and raise it deliberately rather than leaving it open-ended.
• Monitor in near-real time. Waiting for the monthly invoice is too slow. Most platforms expose usage dashboards or cost APIs. Build a habit of checking them, or wire an alert if daily spend crosses a threshold.
• Test with rate limiting in place. When you are integrating a new metered API in development or staging, cap the request rate artificially. You will catch runaway loops before they reach production scale.
• Understand the unit economics of your product before you launch. If your product calls an AI model on behalf of each user, work out the per-user cost at expected usage. Then stress-test that assumption. A feature that costs you £0.002 per user at low volume can look very different at scale.

The vendors are not entirely blameless here. Default spending limits are often off or set very high. Dashboard UX can make it hard to understand what is driving costs until you are already deep in. Some have improved; many have not.

A short history of how we paid for software (optional, click to expand)

For most of software's commercial history, you paid upfront and got a perpetual licence. You bought a boxed copy of Microsoft Office, installed it from a disc, and it was yours. The vendor made money once at the point of sale, which created pressure to ship new major versions with features compelling enough to justify another purchase.

When SaaS arrived in earnest in the early 2000s, the payment model shifted to subscriptions. Salesforce's "No Software" pitch included a monthly fee rather than a perpetual licence. Vendors liked this because revenue became recurring and predictable. Customers liked it because the upfront cost disappeared and upgrades were automatic.

Cloud infrastructure introduced the first mainstream pay-as-you-go model. AWS launched in 2006 with EC2 billed by the hour (later refined to per-second billing in 2017). The premise was that compute should work like a utility: you pay for what you use, not for what you reserve. This was a radical idea at the time. Within a decade it had become unremarkable.

The metered model spread from infrastructure into software itself. Twilio (founded 2008) built an entire business on per-message and per-minute pricing for communications. Stripe took a cut of each transaction rather than charging a flat fee. These were not infrastructure companies but software companies that chose consumption as their native pricing model from day one.

The arrival of large language models has pushed metered billing into a new phase. Token-based pricing means even a simple chatbot integration involves tracking consumption at a granular level. The stakes are higher because the per-unit costs, while small, scale quickly with usage and with the verbosity of the prompts you write.

The AI cost curve deserves special attention

Token pricing is still unfamiliar territory for most development teams, and it has a few quirks worth knowing.

First, input and output are priced differently. Sending a long system prompt costs money. Getting a long response costs more. If your application sends a 2,000-token system prompt with every request, that accumulates fast across thousands of users. Prompt compression and caching (where the provider supports it) are not just engineering niceties; they are cost controls.

Second, model choice has a dramatic effect on cost. The most capable models from any given provider are typically ten to twenty times more expensive per token than their lighter counterparts. For many tasks, the lighter model is good enough. Defaulting to the most powerful option because it is the easiest choice is expensive.

Third, costs are still falling. The price of AI API calls has dropped substantially since 2023 and is likely to keep falling. That is mostly good news, but it also means cost estimates from last year may be significantly out of date. Worth rechecking assumptions if you costed an AI feature more than a few months ago.

Reading the pricing page properly

When evaluating a metered product, the pricing page headline number is rarely the whole story. Things worth looking for:

• What is the unit, and does it map cleanly to how you will actually use the product?
• Are there minimum commitments or monthly minimums buried in the terms?
• What happens when you exceed a tier? Does the price step up or does it scale continuously?
• Does the vendor offer spending caps, and how quickly do alerts fire?
• What does the billing dashboard actually look like? Vendors with clear, real-time cost visibility are worth a premium over those whose billing is opaque.

The shift to consumption pricing is not reversing. If anything, it is deepening as AI tooling bakes metered billing in from the ground up. Understanding how it works, where it is genuinely better, and how to defend yourself against runaway costs is a practical skill for anyone building or running software-dependent businesses right now.

How AI with Ash can support you

If you are building something that calls AI APIs, or evaluating metered infrastructure tools and trying to work out what it will actually cost at scale, these are exactly the kinds of questions worth talking through before you commit. Getting the cost model right early is much easier than retrofitting it after launch.

Book a call and we can work through the specifics of your situation together.