LLM Pricing Calculator: Compare GPT, Claude and Gemini API Costs

“$0.003 per request” is not a budget — it's a fragment of one. An LLM pricing calculator that stops at the cost of a single call answers a question nobody actually asked. The question that matters is a monthly number: requests per day, extrapolated across a real usage pattern, per model, per token type. Get the token count wrong and every other number downstream is wrong too — which is why pricing depends on counting tokens accurately before it depends on anything else. An api cost calculator is only as good as the workload model behind it: average input and output tokens per request, requests per day, and — the variable most back-of-envelope estimates skip entirely — how much of that input gets served from a prompt cache instead of billed cold.

Across every major provider, output tokens are priced several times higher than input tokens — an openai pricing calculator and a claude api cost estimate both show the same asymmetry, just at different rates. That single fact reshapes which features are expensive. A classification endpoint that reads a 2,000-token document and returns one word ("spam" or "not_spam") is nearly all input cost. A writing assistant that reads a 200-token instruction and generates an 800-word draft is nearly all output cost, at the higher rate, on the larger side. Two features with a similar “it just calls an LLM” description can differ by an order of magnitude in monthly cost purely because of the shape of their output — long, free-form generation versus short, targeted judgment — and that shape matters more than most people budgeting a feature initially assume.

• Short-output features — extraction, classification, routing, a yes/no or a single structured field — stay cheap even at high volume, because the expensive token type barely gets used.
• Long-output features— summarization of a full document, drafting, open-ended chat replies — accumulate cost fast, because every generated token is billed at the output rate, and there's no caching lever on tokens the model hasn't written yet.

This is the part a naive token cost calculator leaves out entirely, and it's the single biggest lever on the final number. Most real prompts repeat a large, static prefix on every call — a system prompt, a tool schema, a long set of instructions, a document pasted into context once and referenced many times. Every major provider now discounts that repeated portion steeply on the second and subsequent reads within a caching window, instead of billing it cold every single time. Model that cache hit rate and a workload's real monthly bill can look nothing like the number you get from pricing every request as if the cache didn't exist — the gap gets larger the bigger the reused prefix is relative to the part that actually changes per request.

Inputs
  requests/day        = 10,000
  input tokens/req    = 1,500   (1,200 reusable system prompt + 300 fresh query)
  output tokens/req   = 400
  input price         = $2.50 / 1M tokens
  cached input price  = $0.25 / 1M tokens   (10x cheaper on a cache hit)
  output price        = $10.00 / 1M tokens

No cache modeled — every input token billed at the full rate
  daily input tokens  = 10,000 × 1,500           = 15,000,000
  daily input cost    = 15,000,000 / 1M × $2.50  = $37.50
  daily output tokens = 10,000 × 400              = 4,000,000
  daily output cost   = 4,000,000 / 1M × $10.00   = $40.00
  daily total         = $77.50
  monthly (× 30)      = $2,325.00

With a 90% cache hit rate on the 1,200 reusable tokens
  cached tokens/day   = 10,000 × 1,200 × 90% = 10,800,000 → / 1M × $0.25 = $2.70
  cache-miss tokens   = 10,000 × 1,200 × 10% =  1,200,000 → / 1M × $2.50 = $3.00
  fresh query tokens  = 10,000 × 300               =  3,000,000 → / 1M × $2.50 = $7.50
  daily input cost    = $2.70 + $3.00 + $7.50 = $13.20
  daily output cost (unchanged, never cached) = $40.00
  daily total         = $53.20
  monthly (× 30)      = $1,596.00

Same requests, same tokens, same model — the input side alone drops
from $37.50/day to $13.20/day once the cache hit rate is modeled.

Notice the output cost doesn't move at all — generated tokens are never cached, so caching only ever discounts the input side. That means the more input-heavy and output-light a workload is (long system prompt, short generated answer), the closer the caching effect gets to an order of magnitude on the total bill; the more output-heavy it is, the smaller a share of the total that discount can touch. A calculator that can't take a cache hit rate as an input either assumes nothing is ever cached — wildly overstating the bill — or gives you no way to plan around a caching strategy you're actually about to build.

GenKitLab's Prompt Cost Calculator prices a real workload across GPT and Claude models — requests per day, input and output tokens, and the cache hit rate that usually decides the bill — instead of quoting a single per-call figure. Start from an accurate token count, not a character-count guess: Token Counter tokenizes real prompt and completion text so the numbers you feed the pricing model are the numbers a provider would actually bill. Everything runs entirely in your browser — no API key, prompt, or workload figure you enter is ever uploaded anywhere; the whole calculation happens client-side, on your machine, and nothing survives the tab closing.