Clawy / Guides / Pricing a paid AI API

How to price a paid AI API without losing money

If you resell or wrap GPT or Claude at a flat per-call price, a single large prompt can cost you more than you charge. Here's the math, and two ways to fix it.

You wrapped an LLM, put it behind an endpoint, and charge a tidy flat price — say $0.15 per call. Clean for your customers, easy to reason about. The problem: the model underneath you doesn't bill per call. It bills per token, and tokens scale with prompt and response size. On a small request you pocket a fat margin. On a big one you can pay more than you collected — and you won't notice until the provider invoice lands.

Why flat pricing leaks

Token-billed models charge separately for input (the prompt you send) and output (what the model generates). Per the official list rates for Claude:

Your cost for one call is simply:

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

Take Opus 4.8 at a flat $0.15/call. Output alone runs $25 per million tokens — so just 6,000 output tokens costs $0.15, eating your entire price before you've counted a single input token. Let a customer send a 100,000-token document as context and ask for a long answer, and that one call can cost you several times what you charged. Multiply by a few power users and the "profitable" product runs at a loss.

Find your break-even before you ship

The number that matters is the largest prompt you can serve before a call costs more than you charge. Holding output size fixed, the break-even input size is:

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

For Opus at $0.15 with an 800-token answer: (0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 input tokens. Past ~26k tokens of prompt, every call loses money. If your real traffic regularly exceeds that, flat pricing is the wrong model — or your price is too low.

Fix #1 — cap input and output

If you want to keep flat pricing (customers love its predictability), bound both sides so the worst-case call can't exceed your price:

• Cap input size. Reject or truncate prompts above a token/character limit — and do it before you charge or call the model, so an oversize request costs you nothing.
• Cap output (max_tokens). A generous default still bounds the expensive side. At $25/1M, every 1,000 output tokens is $0.025.
• Size the caps from the math above. Pick limits where worst-case cost < price with margin to spare for retries, fallbacks, and prompt-cache misses (budget ~25–40% headroom).
• Advertise the limits. Put the input/output caps in your API schema so clients self-limit instead of hitting surprise rejections.

This is exactly how a flat-priced endpoint stays solvent: the price is fixed, but the work behind it is bounded so it can never run underwater.

Fix #2 — usage-based pricing

The alternative is to stop pretending calls are uniform and bill for what they actually consume: meter tokens (often with a markup multiple over your cost) or charge tiered prices by request size. You give up the simplicity of one round number, but you can never lose money on a big request because the price moves with the cost. Usage-based is the right call when prompt sizes vary wildly or you serve large-context workloads.

Don't forget the hidden costs

• Retries & fallbacks. A failed call that retries on a second model can double the token spend for one customer-visible request.
• Prompt-cache misses. Caching cuts repeated-prefix cost ~90%, but only on hits — a silent cache invalidator (a timestamp in the system prompt, unsorted JSON) means you pay full price every time.
• Thinking / reasoning tokens. If you enable extended/adaptive thinking, those tokens bill as output too.

Whichever model you choose, the discipline is the same: know your per-call cost, know your break-even, and bound the worst case before it reaches a paying customer.