What is cost per million tokens, really?

Cost per million tokens is the only pricing unit that makes LLM bills comparable, because it normalizes for model size, output length, and provider naming games. If you can do the arithmetic once, you can sanity-check any invoice, budget, or model comparison in seconds.

Why per-million-token pricing is the number that matters

LLM pricing gets messy fast because providers split charges by input and output, then add cache, reasoning, or platform-specific terms on top. A model that looks cheap on input can still get expensive if it produces long answers, and a model with a higher input rate can still win if it finishes faster or needs fewer retries.

The trick is to keep the unit consistent. Every price you see in this article is quoted per 1,000,000 tokens, because that is the standard way to compare models without accidentally hiding a million-fold mistake. A price like $2.50 per 1M input tokens is easy to reason about. A price like $0.0000025 per token is the same number rewritten, but it is much easier to misread or misuse.

For a broader market view, the AI Cost Index is the cleanest shortcut. It tracks blended prices so you can see the market without manually normalizing every provider’s rate card.

How to calculate LLM cost from token counts

The formula is simple:

cost = (input_tokens / 1,000,000) * input_price_per_1M
     + (output_tokens / 1,000,000) * output_price_per_1M

If a model also uses cache or reasoning tokens, you apply the same logic with the correct rate for that token type. The important part is that the unit stays per million tokens all the way through.

Here’s a worked example using gpt-4o, which is priced at $2.5 input / $10 output per 1M tokens.

Input: 120,000 tokens
Output: 30,000 tokens

Input cost = 120,000 / 1,000,000 * 2.5 = $0.30
Output cost = 30,000 / 1,000,000 * 10 = $0.30
Total cost = $0.60

That example matters because it shows something people miss all the time: output can cost as much as input even when the output token count is much smaller. In this case, 30,000 output tokens cost the same as 120,000 input tokens because output is priced 4x higher than input.

Now compare that with gpt-4o-mini, priced at $0.15 input / $0.6 output per 1M tokens. Using the same 120,000 input and 30,000 output tokens:

Input cost = 120,000 / 1,000,000 * 0.15 = $0.018
Output cost = 30,000 / 1,000,000 * 0.6 = $0.018
Total cost = $0.036

Same workload, different model, 16.7x cheaper on raw API spend. That does not mean it is the right model for the job, but it does mean you can make the tradeoff with real numbers instead of vibes.

A small comparison table, because ratios beat opinions

Here is a compact view of the models and blended market baskets in the current index. The baskets are especially useful when you want a quick signal instead of a full model-by-model audit.

That table is enough to make one point very clear: you should never compare model prices with a single sticker number unless you know your input-output mix. A model with a low input price but high output price can be cheap for retrieval-heavy tasks and expensive for long-form generation.

Why blended prices are useful, and where they can mislead you

Blended prices are a fast way to compare models when you know your typical prompt shape. The AI Cost Index uses a 3:1 input:output blend for the Frontier and Budget baskets, which is a practical proxy for many coding workloads and agent loops. That makes the basket numbers useful for rough planning, especially when you are trying to answer, “Is my stack drifting toward expensive territory?”

But blended numbers can hide the real shape of your workload. If your agent spends most of its time reading files, the effective cost will lean toward the input rate. If it writes long patches, explanations, or structured outputs, the output rate dominates. If you are using reasoning-heavy flows, the bill can skew again because some providers expose extra token categories.

That is why live model catalogs matter. The live prices for 4,096 models let you check the exact rate card instead of relying on stale blog posts or a random screenshot from last quarter. For market-level trends, the State of AI page is a better place to look than a single model page, because it shows how pricing behaves across the ecosystem rather than just one vendor.

What actually drives your bill in practice

In real dev workflows, the biggest cost drivers are usually not “which model is cheapest” but “how often do I ask it to think, rewrite, or retry.” Long context windows, verbose output, and multi-step agents all multiply token volume. A small prompt can become a large bill if it is repeated across dozens of tool calls.

• Input tokens, your system prompt, chat history, retrieved files, and tool output all count here.
• Output tokens, the model’s answer, code, explanation, or structured response.
• Repeated context, the hidden tax when your agent keeps resending the same instructions.
• Retries, failed tool calls and regenerated responses that double the work.
• Model switching, when a cheaper model handles most calls but a pricier one handles the hard cases.

For example, a coding agent that sends 80,000 input tokens and receives 10,000 output tokens on every task might look “small” because the output is short. But if it runs that loop 50 times in a day, you are no longer talking about a toy workload. You are talking about millions of tokens per week, and that is exactly where per-million pricing becomes useful.

When you want to see whether your usage is actually drifting, compare your workload against the value-for-money view. It is often more useful than raw price because it helps you ask whether a model is cheap enough for the quality it returns.

How to track this without guessing

If you want the numbers from your own tools, don’t estimate from memory. Run npx mytokentracker and it reads the usage logs your coding agents already keep locally, then prints a 30-day cost table at API prices. Your usage data never leaves your machine for that local report.

If you want a synced dashboard, create a free account and run npx mytokentracker init. It asks for the API token, uploads history, then syncs every 30 minutes. It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code and more. Only daily totals per agent and model are uploaded, never prompts, code, or file names.

MyTokenTracker also captures cost, input/output/cache/reasoning tokens, latency, and success, broken down by provider, model, platform, and use-case. That means you can answer practical questions like, “Which agent is expensive?” and “Which model is failing enough to waste tokens?” instead of staring at a single monthly total and hoping it makes sense.

If you want to go deeper on the raw data behind the index, the open data makes it easier to build your own analysis or verify trends independently.

FAQ

Is per-million-token pricing enough to estimate my real bill?

It is enough for a good estimate, but only if you know your input-output mix. For a rough forecast, per-million pricing is excellent. For an exact invoice, you need the actual token counts, including any cache, reasoning, or tool-related usage your provider reports.

Why do two models with similar input prices cost so differently?

Because output pricing, context growth, and retry behavior can dominate the total. A model with a cheap input rate can still be expensive if it generates long responses or needs more turns to solve the same task.

What is the fastest way to see my own token spend?

Run npx mytokentracker. It gives you a local 30-day cost table first, then you can sync if you want a dashboard. That is usually faster than trying to reconstruct spend from provider dashboards after the fact.

If you want to see your own numbers instead of guessing, try MyTokenTracker.