I pay for Claude. Most months, one of two things happens: I either burn through my limit faster than expected and have to slow down on work I actually wanted help with, or I underuse the tool because I’m watching my usage meter and second-guessing whether a question is “worth” asking the AI.

I’m not unusual. Every AI product I pay for personally produces some version of the same experience: meter anxiety, surprise bills, or quiet underuse. And the same patterns are playing out at scale inside the enterprise, where customers are consuming AI features through the products they buy, just with bigger numbers and more confused finance teams.

Token-based billing has a place. It’s how major foundation model providers price their compute, and it’s the only metric many companies can confidently instrument early on.

Walk through any AI feature shipped in the last two years, and you’ll find some flavor of token-based billing underneath. Per-message credits, per-action units, per-conversation costs – different names, same idea. It’s the default. And it’s worth asking why everyone defaulted to the same model, and whether that default still makes sense as the AI feature surface expands.

My argument is simple: tokens are a fair pricing unit for foundation model providers, because tokens map to their cost structure. They’re a much less obvious choice for the companies building products on top of those models. Most companies are over-relying on token-based pricing, and the trade-offs are starting to show.

Why token billing became the default

Three reasons, none of them about customer value:

  • It mirrors the wholesale cost: When you’re reselling compute, passing the meter through feels safe and defensible. Finance teams can map revenue to costs cleanly. Procurement can’t easily argue you’re overcharging.
  • It’s the only metric you can confidently instrument on day one: Outcome-based billing requires you to define an outcome first, and outcomes are hard to define for general-purpose AI features. Usage-based billing just needs a counter.
  • It transfers cost risk to the customer. If usage spikes, the customer pays. If usage flatlines, the vendor isn’t on the hook. The vendor’s margin is protected regardless of how the product actually performs.

None of those are bad reasons. They’re just not customer-centric reasons. They’re vendor-centric reasons dressed up as fairness.

What’s quietly breaking

Token-based billing isn’t catastrophically failing; it’s quietly degrading. There are six patterns worth looking out for:

1. Customers don’t understand the units they’re being charged for 

This is the most basic problem and the one almost nobody talks about. Tokens are an engineering abstraction. A token is roughly four characters, but it’s not exactly four characters; it varies across models. Plus, input tokens are priced differently from output tokens, and cached tokens cost something else again. 

The first time a business user sees an invoice with “tokens consumed” on it, the reasonable reaction is to ask what a token is. The honest answer is that it’s a unit invented by the people billing them, for reasons that have nothing to do with the work being done. That’s a hard place to start a customer relationship.

2. Customers can’t predict their bill

Even when customers understand what a token is, they can’t forecast how many they’ll use. Finance teams cap usage of features that should be used heavily, just to control variance. AI features get bought and then under-deployed, because nobody wants the call from finance asking why this month’s bill is three times last month’s.

3. Pre-paying for tokens doesn’t fix it

The standard response is to let customers buy tokens or credits in advance. The pitch is predictability. The reality is that customers run out mid-month, mid-quarter, or mid-project – and then the conversation becomes either an emergency top-up at higher rates or a hard stop in the middle of work that was already paid for. 

Pre-purchasing converts a variable-bill problem into a depletion problem, which is a different problem, not a solved one.

4. Tokens don’t correlate with value

A 50-token answer that resolves a customer issue is worth more than a 5,000-token answer that doesn’t. Token billing rewards verbose, low-quality output. It’s a metric that gets bigger when your product gets worse. The meter goes down. The bills go up. When a meter behaves that way, it isn’t really measuring value; it’s measuring activity.

The wider industry data tells the same story. According to Gartner, generative AI software spending is forecast to increase 47% to $2.59 trillion in 2026, even as per-token prices continue their steep decline. 

5. Adoption stalls

Users hesitate. “Should I really run this through the AI? It costs money.” The friction is the opposite of what AI features need in their first eighteen months, which is high-frequency, low-stakes use that builds habit and trust.

6. Billing infrastructure becomes a moving target for the engineers building the product

Tracking tokens accurately across multi-step agent flows, retries, caching, fine-tuning costs, internal vs. external calls – this is genuinely difficult engineering. 

And the engineers writing the feature have to keep one eye on an external pricing sheet that changes without notice: input tokens at one rate, output tokens at another, cached input at a third, premium models at a multiple, batch processing at a discount, regional inference at a premium. Every one of those distinctions has to be metered, attributed, reconciled, displayed in the UI, and made consistent on the invoice. 

Many teams are quietly spending more engineering time on billing edge cases than on the AI features themselves. That tax doesn’t show up in any vendor pitch deck, but it shows up in every roadmap review.

That last point is the one most product managers don’t see coming. You can build the AI feature in three months. The billing infrastructure to charge accurately for it will take a year and still have edge cases.

