Token-scaled APIs — LLM wrappers, search, enrichment, anything where one call does more work than another — are the hardest to bill, because the cost isn't fixed per request. The instinct is to build a meter: count tokens, aggregate per customer, invoice monthly. You usually don't need to.
Quick answer: Express the price as a base amount plus a per-unit surcharge, and charge it per call instead of metering to a monthly bill. Price on inputs you know before you run the work (or charge a flat per-result price), quote the total in a signed 402, and let the caller pay and retry. Because each call settles on its own, there's no meter to aggregate and no invoice to reconcile.
Two ways to charge for token-scaled work
There are only two real shapes here, and they have very different build costs:
- Meter, then bill. Count tokens on every call, sum them per customer over a month, apply a rate card, send an invoice. This is the classic usage-based stack — accurate, but it's the ingestion-plus-aggregation-plus-invoicing pipeline that runs past $200K to build well.
- Price, then charge per call. Put a price on each call up front and collect it in the request. No monthly meter, no invoice — the caller pays to get the result. This is the model x402 uses, and it's what the rest of this post is about.
For agent traffic especially, the second shape fits: an autonomous caller has no account and won't wait for a monthly bill, so pricing the call it's making right now is the only thing it can act on.
Structure the price as base + per-unit
Token-scaled pricing is legible when you split it in two:
- a base price that covers the fixed cost of handling the call, and
- a per-unit surcharge for the work that scales — per 1,000 tokens, per item returned, per page rendered.
This is exactly how the LLM APIs underneath most of these products already price. In mid-2026, OpenAI's GPT-4 Turbo lists around $5 per million input tokens and $15 per million output tokens, and Anthropic's Claude Sonnet lists about $3 per million input tokens (pricepertoken.com tracks 300+ models). If your API wraps a model, your price has to sit above that per-token cost with margin — the base-plus-surcharge split makes that easy to reason about and easy to change.
Quote the total in the 402
Here's the mechanic that removes the pipeline. When a caller hits a metered route without paying, the route answers with a signed 402 that states the exact price for this call. The caller pays in USDC and retries; the route serves the result. You register the route and its price rule, add one middleware, and the SDK quotes and verifies for you — failing closed if payment can't be confirmed.
Because the price is settled in the same exchange as the result, "metering" collapses into "pricing": there's no separate counter to run at month-end, and no invoice to send. You read settled payments from the payment.settled webhook and the dashboard.
When you don't know the size until you compute it
The honest edge case: sometimes output size — and therefore cost — isn't known until after the work runs. Three practical patterns:
- Price on the input. Input tokens, query length, or document size are known before you run anything. Price on those and you can quote up front.
- Charge per result, not per token. Set a flat price for a successful call and eat the variance. Simple, predictable for the caller, and implementable as "free
4xx, paid2xx" at the gate — you only charge when the call succeeds. - Tier by size band. Offer a few priced tiers (small / medium / large) and let the caller pick the ceiling. Each tier is a fixed, quotable number.
All three keep the price something you can put in a 402 before the caller commits — which is what lets you skip the meter.
FAQ
How do I set up metering and billing for an API that charges per token?
You have two options. Build a metering pipeline (count tokens, aggregate per customer, invoice monthly) — accurate but expensive. Or price each call as a base amount plus a per-unit surcharge, quote the total in a signed 402, and charge per call — no monthly meter, no invoice. For per-token work where output size is unknown up front, price on the input, charge a flat per-result price, or tier by size band.
Can I charge per token with x402 if I don't know the output size in advance?
Yes, by pricing on something you do know before running the work — input tokens, query size — or by charging a flat price per successful result. The 402 has to quote a concrete number before the caller pays, so the trick is choosing a unit you can measure up front.
Do I still need a billing system for a per-token API?
Not if you charge per call. Each call is priced and settled individually, so there's no aggregation step and no invoice. You reconcile by reading payment.settled webhooks and the dashboard rather than running a billing job. See what billing infrastructure you actually need.
How is per-token pricing different from a monthly quota? A quota bills a lump sum for a bucket of usage a human manages; per-token-per-call prices each request at the moment it happens, which is the only model an autonomous agent can act on. Many APIs run both — quotas for known developers, per-call for agents. See pay-per-call vs subscriptions.
Next steps
- Set the number: how to price an API for AI agents
- What you don't have to build: billing infrastructure to charge per API call
- The model end to end: the monetization playbook
- Try it free: pricing and create an account