TL;DR: Usage-based pricing drives retention and growth when metering, rate cards, and customer-facing visibility are built before the pricing model ships. Snowflake and Twilio are the evidence. Cursor's mid-2025 rollout is the counter-evidence: same category of pricing model, a customer backlash, a public apology, and a refund window. The difference came down to whether customers could see the meter running before the bill arrived.

Two companies can run the exact same pricing model on paper and land in completely different places in practice. One ends up with a retention number people cite in decks for years. The other ends up with a public apology and a refund window. That gap should worry anyone about to price an AI product by the token, probably more than it currently does.

The version that works: Snowflake and Twilio

Snowflake's whole pricing model rests on one architectural decision: decoupling storage from compute (the kind of call that looks obvious in a case study and took real internal fighting to actually ship, probably). Customers pay for storage separately from the compute they spin up to query it, in credits, by the second. That single decision is why Snowflake could price by consumption at all. Its net revenue retention hit 158% around its 2020 IPO, the highest of any cloud company at listing. It's since cooled to around 127% in fiscal 2025, which sounds like a drop until you remember that's still a company getting paid meaningfully more by the same customers, year over year, off a much bigger base. The price tracks the value the customer is actually pulling out of the platform. It's not more complicated than that.

Twilio runs the same logic at a different unit. $0.0079 per SMS. $0.013 per minute of voice. Twilio pays carriers on a usage basis to deliver those messages and calls, so pricing usage-based on the customer side is the only model that keeps its own margin intact as volume scales. A developer can send ten messages testing an integration or ten million running a production alerting system, and the unit economics hold in both cases. Nobody at Twilio has to guess whether you're a weekend hobbyist or a Series C company. The invoice does the segmenting for them.

The thread connecting both, if you squint: the meter existed before the price did. Snowflake could tell you exactly how many compute-seconds a warehouse burned before that number ever became a line on an invoice. Twilio could tell you the exact carrier cost of an SMS before it decided what to charge for one. Pricing came second. It usually should.

The version that breaks: Cursor's July

In mid-2025, Cursor moved its Pro plan away from a flat quota (500 "fast" requests a month) to a model where $20 of monthly credit gets consumed at current API rates, and anything past that requires buying more credit or hitting a spending cap. Functionally, that's usage-based pricing... the same category of model as Snowflake's and Twilio's.

I bet lots of cursor users found out that they had no clear way to see how fast that $20 was burning until it was gone, in some cases after a handful of prompts. I remember reading on HackerNews of people with >$350 in Cursor overage in a single week (which is a lot more than the mentally "$20-ish" since forever). CEO Michael Truell posted a public apology acknowledging the company hadn't communicated the change clearly, and Cursor refunded users charged unexpectedly between June 16 and July 4, 2025.

Lots of people went to Cursor's forums to try and help them be more clear about pricing

You'd think a company selling AI coding tools to developers would have usage telemetry solved on day one. Not my favourite kind of surprise to read about from the outside, but at least it's an honest one, and Truell owned it in public instead of slipping a fix in and hoping nobody noticed. The gap between usage happening and a customer being able to see what it cost, in the moment, is what actually broke. The pricing model itself was fine.

Be warned: agentic usage doesn't behave like chat usage

Part of what makes this moment different from a normal SaaS metering problem is that the workloads themselves stopped being predictable. Agentic tasks (chains of tool calls, retries, multi-step reasoning) can burn up to 1,000x the tokens of a single chat exchange, and vary as much as 30x between two runs of what's supposed to be the same task.

A pricing model calibrated on chatbot-era assumptions doesn't survive contact with an agent that loops, retries, and carries context forward across dozens of steps. Nobody priced for an employee's Tuesday afternoon turning into a compounding loop.

The Agentic workflow loop (via neo4j)

The most extreme version of this made the rounds earlier this year: reports of an unnamed company that burned through roughly $500 million on Claude usage in a single month after failing to set per-user spending limits across its employee base. I guess that's semi-real but we don't know who it is.

Engineers running parallel agentic coding sessions at scale, multiplied across thousands of seats with no caps configured, turned a normal enterprise AI rollout into a nine-figure invoice. The controls to prevent this exist. Admin dashboards, per-user limits, spending caps, all available, all optional. Somebody just never flipped them on. Whoever signed off on that month's finance report had a considerably worse Monday than the rest of us.

What the market data says about who's ready for this

The Revenera Monetization Monitor puts a number on some of these things.

74% of companies have adopted usage-based pricing at least moderately. 59% expect usage-based revenue to keep growing, up 18 percentage points from where that number sat in 2023. And 70% say the cost of delivering AI functionality is already cutting into their margins. Everyone's rushing toward the model - which is fine I guess.

