Dollars per million tokens is a unit invented for comparison shopping. What hits your card depends on how much you generate, how much of your prompt repeats, and which half of the traffic you forgot to count.
Change any number and everything below recalculates, including how the rest of the market handles the same traffic.
Millions of tokens
Millions of tokens
% of input served from cache
Only applied where a batch rate is published
Estimated monthly spend at the token mix above.
| Model | Monthly | vs cheapest |
|---|
Only models with a verified price are listed. Anything unverified is excluded rather than estimated.
Self-hosting swaps a variable cost for a fixed one. It only wins above a crossover volume — and it loses outright if the box cannot physically push that much traffic. This runs both checks.
Rental rate, USD/hour
% of the month it is running
% on top, for storage and people
Input tokens per output token
Output tokens/sec per GPU — measure it
They do not guess your token mix. A chatbot and a document pipeline with identical spend have completely different input/output shapes, and any default we picked would be wrong for one of them.
They do not model quality. Cheapest-per-token is not cheapest-per-solved-problem — if a cheap model needs three retries, the retry tokens are on your bill too.
They do not include the costs that never appear on a pricing page: the engineering week to stand up vLLM, the on-call rotation, the eval suite you need before you can safely change a model version. The ops-overhead field exists because that number is real, and it is usually bigger than people expect.
One honest limitation: throughput is the input that swings the break-even result hardest, and it is the one almost everybody overestimates. Measure it on your own workload before you believe the answer.