LLM Model Cost Comparison
Price the same workload on two models side by side, with your own rates overriding the table on either side. The output states the thing that makes most model comparisons wrong: both columns use the same token counts, and the two models will not.
model-comparison.txt
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Applying one model's measured token counts to another model's rates
A cheaper model usually needs more tokens for the same task: more retries, longer reasoning, more tool calls to reach the same answer. Pricing one measurement against both rate cards systematically flatters the cheaper side, sometimes by more than the rate difference itself.
Instead:Run both models over the same sample of real work, measure each, then price each against its own rates. A ratio from one measurement is a hypothesis.
Comparing on the input rate
Output is priced several times higher almost everywhere, so on a typical workload the output rate decides the ranking and the input rate is a rounding difference. It also means prompt caching, which only touches input, will not reorder the two.
Instead:Compare on output first. Treat input-side optimisation as secondary unless your workload is genuinely prompt-heavy and answer-light.
Treating a cheaper model with a smaller context window as a substitute
Cost per request is irrelevant for a request that cannot be made. The same applies to the per-response output ceiling, which is a separate and much smaller limit than the window.
Instead:Check your longest prompt against the smaller window and your longest expected answer against the smaller output cap before this is a choice at all.
A price ratio is not a cost saving
Two models that differ fourfold in rate rarely differ fourfold in bill, because the cheaper one usually needs more tokens to finish the same task. This page prices the numbers you give it and says so plainly rather than pretending otherwise.
Both columns use the same token counts, and the models will not
You measured a prompt on one model. Applying those counts to another model's rates assumes the second model spends the same tokens reaching the same answer, and it usually does not: more retries, longer reasoning, more tool calls to get there. That systematically flatters the cheaper model, sometimes by more than the rate difference. Measure both over the same real sample, then price each against its own rates.
Output is where the money is, and where the ratio is decided
Output is priced several times higher than input almost everywhere, so on a typical workload the output rate decides the ranking and the input rate is a rounding difference. That also means prompt caching, which only touches input, will not reorder the two.
A smaller context window is not a cheaper model, it is a different one
Cost per request is irrelevant for a request that cannot be made. Check your prompt against the smaller of the two windows, and check your longest expected answer against the smaller output ceiling, before treating this as a choice at all.
Cache economics do not transfer between providers
The read and write multipliers here are Anthropic's: a tenth for a read, and more than full price for a write. Other providers price cached input differently, several cache automatically with no breakpoint you control, and at least one charges nothing to write. The cache rows are only meaningful on the Anthropic side; for anything else, put the real cached-input rate in the input field and leave the cache rows at zero.
Where these rates came from, and why that matters
The Anthropic figures come from a dated pricing reference. Every other model carries a published list price held in the code that has NOT been re-checked against a live source, and those are marked with an asterisk in the picker. Provider pricing changes, introductory rates expire, negotiated and committed-use rates differ from list, and none of that is visible to a page with no backend. Treat an unmarked rate as a starting point.
The four rate fields are the point of the tool
They override the table completely, per side. Entering the numbers from your own invoice turns this from an approximation into arithmetic, and it is the only way the result will reconcile against a bill. It is also what makes the tool useful for a model whose listed rate here is stale.
What this cannot see
Quality, latency, rate limits, and how many tokens either model actually needs. It multiplies counts by rates in your browser and calls nothing. It cannot tell you that the dearer model finished the task in one attempt where the cheaper one took three, which is the comparison that usually decides the question. Use this to size the gap, then run both on real work before moving anything.