How the providers do it
Every OpenAI and Anthropic response carries a usage object with exact input and output token counts. Each model has a published rate per million tokens for each direction, so the cost of any call is arithmetic, and the invoice is the sum over the account. Three properties make it work: the meter is exact and per request, the price sheet is public, and aggregation happens at the account grain because that is who pays them. Note the grain: providers bill accounts, which is exactly why they cannot tell you about your users, the gap covered in the OpenAI Usage API guide.
Building your version, step by step
- Meter per user.Tag every model call with your user id and feature, store the usage object’s token counts against it. This is the foundation everything else stands on, and the discipline described in tracking AI costs per user. A single untagged code path means silent under billing forever.
- Know your cost per unit. Multiply metered tokens by current provider rates (live from the LLM pricing JSON feed, never a hardcoded table) to get real cost per user and per action, including the distribution, not just the mean.
- Pick the billable unit. Raw tokens are honest but unpredictable and leak your model choices. Credits abstract cleanly, covered in depth in building a credits system for your AI SaaS. Per action is friendliest when actions have stable token profiles.
- Price above the tail, not the average. A unit priced on the typical case loses money on the p95 user. The math pattern is the same heavy tail analysis as the unlimited plan audit.
- Invoice on rails. Report usage to Stripe metered billing (or equivalent) per period. Do not hand roll invoicing, hand roll nothing except the metering.
- Reconcile monthly. Sum of your metered cost should approximate the provider invoice. A gap is unmetered traffic, and unmetered traffic is margin leaking.
The part that rots: unit economics drift
Your price per credit stands still while everything under it moves: providers reprice (an 80 percent cut in July 2026, in the good direction, but it moves both ways), prompts get longer, models get swapped, output drifts. Teams set credit prices once and rediscover their real margin at the invoice. The fix is not vigilance, it is instrumentation: continuous cost per action per user, compared against what each user pays.
That comparison is precisely what Weckr computes on every call: metered tokens, server side cost at current rates, revenue from the user’s plan, margin per user and per feature. It is the metering layer of this whole article as two lines of code, and it doubles as your billing meter’s audit trail.
FAQ
How do OpenAI and Anthropic bill for their APIs?
Per token, metered, postpaid or prepaid credits. Every request reports exact input and output token counts, each model has a price per million tokens for each, and the invoice is the sum. The three ingredients are a meter (token counts per request), a price sheet (rates per unit), and an aggregator that rolls usage into an invoice per account.
Can I replicate token based billing for my own product?
Yes, and you already have the hardest part: the provider reports exact token counts on every response. You need per user metering (tag each call with the user id and store the usage), a pricing decision (bill raw tokens, credits, or actions), and an invoicing rail, which Stripe metered billing or usage based invoicing handles. The engineering is mostly the metering discipline, not the payments.
Should I bill my users per token, per credit, or per action?
Almost never raw tokens: users cannot predict them, and you expose your unit costs and model choices. Credits are the common middle ground, an abstraction you price above cost. Per action (per document, per conversation, per generation) is the most user friendly and works when your actions have reasonably stable token profiles. Whatever the unit, it must map to measured cost or your margin is a guess.
What margin should I put between my token cost and my price?
AI native products commonly aim for gross margins well above 50 percent on the AI unit itself, because model spend is only one of your costs and prices you charge are sticky while provider prices move. Concretely: measure your real cost per action across live traffic, including the heavy tail, then price the unit at a multiple of the typical case that still survives the p95 user.
What usually goes wrong with usage based AI billing?
Three failures: metering drift, where some code path calls the model without recording usage, so you under bill; stale unit economics, where a model or price change silently alters cost per action while your prices stand still; and no reconciliation, where nobody compares billed usage against the provider invoice. All three are solved by measuring cost per user per feature continuously rather than assuming it.
Keep reading
Meter first. Everything else is arithmetic.
Whether you end up billing credits, actions, or flat plans with caps, the prerequisite is the same: knowing what each user costs you, live. Weckr gives you that meter in two lines, free for 50,000 requests a month. See the per user numbers on the live demo, or start from the AI cost and margin guide.