Which AI API Is Cheapest? How to Actually Compare

"Which AI API is cheapest" has no single answer, because cost depends far more on how you use a model than on its headline rate. Two teams on the same model can differ tenfold in spend.

Here is how to compare properly.

The formula

Every provider bills the same way: separately for tokens in and tokens out.

cost per call = (input tokens ÷ 1,000,000 × input rate)
              + (output tokens ÷ 1,000,000 × output rate)

monthly cost  = cost per call × calls per month

Two things fall out of this immediately.

Output is expensive. Output rates typically run three to five times input rates. A prompt that generates long responses costs far more than one with a long input and a short answer.

Volume dominates. A cost per call that looks negligible becomes significant across a million calls. Always calculate at your actual volume, not per request.

Our cost calculator does this across eight models simultaneously with editable rates, since published prices change frequently.

Why headline rates mislead

Tokenizer differences. Each model family tokenizes differently. The same text might be 1,000 tokens on one model and 1,150 on another, so a 10% cheaper headline rate can be a wash in practice.

Verbosity differences. Models differ substantially in how much they write by default. A model with a lower output rate that produces 50% longer answers is not cheaper. Cap output length explicitly and this variable disappears.

Reasoning tokens. Reasoning models generate extensive internal deliberation you pay for even when it is not displayed. A reasoning model at the same nominal rate can cost several times more per request.

Caching. Providers offering prompt caching can be dramatically cheaper for workloads with a large stable prefix — often 75-90% off cached input. If you send the same long system prompt every time, this can outweigh a rate difference entirely.

The four changes that actually cut bills

In rough order of impact:

1. Route by difficulty. This is the big one. Most workloads do not need a flagship model. Classification, extraction, tagging, routine summarisation and simple generation run perfectly well on small models at a small fraction of the cost. Send hard reasoning to the expensive model and everything else to the cheap one, and total spend often drops by more than half.

2. Cap output length. Because output costs several times input, "respond in under 100 words" is a direct and immediate saving. Most applications generate far more text than anyone reads.

3. Cache stable prefixes. Put unchanging content — system prompt, examples, reference documents — at the start of every request so it can be cached, and variable content at the end. A timestamp at the top of your prompt defeats caching entirely.

4. Trim retrieved context. RAG pipelines routinely stuff ten chunks into a prompt when three would answer the question. Reranking retrieved candidates and passing fewer, better ones cuts input cost and usually improves answer quality at the same time.

What about self-hosting?

Open-weights models eliminate per-token cost, replacing it with infrastructure cost. The maths depends almost entirely on utilisation.

At low or spiky volume, hosted APIs win comfortably. You pay only for what you use and nothing when idle.

At high sustained volume, self-hosting can be substantially cheaper — but budget for GPU cost, engineering time, monitoring, and the ongoing work of keeping it running. The infrastructure is rarely the expensive part; the attention is.

Self-hosting also buys things unrelated to cost: no data leaving your environment, no rate limits, and no provider deprecating the model you built on.

A practical process

1. Measure your actual input and output tokens per call with the token counter.
2. Multiply by real monthly volume.
3. Compare across models using current published rates.
4. Then optimise: route by difficulty, cap output, cache prefixes, trim context.

Teams almost always find that step 4 saves more than steps 1-3 combined. The cheapest API is usually the one you are already using, used more carefully.