Why prepaid wallets fit AI APIs better than subscriptions

Every AI API gateway eventually faces the billing question. Subscription tier? Pay-as-you-go? Credits? Some hybrid? The major unified gateways (OpenRouter, Onlist, several others) have all landed on the same answer: prepaid wallet credits, billed per call. This post explains why that convergence happened.

The shape of AI request cost

A typical REST API has a roughly fixed per-call cost. A user query, a database lookup, a JSON response. You can price it by call volume and the unit cost barely moves.

AI calls don't behave that way. The cost of a single call depends on the input length, the output length, whether tools were invoked, whether the request was streamed, whether the model is GPT-5 or DeepSeek V3. A summarization request costs less than a long-form generation. A vision call with a high-resolution image costs more than text only.

The cost-per-call distribution is heavy-tailed. The median call is cheap, the 99th percentile is many multiples more expensive. Any pricing model has to handle that tail.

Why subscriptions misprice the long tail

A flat subscription tier picks a single number to represent average call cost and multiplies by an expected call volume. It then either underprices heavy users (and loses money on them) or overprices light users (and loses them as customers). The heavy-tailed distribution makes the safe middle ground vanishingly small.

Tiered subscriptions reduce the problem but do not eliminate it. They also lock users into commitments that do not match how AI calling patterns actually shift. A team that experiments with three different models over a week ends up paying for tier headroom they never used.

The cleanest evidence that subscriptions are a bad fit: no major unified AI gateway uses them as the primary billing model. The pattern is too risky for the provider, too restrictive for the buyer.

Why pay-as-you-go without prepayment is also painful

The other extreme is straight metered billing: invoice the buyer monthly for whatever they consumed. This works for established companies with predictable budgets and accounts payable cycles. It does not work for the developer who wants to try an AI gateway tonight.

A new buyer with no credit history is a credit risk. Monthly invoicing requires the gateway to advance the cost of upstream calls and hope the buyer pays. Fraud is real. Disputes are real. Settlement delays are real.

For most consumer-developer products in this space, the friction of "give us a credit card we'll charge monthly" is higher than the friction of "prepay a small amount, we'll deduct as you go."

Prepaid wallets thread the needle

Prepaid wallet credits combine the parts of each model that work:

• The buyer gets metered pay-as-you-go pricing per call, matching the real cost distribution.
• The gateway gets no credit risk; calls are debited from already-collected funds.
• The buyer is not locked into a commitment; balance does not expire.
• Heavy users top up more often, light users top up less, the pricing self-adjusts.

For AI APIs specifically, the wallet model also matches how teams think about AI spend. AI calls are budget items, not subscription items. A team that allocates $200 a month to experimentation tops up $200, watches the burn, and tops up again when needed. The wallet balance is a budget ledger, not a recurring charge.

What good wallet design looks like

The minimum viable prepaid wallet design has:

• A clear balance display, including a forecast of how long current balance lasts at recent usage rate
• Multiple top-up methods (card, crypto, gift codes), so payment friction never blocks a useful call
• No expiration on credits, so trust does not erode over long inactive periods
• Real-time spend visibility, so the buyer can audit calls against the balance

Onlist's wallet is built around these four principles. It also accepts stablecoin top-ups (USDT via NowPayments), which matters for buyers in regions where card payment to a foreign service is impractical. The crypto path is not a marketing checkbox; it is the only way some buyers can pay at all.

When subscriptions might still make sense

There is one scenario where a flat subscription works: a buyer with predictable, capped usage that matches the subscription tier. Enterprise contracts with negotiated rate caps. Internal tooling with fixed daily call budgets.

For those cases, custom contracts make more sense than productized subscription tiers. The buyer and the gateway can agree on a flat rate that matches the actual usage profile, with overage clauses for the long tail.

For everyone else (solo developers, small teams, fast-moving products), prepaid wallets remain the model that respects the cost shape.

Top up your wallet →