Jordan: Four clients. GPT-4o and Claude three Haiku running behind the scenes. Last month I pulled my OpenAI and Anthropic invoices and added them up — twenty-one hundred and forty dollars in token costs across those four accounts. You know what I billed those clients? A flat retainer. Same number every month. And when I actually mapped tokens consumed per client — one of them was burning eight hundred and sixty dollars a month in API calls on a fifteen-hundred-dollar retainer. That's a fifty-seven percent cost-of-goods on a single account. Before my tools, before my time, before anything else.
And the worst part? I had no idea. I was guessing. Estimating. Telling myself it probably evens out. It did not even out.
So I went looking for a way to meter every token, tie it to a client, price it automatically, and have Stripe handle the invoicing. No spreadsheets. No end-of-month reconciliation. Just — usage happens, usage gets billed. Turns out Stripe rebuilt their entire metering stack for exactly this. And there are now two paths to wire it up — one where you write zero metering code, and one where you post events yourself from Make or n8n. Today I'm building both.
Jordan: Every month you run AI for clients on a flat retainer, you are subsidizing their usage with your margin. The gap between what the models cost and what you charge only widens as clients adopt the tools you built for them — and that's the cruel irony. Success makes the problem worse. Today we're fixing that with Stripe usage-based billing. Meters, pricing plans, rate cards, and two concrete implementation paths so that by next invoice cycle, every token has a price and every client pays for what they actually use.
Jordan: Okay, so the core problem. You're delivering AI-powered services — content generation, data extraction, customer support bots, whatever your niche is — and you're pricing on a flat monthly retainer. That works great when your costs are predictable. Hosting is predictable. Automation tool subscriptions are predictable. But API token costs are not predictable, because they scale with how much your client actually uses the thing you built.
And here's where it gets dangerous. A client who barely touches the tool in month one starts leaning on it hard by month three. They're sending more queries, longer prompts, requesting more complex outputs. Your costs double. Your retainer stays the same. You're effectively giving yourself a pay cut every time your client gets more value from your work.
The fix is usage-based billing. You meter every token, you price it per thousand, and Stripe invoices the client automatically at the end of each billing period. The client sees exactly what they used. You capture margin on every API call. And the beautiful part — the more they use it, the more you earn, instead of the more you lose.
Let me walk through the full build.
Jordan: First decision — how do you price tokens? You need to know three things. What your provider charges you per thousand tokens, what markup covers your margin, and whether you want to price differently by model or by token type.
Token type matters more than people realize. Input tokens — what the client sends to the model — are almost always cheaper than output tokens — what the model generates back. And if you're using prompt caching, cached tokens are cheaper still. So you've got three cost tiers per model before you even think about markup.
Here's a concrete example. GPT-4o mini charges you fifteen cents per million input tokens and sixty cents per million output tokens. That's zero-point-zero-one-five cents per thousand input, zero-point-zero-six cents per thousand output. If you apply a two-x markup — which is the minimum I'd recommend — your client rate is zero-point-zero-three cents per thousand input and zero-point-one-two cents per thousand output. Sounds tiny. But a client running fifty thousand queries a month at an average of two thousand tokens per query? That adds up fast.
Jordan: Now we set up the Meter in Stripe. This is where the magic actually lives. Go to your Stripe Dashboard, find Meters under the Billing section, and hit Create Meter.
Three settings matter. Event name — I use "ai underscore tokens" as a single event name for everything. Aggregation — set it to sum, because you want Stripe to add up all the token events over the billing period. And then Dimensions — this is the key part. Add two dimensions: "model" and "token underscore type." These let Stripe slice your usage by which model generated the tokens and whether they were input, output, or cache tokens.
For the payload mapping, you need two required keys. "stripe underscore customer underscore id" maps the event to the right client. "value" is the raw token count — not thousands, just the actual number of tokens. Stripe handles the aggregation.
One thing that tripped me up initially — the value field takes raw tokens, but your pricing is per thousand. Stripe does that math for you when you set up the rate card. You don't need to divide by a thousand before sending the event. Just send the raw count.
Jordan: Next — Pricing Plans. Still in the Dashboard, go to Pricing Plans, create a new one, and add a rate card. When you attach a rate, you'll select the Meter you just created.
Now you pick your price type. Three options. Flat — same price per thousand tokens regardless of volume. Volume — the price changes based on total usage within a tier. Graduated — different prices apply to different chunks of usage, like the first million tokens at one rate and everything above that at a lower rate.
For most solo operators starting out, flat pricing is the simplest and the most transparent for clients. You can always add volume tiers later when a client's usage justifies a discount.
Oh — and this is where credits come in. Stripe has something called service actions in Pricing Plans. You can grant a monthly credit — say, fifty thousand free tokens — that applies automatically and expires at the end of each billing period. So if you want to include a base token allowance in your retainer and only bill overages, you configure that here. No custom balance logic. Stripe handles the expiration and the math.
Before you go live, use the Upcoming Invoice preview on the subscription. It shows you exactly what the client would be charged based on current usage. Sanity check this against your cost spreadsheet. If the numbers don't match, you've got a dimension mismatch or a rate card error — catch it now, not on the first real invoice.
Jordan: Okay, this is the path that genuinely surprised me. If you're routing your AI calls through Vercel's AI Gateway — and if you're not, this might be reason enough to start — you can get automatic Stripe metering with zero custom code.
Here's how it works. On every AI request that goes through the gateway, you include two headers. One is "stripe dash customer dash id" with the client's Stripe customer ID. The other is your Stripe restricted API key — and I'll come back to why it needs to be restricted, not your full secret key.
When the AI call completes, the gateway automatically sends two meter events to Stripe. One for input tokens, one for output tokens. Each event includes the customer ID, the model name, and the token type. It maps directly to the Meter dimensions you set up.
Two headers. That's it. No aggregation logic. No cron jobs. No Make scenarios polling for usage. The gateway handles metering as a side effect of routing the AI call. For solo operators who want the simplest possible path, this is it.
One important detail on the API key. Go to your Stripe Dashboard, create a restricted key, and give it exactly one permission — Billing Meter Events Write. Nothing else. You're passing this key through a third-party gateway, so you want the smallest possible blast radius if something goes wrong.
Jordan: Now, if you're not using Vercel's gateway — maybe you're calling APIs directly, or you're using a different proxy, or you just want more control over when and how events get posted — you build the metering yourself.
The endpoint is Stripe's v2 billing meter events API. You're sending a POST request with a JSON body that includes your event name, the customer ID, the token count, the model, and the token type. You also include an idempotency key in the header — and this matters. If your scenario retries on a timeout, the idempotency key prevents Stripe from double-counting the same usage.
In n8n, there's a native Stripe node with a Create Meter Event action. You authenticate with your restricted key, map the fields, and schedule it on a cron — hourly or daily, depending on how granular you want the metering.
In Make, you use an HTTP module. POST to the v2 endpoint, set your authorization header with the restricted key, set the idempotency key header, and pass the JSON body. Add error handling for four-twenty-nine rate limits and five-hundred server errors with exponential backoff.
I run mine daily. Every night at midnight Central, a Make scenario pulls the day's usage from my app's logs, aggregates by customer, model, and token type, and posts one meter event per combination. Roughly takes eight minutes to run across all clients. That's a twenty-nine-dollar-a-month Make plan replacing what would otherwise be a custom billing microservice.
Jordan: Okay — I need to be honest about something. Stripe's Token Billing product — the one specifically designed for LLM token metering — is in private preview as of April twenty-twenty-six. You can't just flip it on. You'd need to contact their token billing team to get access.
And the broader Meters and Pricing Plans stack, while publicly available, is still relatively new. The v2 API endpoints, the dashboard UI for rate cards — this stuff has changed in the last year and will probably change again.
So should you wait?
No. And here's why. Everything I just walked through — the Meter with model and token type dimensions, the rate card with per-thousand pricing, the gateway headers or the self-posted events — all of that works today with standard Meters. You don't need Token Billing enabled. You don't need any private preview flags. The standard Meter plus a Pricing Plan rate card gives you dimensional usage billing right now.
If and when Token Billing goes generally available, your Meter dimensions already match what it expects. You're not building throwaway infrastructure. You're building the foundation that the premium product snaps onto.
Jordan: Last piece — and this is the part people skip and then regret. You need alerts and you need dunning protection.
Stripe lets you configure usage alerts directly on a Meter. Set thresholds at fifty percent, eighty percent, and one hundred percent of a client's expected monthly usage. When a threshold gets crossed, Stripe fires a webhook. Route that webhook to Slack — I use a Make scenario that catches the webhook and posts to a client-specific Slack channel — and now you know the moment a client's usage is spiking before the invoice surprises anyone.
The hundred percent alert is especially important. If a client's usage doubles because they launched a new feature on top of your automation, you want to know that week, not when the invoice goes out and they call you confused.
For dunning — turn on Smart Retries. It's in your Stripe Dashboard under Billing, then Revenue Recovery. One toggle. Stripe's engineering team built this on machine learning trained across billions of payment data points. It schedules retries at the optimal time for each card network and issuer. We covered this in detail back in episode five, but the short version is — enable it, and failed subscription payments get retried automatically without you sending a single awkward email.
And if you haven't already, activate the customer portal. Your clients can see their upcoming invoice, their usage breakdown, and their payment methods — all self-serve. That transparency alone reduces billing disputes to nearly zero.
Jordan: Three quick edge cases before we wrap the build. Backfill — if a webhook misses or your Make scenario fails overnight, you can post meter events with a historical timestamp as long as it falls within the current billing window. Stripe accepts backdated events. So you're not losing data on a transient failure.
Caps — if you want to hard-cap a client's usage rather than just alerting, you enforce that at the gateway or app level, not in Stripe. Stripe meters and invoices. It doesn't throttle. Your gateway or your app needs to check the current period's usage and reject requests once the cap is hit.
And free credits — we already covered service actions in Pricing Plans. Set the monthly credit amount, Stripe deducts it from the metered total, and any unused credits expire at period end. Clean, automatic, no custom code.
Jordan: Remember that client — eight hundred and sixty dollars a month in API costs on a fifteen-hundred-dollar retainer? That account now runs through a Meter with model and token type dimensions, a two-x markup rate card, and fifty thousand free tokens baked into the plan as a credit. Last month they used about a hundred and twenty dollars more in tokens than the credit covered. They paid for it automatically. I didn't send an email. I didn't open a spreadsheet. The margin on that account went from barely surviving to healthy — and the client actually prefers it because they can see exactly what they're using in the portal.
If you want to skip the math on pricing your own token rates, grab the AI Token Billing Calculator plus Stripe Mapping Sheet on the Resources page. Plug in your provider costs, set your markup, and it outputs the exact rates and dimension values you need for your Meter and Pricing Plan.
One thing to do this week. Pick one client. Pull their last thirty days of API usage. Map it against what you charged them. If the gap scares you, build the Meter.
I'm Jordan. This is Headcount Zero. Go ship it.