The complexity is borrowed, not necessary

Here is where the argument gets sharper. The bill that companies pay to their foundation model providers is genuinely complicated, and that complication has a real reason behind it.

Anthropic charges $5 per million input tokens for its current flagship Claude Opus model and $25 per million output tokens – but cached inputs cost about 10% of that, batch processing knocks 50% off everything, and the latest tokenizer update can quietly increase effective cost per request by up to 35% on the same prompt. 

OpenAI splits its API across multiple processing tiers – Batch, Flex, Standard, Priority – with prices that can differ by several multiples for the same underlying model. 

None of that is unreasonable. Foundation model providers are selling compute, and compute genuinely has that much variance in what it costs to serve a request. The complexity reflects real economics.

Here is where the chain breaks down. Companies that buy from those providers absorb that complex bill – and then pass an equally complex bill through to their own customers. Token meters. Credit packs. Tiered consumption rates. Different prices for different feature flavors. 

Some of the most widely adopted productivity and workflow platforms are now billing customers in “AI credits” that map directly to upstream token rates, complete with model-specific multipliers. The structure mirrors the upstream invoice almost line for line.

That’s a choice, not a requirement. Your customers don’t see your foundation model bill. They don’t know whether you used a flagship model or a smaller one, whether the cache hit, whether the request ran in batch. They shouldn’t have to. The entire point of being the layer above the foundation model is that you absorb the upstream complexity and present customers with something predictable.

Foundation model providers bill in complexity because their cost structure is genuinely complex. The companies selling to enterprises bill in complexity because they copied the invoice they were paying. Those are very different reasons to bill the same way – and only one of them holds up.

What else is possible?

Token billing isn’t the only option. It became the default because it was the easiest to ship, not because it was the best fit. A handful of alternatives are worth considering, each rewarding different behavior:

  • Per active user / AI seat license: Predictable, easy to budget, customers love it. Disconnects revenue from usage, which makes vendors nervous. Works well when usage patterns are consistent across users, and the AI is a feature inside a broader workflow, not the workflow itself.
  • Per outcome / per resolved task: Closest to customer value. Hardest to define (“what counts as resolved?”). Works in narrow domains where outcomes are clean – support deflection, document summarization, content generation with clear success criteria. Fails when outcomes are subjective or contested.
  • Tiered by capability, not consumption: What most non-AI software already does. Basic AI features in the standard tier; advanced agents in the enterprise tier. Predictable, defensible, doesn’t require new infrastructure. The downside is that it doesn’t capture the upside when a customer’s usage grows dramatically.
  • Hybrid: base seat + outcome credits: Probably where the market lands. Predictable floor for the customer, upside for the vendor when AI delivers real value. More complex to communicate, but matches how customers actually think about the product.
  • Pure consumption (where it still makes sense): Not all features should leave token billing behind. Developer APIs, ad-hoc tools, agent platforms – places where the customer is effectively buying compute and knows it – token billing is still honest. The mistake is treating it as the default everywhere else.

The point isn’t that one model wins. The point is that the choice should be deliberate, not defaulted. Most companies didn’t decide; they just copied what the foundation model API page looked like and called it a pricing strategy.

What product teams should actually do

Four things, if you’re working on AI features today:

  1. Treat pricing as a product decision, not a finance decision: The billing unit shapes how customers use the product, which shapes whether they renew. That’s product territory. If pricing gets handed to procurement or finance after the product ships, the wrong unit gets locked in and is painful to undo.
  2. Match the billing unit to the value the customer experiences: If they buy outcomes, bill for outcomes. If they buy seats, bill for seats. If they really do buy compute, bill for compute. Don’t pick a unit just because it’s measurable. Easy-to-instrument and easy-to-justify are not the same thing.
  3. Absorb the complexity upstream of the customer: If your foundation model bill is complicated, that’s your problem to manage, not your customer’s. The job of the product layer is to convert messy upstream economics into a clean downstream price. Recreating the upstream invoice for your customer is the opposite of doing that job.
  4. Account for the infrastructure cost honestly: If you’re going to use consumption-based billing, the engineering investment is large and ongoing. Metering, reconciliation, error handling, refunds, dispute resolution – these are not edge cases. They are the system. That cost belongs in the pricing decision from day one, not as a discovery in year two.

Closing thoughts

Billing should be straightforward. A customer should be able to look at an invoice and understand it. A finance team should be able to forecast it. An engineering team shouldn’t need to spend its week reverse-engineering a foreign pricing sheet to make sure last month’s charges add up.

Foundation model providers will keep billing in tokens, and they should. But the companies building products on top of those models are selling something different – workflows, outcomes, time saved – and the price they charge customers should reflect that.

The companies that get this right won’t necessarily be the ones with the best AI. They’ll be the ones whose customers can actually predict and approve the cost of using it.