What this tool tells you
Four numbers determine an LLM API bill: how many requests you make, how big the prompt is, how long the answer runs, and how much of the prompt the provider has already cached. Feed those in and this page prices every model we track side by side, using rates read from each provider’s own documentation on the date shown beside them.
The reason to compare rather than calculate a single model is the spread. Between the cheapest and dearest model in the same table, at identical volume, the monthly figure routinely differs by two orders of magnitude. That gap is a product decision, not a rounding error.
Getting the inputs right
Requests per month
Count API calls, not users. An agent that loops five times per user action makes five requests, and a retry on failure makes six. Teams underestimate this line more than any other.
Input tokens per request
This is the whole request, not the user’s message: system prompt, conversation history, tool definitions, retrieved documents. In a retrieval-augmented setup the retrieved chunks usually dominate everything else. Measure a real one in the token counter rather than guessing — guesses here are wrong in the expensive direction.
Output tokens per request
Note this is what the model actually generates, which is not your max_tokens ceiling. If you have production logs, use the median. If you do not, generate twenty representative answers and count them.
Cached share of input
If your requests share a stable prefix — a long system prompt, a fixed document, a tool schema — providers will charge roughly a tenth of the base input rate for that portion on subsequent calls. A chatbot with a 2,000 token system prompt and 200 tokens of user text is around 90% cacheable, and moving that slider is the single largest saving available on this page.
Reading the comparison
Sort by monthly cost and look at the shape of the table rather than only the top row. Three patterns show up repeatedly:
- Output-heavy workloads reshuffle the ranking. Summarisation and classification are input-heavy, so cheap-input models win. Generation and code-writing are output-heavy, and the ranking inverts.
- Caching flattens the field. At 90% cached input, models separate almost entirely on output price, and several expensive-looking options become competitive.
- The cheapest model is rarely the cheapest solution. A weaker model that needs two attempts, a longer prompt, or a human correction costs more than the table shows. Price the workflow, not the call.
What this does not include
These are standard on-demand rates. Not modelled here: the roughly 50% discount most providers offer for asynchronous batch processing, negotiated enterprise rates, regional or data-residency premiums, per-search charges for server-side tools, and image or audio input priced on a separate scale. Reasoning models add a further wrinkle — their internal thinking tokens are billed as output even though you never see them, so a reasoning model’s real output count can be several times the visible answer. Treat the result as a well-founded upper bound on a straightforward text deployment.
On price freshness
Model prices change without notice, and a stale calculator is worse than none because it is confidently wrong. Every model entry here stores the URL it was read from and the date it was read; both are visible on the model price table. If a figure looks wrong, follow the source link and check — and if the provider has moved, that is a bug worth reporting.