AI Prompt Cost Calculator

Most cost calculators for AI make you do the annoying part yourself. You look up a price, type it in, get one number, then repeat the whole thing for the next model. Here you start from the model rather than the price. Pick GPT-4o, a Claude model, or Gemini from the dropdown and the per-million input and output rates fill in for you. Enter your token counts once and the comparison table below ranks every built-in model from cheapest to most expensive for that exact prompt. So the real question, which model is actually cheapest for the work you are doing, gets answered on one screen instead of across three pricing pages and a spreadsheet.

That comparison is the part that matters, because a bare per-token price list quietly points you at the wrong model. Output tokens usually cost several times more than input, so a model with a cheap headline input rate can lose badly once it actually starts generating. Tokenizers differ too, which means the same paragraph becomes a different number of tokens depending on which model reads it. The honest way to compare is to price the same prompt through each model and read the totals, which is what the table does.

1. Enter your input tokens. Count everything you send in one call: the system prompt, retrieved context or documents, prior chat history, few-shot examples, and the user's question. It all bills as input.
2. Enter your output tokens. This is the reply length you expect back. If you are not sure, estimate from a typical answer or use the max_tokens cap as an upper bound.
3. Set the number of requests. Leave it at 1 for a single call, or raise it to a daily or monthly volume to turn a fraction of a cent into a real budget.
4. Pick a model. Choose one from OpenAI, Anthropic, or Google and its input and output prices load automatically. Want your own numbers, or a model that is not listed? Choose Custom prices and type the two rates yourself.
5. Flip on Batch API pricing if it fits. For work that can wait, most providers run an asynchronous batch queue at roughly half the standard rate. The toggle applies that discount to your estimate and to every row of the comparison at once.
6. Read the results. The top box shows the cost of your chosen model. The table below prices the same prompt across every built-in model, cheapest first, with the winner tagged.

Every price field stays editable after a model loads, so if a provider changed a rate since these were set you can correct it in place. The built-in rates carry the date they were captured, and you should confirm against the official pricing page before committing a budget, since these numbers move.

Almost every provider charges more for output than input, often three to six times more. It comes down to how the models run. Reading your prompt is one pass over the text. Writing a reply happens one token at a time, and each new token means another pass through the model over everything generated so far, which is more compute per token and so a higher price.

The practical result is that long replies tend to dominate a bill, not long prompts, and they do it on every single call. A wordy system prompt you send once is cheap, because you pay for it a single time. A model that generates two thousand tokens on every answer keeps costing you on each call. When you want to cut cost, capping max_tokens or asking for concise, structured output moves the number more than trimming the prompt does. Watch the "Per request" column with that in mind. A model can look cheap on its input rate and still land near the top of the table once output is priced in.

The table sorts by total cost for your workload, which is the figure that shows up on an invoice. A few habits keep the read honest.

Use realistic token counts, averaged across typical calls rather than a best case. If you want the counts exact instead of estimated, run your actual prompt and a sample reply through a token counter first, then bring those numbers here. Remember that the same text tokenizes differently per model, so a cheaper-per-token model is not automatically cheaper per document.

And think past the raw price. A model that costs more per token but gives shorter, more correct answers can win on total cost by needing fewer retries. The table gives you the list-price ranking, but your own sense of which models one-shot the task matters just as much.

The estimate is list price by default, which is the right baseline. Two provider features can drag the real bill well under it, and most people never switch them on.

Batch processing is the toggle already on the page. Send requests to an asynchronous queue that returns results within a longer window, commonly up to about a day, and you typically pay around half on both input and output. Overnight reports, bulk classification, and data enrichment are natural fits, and the only real cost is the wait.

Prompt caching is the other lever, and it is not a toggle here because the savings depend on your setup. If you send the same large prefix on every call, a system prompt, a fixed instruction block, or a long reference document, providers can bill the reused portion at a small fraction of the normal input rate on a cache hit, often around a tenth, after a small write charge the first time. To model it, lower the input price you enter to reflect how much of your input is cached.

A chatbot resends the whole conversation as input on every turn, so the input token count grows as the chat gets longer, and you pay for all of it each time. If your per-call cost climbs over a session, growing history is usually why. Trim old turns, summarize earlier ones, or use a provider feature that condenses history. When you fill in the input tokens above, use a figure for a typical mid-conversation call, not the first message, or the estimate will run low.