Estimate the token cost of the workload your application actually sends. Compare candidates with the same assumptions, inspect the source dates and keep unsupported charges separate.

Calculate a workload

Interactive tool

Estimate your API costs

Your text and estimates stay in this browser. No API requests are sent to model providers.

Loading verified model records…

Start with a request you can describe

A useful LLM cost calculator begins with an application task, not a provider logo. Write down what the request receives and what a successful response must contain. For a support workflow, that might be the current question, relevant policy passages and a concise answer. For extraction, it might be a document and a schema. For coding, it might be a change request and the necessary project files. Each shape produces a different relationship between input and output.

Select the exact model candidate, then enter representative input and output token assumptions. If the application already runs, use its returned usage records to choose those assumptions. Keep an ordinary case and a demanding case. An average alone can hide a small group of expensive requests, especially when documents and generated answers vary widely. If the application is still a prototype, label the values as planning assumptions and replace them after a controlled evaluation.

Use the token counter to inspect a safe text fixture before estimating. A text-only count is not a complete measurement of every request field or media attachment. Keep the model, tokenizer choice and counting scope visible in your notes so a later discrepancy can be investigated rather than explained away.

Read the cost breakdown

Provider pricing distinguishes charge categories such as ordinary input, cached input and output, with additional categories for supported tools or media. Official documentation.

The calculator multiplies each supported category by the applicable stored rate and the workload assigned to it. The request estimate answers what one assumed call costs. Daily and monthly views apply the selected request volume and displayed period assumption. Read the category breakdown before using the total: it reveals whether a change came from the model rate, output length, cache assumption or traffic volume.

The selected comparison unit matters. A rate per token cannot stand in for a rate per image, character, request or unit of time. Where the live record does not support a required charge category, treat the result as a partial estimate and retain that unresolved item. Do not interpret an empty category as a free service. The source link beside a stored value is the place to check what the provider actually bills.

A lower input rate does not always create the lower workload total. A response-heavy task can be more sensitive to output pricing, while document analysis can be more sensitive to input and reuse. Compare candidates on an identical fixture and output requirement. If one candidate regularly needs repair calls, include that work in a separate measured scenario rather than silently declaring it the cheapest application.

Model caching and batch use deliberately

Claude documents distinct cache-write and cache-read treatment, so repeated input should not automatically be priced as a cache hit. Official documentation.

Enter a cached-input share only when the request structure and provider feature make reuse plausible. Start with an uncached baseline, then add a scenario informed by measured cache behavior. Keep initial writes, expiration and changed prefixes in mind when evaluating the difference. A long conversation that changes continuously is not automatically equivalent to a stable reusable document prefix.

Gemini pricing identifies caching and batch categories separately; the relevant feature and model conditions still govern whether a workflow can use them. Official documentation.

Use the batch option for work that can follow the documented asynchronous path. It should not serve as a discount checkbox for a request your application still sends synchronously. Compare the operational consequence as well as the amount: delayed results may suit a nightly document job while failing an interactive response requirement. Preserve both the processing mode and the selected model in the saved scenario.

Try the application presets

The chatbot preset provides a starting shape for conversational work. Replace its assumptions with the history and retrieved material the application actually includes, and estimate how response length changes across ordinary and difficult questions. Keep repeated conversation turns distinct from independent single-turn calls when building the traffic forecast.

The summarization preset is useful for thinking about document input and a controlled output. Test whether the required facts survive the summary, then count the accepted response. If the application splits a document, performs a merge step or revises an incomplete result, include those stages. A single-call budget should not be presented as the total for a multi-stage pipeline.

The coding-assistant preset is a planning aid for supplied context and generated code. Use the smallest relevant project fixture, then add the checks needed to accept a patch. Record unsuccessful attempts when evaluating cost per completed change. Model pricing alone cannot establish which candidate will produce a correct patch for your repository.

Compare, share and revisit

Keep the same workload assumptions when adding candidates to a comparison. Use the copied table to preserve model identity, category amounts and verification dates with your decision. A shareable calculator URL makes the encoded assumptions reproducible, but recipients should still inspect the live rate dates when reopening it. A saved link does not freeze a provider’s future pricing.

Revisit the estimate when model choice, prompt structure, output policy or traffic changes. Review the price-history record separately from your own workload changes: otherwise it is easy to blame the provider for a larger total caused by longer answers or additional application stages. Preserve the previous assumptions so the reason for the difference remains clear.

Treat the result as an engineering estimate. It does not promise a final invoice or account entitlement. Any applicable account terms, credits, taxes and unsupported hosted-feature charges need their own review. Before unattended usage, use the provider’s actual account controls and define an application stop condition. The calculator helps explain a plan; it does not enforce a spending boundary in the provider account.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Last verified · Source ↗

Frequently asked questions

Is this an OpenAI cost calculator or a Claude cost calculator?
It can compare published supported model records across providers. Select the exact model and inspect its source and charge categories.
Why does output length change the estimate so much?
Input and output can have different rates. A response-heavy workload may therefore respond differently to a model change than a document-heavy workload.
Can I assume all repeated text is cached?
No. Use the provider’s caching conditions and measured reuse to justify the cached-input share.
Does enabling batch change my application requests?
No. The estimate assumes an eligible batch workflow; you still need to implement the documented asynchronous request path.
What if a price is missing?
Treat the category as unresolved. Missing data must not be counted as a free charge.
Does a shared link preserve old prices?
It preserves encoded assumptions. Inspect the live verification date because the underlying reference can change.
How can I make the forecast more realistic?
Use returned usage from representative accepted tasks, retain demanding cases and include additional calls required by the application.
Does the estimate enforce a budget?
No. Configure the provider’s account controls and your own application stop conditions separately.

Sources

Last verified · Source ↗