Normalize any LLM price to cost per 1,000 tokens
Provider A quotes “$2.50 per million tokens,” Provider B says “$0.003 per 1K tokens,” and Provider C charges “a flat $0.01 per request.” Which is cheapest? You cannot compare those numbers directly. This tool converts any of those formats to a single unit — cost per 1,000 tokens — so you can compare any two providers in seconds.
How it works
Pick the unit your raw price is quoted in:
- Per 1M tokens: divide by 1,000 to reach per-1K. For example, $2.50/1M = $0.0025/1K.
- Per 1K tokens: passes straight through — nothing to convert.
- Per request: divide the flat charge by the typical tokens per request, then scale to 1,000. For example, $0.01 per request at 500 tokens = $0.01 / 500 × 1,000 = $0.02/1K.
The result is shown both per-1K and per-1M so it fits whichever mental model you use. You can normalize input and output prices separately, since they almost always differ.
Why separate input and output prices matter
Most LLM providers price output tokens several times higher than input tokens. A model with cheap input and expensive output can cost more than a flat-rate competitor on response-heavy workloads, and vice versa for prompt-heavy, short-reply tasks. To compare honestly:
- Normalize both prices to per-1K tokens.
- Estimate your workload split — for example, 500 input tokens and 200 output tokens per call.
- Compute the weighted cost: (500/1,000 × input_rate) + (200/1,000 × output_rate) per call.
This blended per-call cost is what you actually pay, and it depends heavily on your specific input/output ratio.
Common pricing formats in the wild
| Provider quote | What it means | How to convert |
|---|---|---|
| $X per 1M tokens | Standard modern format | Divide by 1,000 |
| $X per 1K tokens | Older format | No conversion needed |
| $X per request | Flat-rate API | Divide by tokens/request × 1,000 |
| $X/hour compute | Batch/dedicated inference | Need to estimate tokens/hour |
Worked example: comparing two providers
Suppose you are choosing between two models:
- Provider A: $3.00 per 1M input tokens, $15.00 per 1M output tokens
- Provider B: $0.006 per 1K input tokens, $0.024 per 1K output tokens
Normalising Provider A to per-1K: $0.003 input, $0.015 output.
Provider B: $0.006 input, $0.024 output.
At first glance Provider A looks cheaper on both. But if your workload sends 4,000 input tokens and receives only 100 output tokens per call:
- Provider A per call: (4,000/1,000 × $0.003) + (100/1,000 × $0.015) = $0.012 + $0.0015 = $0.0135
- Provider B per call: (4,000/1,000 × $0.006) + (100/1,000 × $0.024) = $0.024 + $0.0024 = $0.0264
Provider A is nearly half the cost for this prompt-heavy, short-reply workload. The same comparison on a short-input, long-output workload would produce a different winner. This is why normalising and then weighting by your actual call shape is the only honest way to compare.
Everything runs in your browser — nothing you enter is uploaded or stored.