LLM API price calculator with the cache hit rate priced in

Price your workload

Break even between two models

List prices per one million tokens

Every figure below is the provider's standard list price in dollars per one million tokens, fetched on 2026-09-06. Batch, cached input write, long context and reasoning surcharges are not included. The cached input column is the cached read price only.

Google's pricing page lists the Gemini 3.8 Flash, 3.7 Flash and 3.6 Flash rates in this table as valid through December 31, 2026, with higher rates starting January 1, 2027, so those three rows change on that date (Gemini API pricing).

Primary record, the OpenRouter models API, which returns an array of Model objects and states all pricing values in USD per token. In each record the prompt field is the price for input processing and the completion field is the price for output generation, and the live response carries an input_cache_read key for the cached read price. Independent cross check, the LiteLLM model price table, which stores each provider's published prices under input_cost_per_token and output_cost_per_token. The last two columns are computed in your browser from the three prices in the row.

Which published prices disagree

A row appears above only when the OpenRouter record and the LiteLLM record agree within one percent after both are converted to dollars per one million tokens. Two models were left out before the run. GPT-5.6 Sol was left out after a probe on 2026-09-06 showed the two records differ by roughly a factor of two on its price. DeepSeek V4 was left out before the run because the same probe showed the two records disagree on its price, which its hosts set differently, so the two record rule cannot clear it. Ten listed models, GPT-5.5 Pro, GPT-5.4 Pro, GPT-5.2 Pro, GPT-5 Pro, o3 Pro, o1 Pro, GPT-4 Turbo, GPT-4, GPT-3.5 Turbo and Mistral Medium 3.5, have no cached input price in their OpenRouter record, so their cache cell reads not in the OpenRouter record and the calculator treats the cache hit rate as zero for them. Three more cached input prices are held rather than shown: GPT-5.1 Codex and GPT-5.1 Codex mini because the two records disagree on the cache read price, and Devstral 2 because only one record carries one. Their input and output prices passed, so those rows stay, with the cache hit rate treated as zero for them. For Mistral Medium 3.5 the LiteLLM table does carry a cached price, but one record alone does not clear the two record rule, so no figure is shown. No figure is shown for a held value, on purpose. A number the two records can't agree on isn't a number you should plan against.

Every model at your workload

The table below ranks every validated model by monthly cost for the token shape, request volume and cache hit rate you entered above. The order isn't a verdict from this page. It's arithmetic on your inputs, and it changes as they do. Providers price input, cached input and output tokens separately, so a model that leads on a short prompt with a long reply can fall several places on a long cached prompt with a short reply. Move the output tokens or the hit rate and watch the rows reorder.

Three worked shapes

Each card states its own token counts and its own assumed cache hit rate, and prices a month of one thousand requests a day on the model you selected in the calculator. Change the model up top and all of them recompute.

Common questions

How the price per request is computed

The calculator multiplies your input tokens by an effective input price, adds your output tokens times the output price, and divides by one million. The effective input price is the list input price weighted by the share of input tokens that miss the cache, plus the cached input price weighted by the share that hit. OpenRouter states all pricing values in USD per token, so the page converts to dollars per one million tokens in code before anything is displayed. If you count characters rather than tokens, Anthropic gives a rough estimate of about four characters or three quarters of a word per token in English, and Moonshot estimates roughly three to four English characters per token for typical English text.

Why cached input is cheaper and how each provider bills cache writes

A cached read reuses a prompt prefix the provider already processed, and in every row of the table above the cached read price sits below the base input price. Writes are a different story and vary by provider. Anthropic bills prompt cache writes at 1.25x or 2x the base input price and cache reads at a fraction of it. Google charges a separate per hour storage price for context caching on top of the cached token price. OpenAI discounts reused input tokens by up to ninety percent through prompt caching, and the discount only applies once a prompt prefix reaches a minimum cacheable length, just over a thousand tokens for GPT-5.6 and later and about double that for older models. Mistral says cached input tokens cut input cost by up to ninety percent. None of those write charges or minimums are in the calculator, which is why the cache hit rate is a number you enter and not one the page predicts.

What a list price leaves out

• Batch routes. Anthropic's Batch API gives a half price discount on both input and output tokens, Google's Gemini Batch API is offered at a half price reduction versus standard pricing, OpenAI's Batch API offers a half price discount versus its synchronous APIs, and Mistral's batch processing cuts the price by half.
• Long context. Some Gemini models charge a higher input rate on prompts above a two hundred thousand token threshold, and on xAI models with long context pricing a request whose prompt reaches the threshold is billed at the higher rate for every token in the request. Anthropic's pricing page says a 900k token request is billed at the same per token rate as a 9k token request.
• Reasoning. Google bills Gemini thinking tokens as output tokens, so a reasoning heavy call carries more output tokens than the visible reply.
• Tool use. Anthropic adds tool definition and tool result tokens to the billed input and output counts.
• Tokenizers. Anthropic's pricing page says Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text, and that Claude Sonnet 4.6 and earlier models use the previous tokenizer, so the same prompt can bill a different token count across model generations. Type the count your own usage logs report, not a count from another model.

Why the break even moves when the cache hit rate moves

Two models rarely discount their cached input by the same fraction of their list input price. So raising the hit rate lowers the two input costs by different amounts while leaving both output costs alone. The output share at which the two tie has to shift to keep the balance, and it can shift enough to flip which model is cheaper for the same token shape. Run the break even tool at a low hit rate and again at a high one and you'll see the crossover slide.

Why open weight models are missing

The roster is first party API models where one provider publishes one list price that two records can be checked against. An open weight model is served by many hosts at many prices, so the two records rarely agree on one figure. DeepSeek V4 was left out for exactly that reason. Use the custom entry in the model select to cost any host's rate you've been quoted. If you are sizing a self hosted model instead of buying tokens, the LLM memory calculator covers that side.

How often prices are refreshed

Both records are re fetched every time the page is rebuilt, and the fetch date beside the table is the date the record you're reading was pulled. LiteLLM describes its table as a community maintained list, so the cross check is independent of OpenRouter but isn't a provider document. Both are linked under the table so you can open them and read the per token strings yourself.

Whether this page sends any data

No. Every figure is computed in your browser from the prices baked into the page at build time and the numbers you type. No request leaves the page when you change an input, and nothing you enter is stored.

Where every number on this page comes from

Every list price on this page is fetched, not typed. The primary source is the OpenRouter models API record for each model, which publishes the prompt and completion price per token as a decimal string, plus an input_cache_read price for the cached read. The independent cross check is the LiteLLM model price table, a separately maintained JSON file that records each provider's published input and output cost per token under input_cost_per_token and output_cost_per_token. Both values are converted to dollars per one million tokens in code. A model whose two sources disagree by more than one percent is held and never shown. Everything the calculator returns is computed in your browser from the validated per million prices and the token counts you type.

I run scheduled production jobs against pay per token model APIs on a prepaid balance. I've watched a fleet's per cycle budget of about three dollars outrun a balance of one dollar and change, and the jobs stopped mid cycle. That's why this page prices a whole workload per day and per month rather than a single request, and why the cache hit rate is a first class input. I read the price of every model listed here straight from the provider records rather than from a pricing page screenshot.