LLM Provider Cost Comparator
Compare the monthly cost of every LLM provider you are weighing, on your actual usage profile, using their current published per-1M-token prices. Prices are your inputs — the math is exact, and the ranking reshuffles when your output length or volume changes.
| Provider | Per request | Monthly | vs cheapest | Saves vs max |
|---|---|---|---|---|
| Gemini 1.5 Flashcheapest | $0.000225 | $22.50 | 1.00× | $1,027.50 |
| GPT-4o mini | $0.000450 | $45.00 | 2.00× | $1,005.00 |
| Claude 3.5 Sonnet | $0.010500 | $1,050.00 | 46.67× | — |
Bars are sorted cheapest (green, top) to most expensive. Switching from Claude 3.5 Sonnet to Gemini 1.5 Flash saves $1,027.50 per month at this usage profile.
View the TypeScript implementation on GitHub: packages/calc/src/llm-provider-comparison.ts · view tests
What this means
The headline per-token price on a provider’s pricing page is almost never the number that decides your bill. Two things distort it. First, input and output are priced separately, and output runs 3–5× the input rate, so a workload that generates long responses is fundamentally more expensive than one that returns a short answer — even on the “same” model. Second, your real cost is per-request cost times volume, and at scale a fraction of a cent per request compounds into thousands of dollars a month. This tool collapses both into one apples-to-apples monthly number per provider, ranked.
In my experience the most expensive mistakes are made at architecture time, before a single production request has been sent. A team picks a frontier model for a task that a mid-tier model handles fine, locks the prompt structure around it, and only discovers the 10× cost gap when the first real invoice lands. The fix is cheap up front and painful later: model the cost on your actual input/output profile first, then choose. That is the entire reason prices are inputs here — I’ve found that any comparator with prices baked in goes stale within weeks and quietly hands you the wrong ranking.
Two traps are worth naming because they flip the ranking. Output-heavy workloads punish providers with cheap input and expensive output, so a model that looks cheap on the pricing page can be the worst choice for long-form generation — change the output-tokens field above and watch the order move. And prompt caching changes everything: if you reuse a large system prompt across many calls, your effective input price can drop by an order of magnitude, and a provider with strong caching can leapfrog a nominally cheaper one. This tool states the arithmetic on the prices you give it; it does not weigh quality, latency, rate limits, or caching for you. Use the number as one input to the decision, not the decision.
Worked example
A retrieval-augmented support bot sends 1,000 input tokens (system prompt + retrieved context + user message) and generates 500 output tokens per request, at 100,000 requests/month. You are weighing three example rows: Provider A at $3/M input and $15/M output, Provider B at $0.15/M and $0.60/M, and Provider C at $0.075/M and $0.30/M.
Per request:Provider A is (1,000/1,000,000 × $3) + (500/1,000,000 × $15) = $0.003 + $0.0075 = $0.0105. Provider B is $0.00015 + $0.0003 = $0.00045. Provider C is $0.000075 + $0.00015 = $0.000225.
Monthly at 100,000 requests: Provider A = $1,050, Provider B = $45, Provider C = $22.50. The ranking puts C cheapest; switching from A to C saves $1,027.50/month — A costs about 46.7×what C costs at this profile. That spread is the whole decision surface: it is what you weigh against any quality or latency advantage A might offer on your own evaluation set. I’ve seen teams pay the A bill for a task where C cleared their quality bar — the gap was invisible until the invoice, which is exactly the surprise this comparator is meant to remove.
Frequently asked questions
The information and tools on this website are for general educational purposes only and do not constitute financial, investment, legal, or tax advice. Consult a licensed professional for decisions specific to your situation.