Pricing an AI API is different from pricing a conventional SaaS product, and the differences matter for both unit economics and customer behavior. When you're selling access to LLM inference, image generation, or speech processing, the unit of consumption is tiny, variable, and occurs thousands to millions of times per customer per month. The pricing model you choose shapes what customers build, how they grow, and how predictable your revenue is.
There's no single correct answer for how to price AI APIs — but there are frameworks that work better than others for specific GTM motions, and there are implementation traps that trip up teams building their monetization stack for the first time.
Token Billing: Direct and Demanding
Pure per-token billing is the most intuitive model for AI API pricing: charge a rate per input token, a (typically higher) rate per output token, and bill the customer monthly for their total consumption. The math is transparent, the alignment with your compute costs is direct, and technically sophisticated buyers understand exactly what they're paying for.
The metering requirement for per-token billing is demanding. Every API call must capture both input and output token counts, not just request count. These counts need to be accurately attributed to the customer, deduplicated if the client retries, and aggregated across the billing period. If a single API call returns a streaming response that's broken into 50 chunks, you need to sum the token counts across all chunks and attribute them to a single event.
{
"idempotency_key": "req_01HX9P2Q3R4S5T6U7V8W9X0Y1Z",
"customer_id": "cus_abc123",
"event_name": "llm_inference",
"timestamp": "2025-05-27T09:14:22.331Z",
"properties": {
"model": "text-gen-v3",
"input_tokens": 412,
"output_tokens": 1083,
"request_type": "completion",
"latency_ms": 2847
}
}The operational complexity compounds when you have multiple model tiers with different pricing. A customer might use your standard model for batch jobs (lower cost) and your premium model for real-time responses (higher cost). Your metering schema and pricing engine must handle model-differentiated rates correctly, not just aggregate all tokens at a single rate.
Pure per-token billing also creates a specific customer anxiety problem: costs are hard to predict before building. A developer integrating your API doesn't know their token consumption until they've written and tested their prompt pipeline. This uncertainty slows adoption and increases pre-sales friction. It's one of the main reasons credit packs have become the dominant alternative.
The Credit Pack Pattern
Credit packs trade precision for predictability. Instead of billing customers for exact token counts at the end of the month, you sell them a bundle of "credits" upfront. Credits are consumed by API calls at a fixed rate (which you set based on your expected token consumption per call type). Customers can buy $50, $200, or $500 credit packs and spend them down at their own pace.
The GTM advantages are substantial. Credit packs lower purchase friction — a one-time $50 purchase has less psychological friction than an open-ended monthly bill. They're compatible with corporate procurement processes that can approve one-time purchases but have longer cycles for recurring subscriptions. They create natural expansion revenue: customers who run out of credits buy more, and the buy-more decision is frictionless because the product is already integrated and delivering value.
Billing system requirements for credit packs differ from subscription billing. You need:
- A credit ledger per customer: every purchase adds credits, every API call debits credits. The ledger must be append-only (for auditability) and eventually consistent with your metering pipeline.
- Real-time balance checks: if a customer is out of credits, API calls should fail gracefully (or succeed with a warning) rather than continuing to rack up charges the customer hasn't paid for.
- Credit expiry logic: if you offer promotional or trial credits with an expiry date, your billing system must handle expiry correctly — expired credits cannot be reactivated, and expiry timing must be deterministic.
- Refund handling: if a customer requests a refund for unused credits, the reconciliation between their credit balance and any past invoices must be calculated correctly.
We're not saying credit packs are always better than per-token billing. For API-first products with technically sophisticated buyers who are building infrastructure (not applications), per-token billing is often preferred — these buyers want full precision and are comfortable with variable invoices. Credit packs are better for application developers and less technical buyers who need cost predictability to write a budget proposal.
Rate Limit Design as a Pricing Lever
Rate limits and pricing tiers are deeply intertwined in AI API products. Rate limits serve three purposes simultaneously: cost control (preventing a single customer from consuming disproportionate compute), quality-of-service (protecting latency for other customers), and pricing differentiation (charging more for higher rate limits as a feature).
The standard tier structure for AI API rate limiting uses two dimensions: requests-per-minute (RPM) and tokens-per-minute (TPM). A free tier might allow 60 RPM / 100,000 TPM. A paid tier at $100/month might allow 600 RPM / 1,000,000 TPM. An enterprise tier at custom pricing might offer dedicated capacity with no shared-rate-limit constraints.
Rate limits as a pricing lever works best when the limits are genuinely constraining for the use cases your higher-tier customers are building. If no real-world production use case hits your free tier's rate limit, the rate limit isn't a conversion signal — it's just friction. The goal is to set rate limits where growing customers naturally outgrow the lower tier during normal usage of their production system, creating an organic upgrade trigger without artificial throttling.
Compound Consumption Models: Beyond Single-Dimension Billing
As AI products mature, purely token-based or request-based pricing often becomes too coarse-grained to correctly represent value. A multimodal API might need to price image inputs differently from text inputs, audio processing differently from both. A long-context model charges differently for 4K-token contexts vs 128K-token contexts because the actual compute cost differs by an order of magnitude.
The emerging pattern for mature AI API pricing is compound consumption models: multiple metered dimensions, each with its own rate, combined into a single invoice. The billing infrastructure requirement for this is non-trivial — your pricing engine must support multi-dimensional rate cards that can be applied to events with heterogeneous properties.
An example rate card in a compound model:
model: text-gen-v3
rates:
- dimension: input_tokens
unit: 1000 tokens
price_usd: 0.003
- dimension: output_tokens
unit: 1000 tokens
price_usd: 0.012
- dimension: context_window
tiers:
- max_tokens: 8192
multiplier: 1.0
- max_tokens: 32768
multiplier: 1.8
- max_tokens: 131072
multiplier: 3.2The implementation challenge is that each API call now produces multiple billing line items, and the invoice must correctly aggregate these into a readable summary while preserving per-dimension detail for customer auditing. If a customer disputes their invoice, they need to be able to trace specific charges back to specific API calls. This traceability requirement drives the schema design of the underlying event store — each event must carry enough metadata to reconstruct any individual charge.
The teams that get AI API monetization right are the ones that think about billing architecture at the same time they design their API schema. The metering events you need for billing are almost identical to the observability events you need for product analytics. Building both on the same event schema from the start is substantially cheaper than retrofitting billing instrumentation onto a product that was initially built with only product analytics in mind.
