.jpg)
A year ago, almost every company we talked to sold seats. Now? Almost all of them sell tokens. Some are AI-native from day one whereas others are traditional SaaS companies that added an AI feature and quickly realized they couldn't just charge per user anymore.
Challenge? Your monetization stack (CPQ and Billing) is not ready for it.
AI Token monetization is actually three different models colliding at once: a subscription (tokens issued monthly or annually), usage (tokens burned as the product runs), and one-time buys (a quick top-off when a user runs low).
Most legacy CPQs handle one or two of these beautifully and completely butcher the other one. This causes adding patchwork/workarounds resulting in manual operations, revenue leakage and worse, painful experience for end customers.
Furthermore, customers buy in two distinct ways:
Small accounts want pay-as-you-go: Buy a handful of tokens and once used, buy more.
Enterprise accounts want to commit: They’ll agree to a massive annual token buy, but they want a steep volume discount in return.
You have to support both motions without tearing down your product catalog and building it twice.
Here's what you need to look for in a CPQ:
1. True Convergence of Subscriptions, Usage, and One-Time Charges
Every CPQ vendor will claim they support all three charge types. The real question is: do they actually talk to each other? Can a subscription grant a bucket of tokens, can live usage draw that specific balance down, and can a one-time purchase top off that exact same pool?
If your sales reps have to stack three entirely separate products on a single quote just to fake this workflow, you aren't fixing the problem; you’re just kicking a massive tracking error down the road to your billing team.
2. Running Both Buying Motions From a Single Catalog
Pay-as-you-go and committed enterprise contracts shouldn't live in separate universes. In reality, your best enterprise clients usually start out as small developer accounts paying with a credit card. When they are finally ready to sign a massive annual commit, moving them over should be a simple contract amendment, not a complex migration exercise.
3. Subscriptions Without Proration
If you only remember one thing from this list, make it this one.
Recurring token subscriptions are the holy grail; that is how you turn volatile token usage into predictable ARR.
But traditional subscription software is obsessed with proration. If a contract starts on the 17th of the month, or a customer changes their tier mid-term, the engine automatically chops up the bill by the exact number of days. That works perfectly for user seats. For tokens, it’s completely broken. If you sell a client 1M tokens for the year, they need all 1M tokens on day one; not some bizarre math equation like 1M × 214/365. You must be able to hard-stop proration for token grants, and many legacy tools simply cannot do this without ugly workarounds.
4. Total Control Over Your Issuance Schedule
The contract length and the token delivery schedule are two totally separate variables. Your CPQ needs to treat them that way. We see variations of this every day:
• A 2-year contract where 1M tokens land all at once, once a year.
• A 1-year contract where 100K tokens drop on the first of every month.
Both are technically subscriptions. But a customer with a massive upfront bucket behaves entirely differently than someone on a monthly allowance. The monthly customer hits their ceiling much faster, which gives your account managers a natural, regular touchpoint to trigger an expansion conversation.
5. Guardrails That Keep Special Rates Tied to Commitments
Enterprise clients commit up front because you give them preferred pricing. That’s standard. What you don't want is that heavily discounted rate accidentally showing up on a tiny pay-as-you-go account six months later because a sales rep copy-pasted an old quote. Your volume tiers, discounts, and preferred top-off rates must be dynamically locked to the specific upfront commitment that earned them in the first place.
6. Live Consumption Data Fed Directly From Your Product
As users burn tokens, your product needs to pipe that consumption data directly into your CPQ and billing system in real time. It sounds incredibly basic, but an alarming number of companies are still manually pulling usage exports at the end of the month. By the time the bill arrives, the renewal transforms into a massive argument over whose data is actually right.
7. Balance Alerts That Go Off Before Hitting Zero
If a customer's API suddenly cuts out in the middle of a critical workflow because they ran out of tokens, they won't pause to appreciate your complex pricing strategy. They’ll just think your software is broken. The system needs to automatically ping the client, the account team, or both when a balance hits a threshold like 15%. One of our hyper-growth clients actually uses these automated low-balance alerts as their number-one trigger for sales reps to reach out and close pre-emptive upgrades.
8. Auto-Replenishment at Pre-Approved Rates
Alerts are a great start, but automatic top-offs are the real end-game. Lock the token pricing directly into the master contract so that when a balance dips, the system can instantly inject more tokens in one of three ways:
• The Quick Top-Off: A one-time, fixed block of tokens.
• The Permanent Bump: A larger recurring grant every period moving forward (which immediately scales up your ARR).
• Pure Overage: The system keeps running and bills them pay-as-you-go at the agreed-upon rate.
Because the unit price was locked in at signing, nobody has to scramble for an executive approval at 11 in the night because a customer's live production workload suddenly froze.
.png)
.png)