Here's the number that is interesting to me: only 36% report strong alignment between what they charge and the value the customer is actually getting. Adoption is running well ahead of the metering, rate-card, and visibility infrastructure needed to run it responsibly.

Yep, that means most companies bolted usage pricing onto systems that were never built to price, meter, and show that price back to a customer in real time, which is exactly the kind of stuff that turned Cursor's rollout into a news story instead of a routine plan change nobody would have noticed.

How to make sure you win with pricing

Lay it out like that and I think it gets quite obvious:

1. Every company in that table could tell you the same technical story about how tokens, requests, compute-seconds, are all metered and all billed proportionally

2. Companies that did well gave customers dashboards to watch and measure

3. Companies that didn't do well just sent customers a bill at the end

What to do if you're pricing an AI product by usage

OK, so what does this actually mean if you're the one about to price an AI product by usage, probably sometime in the next two quarters, and most definitely faster than you'd like?

Meter before you price.

If you can't show a customer their own consumption in something close to real time, you're not ready to bill them for it, no matter how sound the rate card looks on a spreadsheet. Give customers the same visibility internally that they'll eventually get externally, so nobody on your team is surprised by the invoice before the customer is (this one sounds obvious until you're the team that skipped it). Price to match your own cost curve, e.g., what the underlying inference actually costs you at this model, at this volume, rather than borrowing a flat mental model from subscription pricing and hoping usage stays inside it. And treat "how does the customer see this coming" as a launch requirement, not a follow-up release. It's cheaper to build once than to apologize publicly later.

I'll plug Solvimon here because we are one of the best when it comes to AI billing: Make sure you know whether metering, pricing, and customer-facing visibility live in one system that can show the truth before the invoice does, instead of three disconnected tools that only agree with each other at month-end, regardless of which pricing model sits on top. Again, Solvimon runs metering, rate cards, and revenue recognition through a single ledger, which is the difference between a pricing change and a refund window - and that makes us really suitable for AI billing.

Truell's team fixed Cursor's visibility gap in a matter of weeks, and the post-mortem reads like most vendors' unshipped roadmap item, the one everyone agrees is important and nobody schedules. The next company that skips that step in the first place probably won't have Cursor's userbase left around to forgive them for it.

Frequently Asked Questions

What are some examples of successful usage-based pricing models in tech companies?

Snowflake, Twilio, Datadog are excellent examples.

Snowflake prices compute and storage separately by the credit, which let it decouple pricing from a single bundled resource and hit 158% net revenue retention at IPO (127% as of fiscal 2025).

Twilio charges $0.0079 per SMS and $0.013 per voice minute, mirroring the carrier costs it pays underneath, so margin holds whether a developer sends ten messages or ten million.

Datadog prices by host and by gigabyte of log ingestion, growing to $3.43 billion in 2025 revenue with 120% net revenue retention as of Q3 2025.

What are common pitfalls in token economics for startups?

The most common one I see is going for a usage-based price before customers can see their own consumption in real time (again, Cursor's 2025 rollout), letting agentic workloads run without per-user spending caps (that often-reported $500 million Claude bill), and lastly treating prepaid balances as a bookkeeping afterthought instead of a revenue recognition liability.

I personally don't like locking usage allocations to individual seats instead of the organization, which creates stranded credits nobody can use - but that's more of a nitpick for me personally.

Why did Cursor's pricing change cause a backlash?

Cursor moved from a flat monthly quota of fast requests to a model where $20 of credit gets consumed at live API rates. Users had no clear way to track how fast that credit was burning, some ran through it in a handful of prompts, and one user reported $350 in overage in a single week. Cursor's CEO apologized publicly and refunded users charged unexpectedly between June 16 and July 4, 2025.

Is usage-based pricing riskier than subscription pricing?

Not inherently. The risk comes from missing metering and visibility infrastructure rather than from the pricing model itself. Snowflake and Twilio run pure usage-based pricing at scale with strong retention because customers can see their own usage before the invoice arrives. The risk shows up when a company bills for usage the customer couldn't observe coming.

How much more can AI agent workloads cost compared to a normal chat interaction?

Agentic tasks, involving tool calls, retries, and multi-step reasoning, can consume up to 1,000 times the tokens of a single chat exchange, and vary as much as 30x between two runs of what looks like the same task. That variability is why pricing models calibrated on chatbot-era usage patterns break down once a product goes agentic.

Should a startup build usage-based billing in-house or buy existing infrastructure?

Don't build this yourself. There are hundreds of Reddit threads that explain why it's a bad idea. The moment you're combining multiple models, multiple customer segments, or usage alongside seats and credits, most teams end up maintaining custom orchestration code that becomes its own liability. That's usually the point where buying metering, pricing, and revenue recognition as one system gets cheaper than the engineering time spent maintaining a homegrown one.