LLM Cost Calculator
Price a real workload across GPT and Claude models — requests per day, tokens in and out, and the prompt cache hit rate that usually decides the bill.
Workload
Prices read
2026-07-28GPT-4o: $2.50 in, $10.00 out, per million tokens. Cache reads $1.25.
Source: developers.openai.com. Context windows from developers.openai.com and platform.claude.com. Prices change — check before committing to a budget.
GPT-4o
2,500 tokens per request$3,000
300,000 requests (30-day month).
- Input
- $1,500
- Cached input
- —
- Output
- $1,500
Input uses 1.6% of the 128,000-token context window.
Every model, cheapest first
per month| Model | Context | Per month | vs selected |
|---|---|---|---|
| 128K | $180.00 | 94% less | |
| 16.385K | $525.00 | 83% less | |
| estimated | 200K | $1,350 | 55% less |
| estimated | 1,050K | $1,500 | 50% less |
| 128K | $3,000 | — | |
| estimated | 1,050K | $3,750 | 1.3× |
| estimated | 1,000K | $4,050 | 1.4× |
| estimated | 1,000K | $6,750 | 2.3× |
| estimated | 1,050K | $7,500 | 2.5× |
| estimated | 1,000K | $13,500 | 4.5× |
| 200K | $18,000 | 6.0× |
Arithmetic only — no API is called and nothing is uploaded. If you need the token count for a real prompt rather than an estimate, the Prompt Token Counter counts it exactly with a real tokenizer, then feeds the number back here.
About the LLM Cost Calculator
This LLM cost calculator answers a different question from a token counter: not what one prompt costs, but what a workload costs per month, and which model is cheapest for it. Enter requests per day, tokens in, tokens out and your cache hit rate, and every model in the catalogue is priced and ranked against your numbers.
Prompt caching is modelled, because it is usually the largest single lever on a real bill — a cache read costs roughly a tenth of a normal input token at both providers here. A calculator that ignores caching overstates the cost of every workload with a long system prompt, which is most of them. Move the slider and watch the ranking change: the cheapest model at 0% cached is often not the cheapest at 80%.
Context limits are enforced rather than ignored. A model that cannot fit your input is not a cheaper option, so it is ranked last and shown as too small instead of appearing at the top on the strength of a low per-token price.
Every price carries the date it was read and a link to the provider's own page. Model pricing changes without much notice, so treat any figure here as a starting point and check the source before committing to a budget.
- Per-request, per-day, per-month and per-year totals from one set of inputs
- Every model ranked cheapest first, with the difference against your selection
- Prompt cache modelled as a percentage of input tokens, priced at the provider's cache rate
- Input, cached input and output costed separately, so you can see where the money goes
- Context window and max-output limits checked — a workload that would be rejected says so
- Estimated token counts marked as estimates rather than presented as exact
- Every price dated and linked to the provider's published pricing
How to use it
- Pick a model, then enter your requests per day.
- Enter average input and output tokens per request. Input means everything you send — system prompt, conversation history and the user's message.
- Set the cache hit rate if you use prompt caching. If you do not know it, the share of your input that is identical between requests is a good first estimate.
- Switch between per-request, per-day, per-month and per-year to sanity-check the numbers at both ends.
- Read down the comparison table. Click any model name to make it the selected one and see the split for it.
Real-world use cases
AI product & engineering leads
Build a defensible monthly cost estimate for a new LLM feature before committing to a model, with caching modelled rather than glossed over.
Backend & platform engineers
Compare the real cost of switching a workload from one model to another at actual production volume, instead of comparing sticker price per million tokens.
Finance & budget owners
Get a per-month and per-year figure for an AI feature's API spend to include in a budget, with every price dated and linked to the provider's own page for verification.
Startup founders & indie developers
Sanity-check whether a planned feature's usage volume is affordable before building it, catching a workload that would exceed a model's context window before writing any code.
AI & ML engineers
Model the effect of prompt caching on a specific workload's bill before implementing it, to decide whether the engineering effort is worth the saving.
Examples
A moderate production workload
Model: GPT-4o Requests: 10,000 / day Input: 2,000 tokens Output: 500 tokens Cached: 0%
Per request: $0.010000 Per day: $100.00 Per month: $3,000 Per year: $36,500
Input dominates: 2,000 input tokens against 500 output. Most real chat workloads are input-heavy, which is why caching matters so much.
The same workload with caching
Cached: 80%
Input: $10.00 / day Cached input: $4.00 / day Output: $50.00 / day Per day: $64.00
A 36% saving from one slider, with no change to the model or the prompt. This is the number most cost estimates leave out entirely.
A request that does not fit
Input: 300,000 tokens Model: a 128K-context model
300,000 input tokens exceed this model's 128,000-token context window. The request would be rejected. In the table: context "too small", cost "—"
The model is not listed as a cheap option, because it is not an option. Ranking it on price would be actively misleading.
Output tokens above the per-response cap
Output: 100,000 tokens
100,000 output tokens exceed the 16,384-token maximum this model will generate in one response.
The context window and the maximum output are different limits, and hitting the second one truncates your response rather than erroring.
Common errors
| Message | Cause | Fix |
|---|---|---|
| The bill is far higher than the estimate | Almost always input tokens: conversation history is resent on every turn, so a chat's input grows with the conversation while the per-request figure was estimated from turn one. | Estimate input from a full conversation, not a single message. Then look at caching or a sliding history window — both attack the same cost. |
| The estimate is higher than the bill | Caching left at 0% when the provider is caching a repeated system prompt, or a shorter average response than assumed. | Set the cache rate to the share of input that repeats between requests. Output tokens are also usually overestimated — measure the mean, not the maximum. |
| The cache slider does nothing | The selected model publishes no cache price, so there is no cached rate to apply. | The tool says so rather than inventing a discount. Every input token is priced at the full rate for that model. |
| Two models look identical in cost but behave differently | Input and output are priced differently, often by a factor of four or more, so two models can tie on a balanced workload and diverge sharply on an output-heavy one. | Compare with your real input-to-output ratio rather than a round number. Watch the input and output rows in the split, not just the total. |
| A per-request cost shows as $0.000001 | The real cost is below a millionth of a dollar and is being shown at the floor rather than rounded to zero. | Nothing to fix — it is deliberate. Rounding a paid API call to $0.00 is the single most common failure of these calculators, so the floor exists to avoid telling you something paid is free. |
| A token count is marked estimated | That model's tokenizer is not public, so token counts come from a calibrated ratio against a known encoding rather than from the real vocabulary. | Treat the figure as a band rather than a number. The Prompt Token Counter explains which models can be counted exactly and which cannot. |
Frequently asked questions
›Is anything sent to a provider?
No. This is arithmetic over a price table that ships with the page — no API is called, no key is needed, and nothing you type is uploaded. That also means it cannot read your actual usage; it prices the workload you describe.
›How is this different from the Prompt Token Counter?
The counter starts from text: paste a prompt, get an exact token count, and see what that one request costs. This starts from volume: you already know roughly how big your requests are, and you want the monthly bill and the cheapest model that fits. Use the counter to get an accurate token number for a representative prompt, then bring that number here and multiply it out.
›How current are the prices?
Each row carries the date it was read and links to the provider's own pricing page — the dates are in the panel under the model selector. Provider pricing changes with little notice and new models arrive constantly, so anything here can go stale. The links are there because you should check before you commit to a number, not because the figures are unreliable today.
›What exactly counts as an input token?
Everything you send: the system prompt, every previous message in the conversation, any tool definitions, retrieved documents, and the user's current message. This is where estimates usually go wrong — a chat application resends its whole history on every turn, so input grows through a conversation while output stays roughly constant. Chat endpoints also add a few tokens of framing per message, which is small but not zero.
›How do I work out my cache hit rate?
Start from the share of your input that is byte-identical between consecutive requests — typically the system prompt and any fixed examples. If a 2,000-token request has a 1,600-token fixed prefix, 80% is the ceiling. Real rates come in lower because caches expire, so estimate the ceiling here and then discount it. Both providers also require a minimum prefix length before caching applies at all.
›Why is a 30-day month rather than a calendar month?
Because it makes the arithmetic legible and comparable. A calendar month varies by 10% between February and March, which would make two months of the same workload look like a change in usage. The per-year figure uses 365 days for the same reason. If you need a real month, use the per-day figure and multiply.
›Does it account for batch discounts or reserved capacity?
No. Both providers offer roughly 50% off for asynchronous batch processing, and there are volume and committed-use arrangements that are not public. Those are not modelled, so the figures here are standard on-demand pricing — which is the right basis for a first estimate and an upper bound on what the same workload would cost through a batch queue.
›Should I budget for the average or the peak of my workload?
Both, separately. The average requests-per-day figure gives a realistic monthly bill; a second pass with your peak daily volume gives the ceiling you should actually budget against, since LLM usage is rarely flat and a launch, a marketing push or a batch job can spike request volume well above the daily average.
Last updated