Discover how much 1 million LLM tokens cost in 2026, compare input, output, and cached token pricing across major providers, and learn practical ways to calculate, budget, and reduce real-world LLM API expenses.
The short answer is: there is no single price for 1 million LLM tokens. The cost depends on the model, provider, token type, context length, caching, and whether the tokens are used for input or output.
For a production application, 1 million input tokens may cost anywhere from a few cents to several dollars, while 1 million output tokens usually costs more. Premium reasoning models can cost substantially more than fast, lightweight models.
The most reliable calculation is:
Input cost = input tokens ÷ 1,000,000 × input price
Output cost = output tokens ÷ 1,000,000 × output price
Total cost = input cost + output cost
This guide explains what 1 million tokens represent, how providers charge for them, and how to estimate your real monthly LLM bill.

Providers do not use one universal token price. Each model may have separate rates for input tokens, output tokens, cached input, cache writing, long-context requests, batch processing, and reasoning tokens.
A low-cost model may charge less than $1 per million input tokens. A premium model may charge several dollars or more. Output tokens are commonly priced higher because the model generates them sequentially.
Assume a model charges $2 per 1 million input tokens and $8 per 1 million output tokens.
A request containing 600,000 input tokens and 100,000 output tokens would cost:
Input: 0.6 × $2 = $1.20
Output: 0.1 × $8 = $0.80
Total: $2.00
Your final bill may also include cached tokens, tool calls, retries, image or audio processing, and platform fees.
Search results often combine prices from different dates, model versions, and billing systems. A page that lists a model as “current” may actually use an older version.
For accurate budgeting, check official provider documentation:
Third-party comparison pages are useful for discovery, but official pricing pages should be treated as the final source.
A language model breaks text into smaller units called tokens. A token may be a complete short word, part of a longer word, a number, punctuation, a space, or a programming symbol.
The exact result depends on the tokenizer used by the model.
For typical English text, 1,000 tokens are often estimated at about 750 words. This is only a planning approximation.
The ratio changes with language, word length, numbers, emojis, URLs, Markdown, source code, JSON, XML, and special characters.
Chinese, Japanese, source code, and structured data can consume tokens at a different rate from ordinary English prose.
A single-spaced page containing approximately 500 English words may use around 650–700 tokens.
Using that rough estimate:
These numbers are estimates, not fixed limits. Documents containing code, tables, or many URLs may use more tokens than ordinary prose.
Code has a different token density from natural language. Brackets, indentation, operators, variable names, and file paths all affect tokenization.
There is no reliable universal conversion between tokens and lines of code. One million tokens may represent tens of thousands of lines of ordinary code, but a minified JavaScript file, JSON file, and Python project will produce very different results.
Use an actual tokenizer whenever code cost matters.
Input tokens include everything your application sends to the model:
If you resend the same conversation history on every turn, those previous messages may be counted again as input.

Output tokens include natural-language answers, code, structured JSON, tool arguments, summaries, explanations, and error messages.
During input processing, the model can analyze many tokens in parallel. During output generation, it predicts the next token repeatedly until the response is complete.
This sequential process requires more active computation, so providers commonly price output tokens higher than input tokens.
Input cost = input tokens ÷ 1,000,000 × input price
Output cost = output tokens ÷ 1,000,000 × output price
Total cost = input cost + output cost
For example, if 1 million input tokens cost $3 and 1 million output tokens cost $15:
Total cost = $3 + $15 = $18
This calculation assumes that all tokens are billed at the same standard rate.
Suppose your application processes 4 million input tokens and 500,000 output tokens. The input price is $2 per million tokens, and the output price is $10 per million tokens.
Input: 4 × $2 = $8
Output: 0.5 × $10 = $5
Total: $13
This is why input and output should be measured separately instead of applying one average rate to all tokens.
If your application handles 30 million input tokens and 5 million output tokens per month:
Monthly cost = (30 × input price) + (5 × output price)
At $2 per million input tokens and $10 per million output tokens:
Monthly cost = (30 × $2) + (5 × $10) = $60 + $50 = $110
Your actual total may be higher if you use retries, tools, long context, image inputs, or multiple models.
If each classification uses 200 input tokens and 30 output tokens, 1 million combined tokens can support several thousand classifications.
A short prompt with a compact label response will process far more emails than a workflow that includes a large policy document in every request.
A support chatbot may process the current user message, system instructions, retrieved knowledge-base content, conversation history, and the model’s answer.
A short single-turn interaction may use a few hundred tokens. A long multi-turn conversation can use several thousand tokens because the history grows over time.
Conversation history is one of the most common causes of unexpected token growth.
RAG systems often use more input tokens than output tokens. A request may include the user’s question, retrieved document chunks, system instructions, citation requirements, and conversation context.
Reducing irrelevant retrieved text can lower cost without reducing answer quality.

Code workloads are difficult to estimate because one task may include source files, tests, dependency information, build logs, tool results, generated patches, and follow-up corrections.
A small function request may use fewer than 1,000 tokens. A repository-level refactor can consume tens of thousands of tokens across multiple calls.
For coding agents, track cost per completed task, not only cost per API request.
Input tokens are normally charged every time they are sent unless the provider offers a discounted caching mechanism.
Repeatedly sending a large system prompt or document can therefore become expensive.
Some providers offer lower prices when previously processed content is reused through prompt caching.
Caching can help when your application repeatedly sends the same system instructions, product catalog, legal document, codebase summary, or tool definition.
Caching is less useful when every prompt is completely different.
Some pricing systems separate the cost of writing content into a cache from the cost of reading it later.
A cache is financially useful only when the content is reused enough times to offset the initial write cost.
Compare:
Cache write cost + repeated cache read cost
with:
Repeated full input cost
Some reasoning models may use additional internal processing tokens. Depending on the provider’s billing policy, these tokens may be included in usage totals or shown as a separate category.
Do not assume that visible answer length equals total billed usage. Check the provider’s usage fields and invoice documentation.
Context bloat occurs when an application keeps sending unnecessary history, documents, or tool results.
Common solutions include conversation summaries, sliding context windows, retrieval filters, duplicate-content removal, shorter system instructions, and separate memory storage.
A timeout or failed tool call may trigger another request. If the first request consumed tokens before failing, the retry can create additional charges.
Track retry count, error type, tokens used before failure, final success or failure, and cost per successful result.
An agent may call the model several times for one user task. The total bill includes every planning step, tool result, correction, and final response.
A workflow that appears to be one feature to the user may actually contain dozens of model requests.
Using several providers can improve flexibility, but it also creates separate billing dashboards, different token definitions, different cache rules, different rate limits, and different logging formats.
A single blended average price can hide which model is driving your spending.
Use a smaller model for routine classification, extraction, formatting, and simple code edits. Reserve expensive reasoning models for tasks that genuinely need them.
Send only the information required for the current decision. Remove duplicate documents, outdated history, and irrelevant tool output.
Set an appropriate maximum output limit. Ask for structured, concise responses when a long explanation is not needed.
Clear sections, explicit constraints, and stable output formats can reduce retries and unnecessary explanations.
Use prompt caching when the same large context is reused frequently and the provider’s terms produce a measurable saving.
For offline classification, evaluation, summarization, or data processing, batch pricing may be cheaper than real-time processing when the provider offers it.
Use exponential backoff, classify errors, and stop retrying after a defined threshold. Unlimited retries can turn a temporary outage into a large bill.
Cost per successful task = total input and output cost ÷ successfully completed tasks
This metric includes the effect of retries, long outputs, and failed attempts.
Your total AI operating cost may also include application servers, vector databases, observability tools, storage, human review, data processing, security controls, engineering maintenance, and support operations.
A cheaper token price does not automatically produce a cheaper product.
Slow responses can increase abandonment, reduce conversions, and create more concurrent infrastructure demand.
When comparing models, measure time to first token, full response time, error rate, retry rate, user completion rate, and cost per successful workflow.
A gateway can simplify multi-provider operations by centralizing routing, usage reporting, authentication, and fallback logic.
It does not automatically change a provider’s published token price. Its value comes from operational control and the ability to select different models for different workloads.
LLMs use tokens because tokens are easier for computers to process than complete words. A token can be a full word, part of a word, punctuation mark, number, space, or programming symbol.
Tokenization allows one system to process multiple languages, uncommon words, code, URLs, and new terms without storing every possible word in its vocabulary. It also gives providers a consistent way to measure usage and calculate API costs.
For typical English text, 1,000 tokens is roughly equal to 750 words, but the ratio changes for Chinese, code, numbers, emojis, and structured data.
This question can refer to two different limits:
Vocabulary size: the number of unique tokens a model understands.
Context window: the maximum number of input and output tokens the model can process in one request.
The vocabulary size is fixed by the model’s tokenizer, while the context window varies by model and provider. Modern LLMs may support context windows ranging from thousands to hundreds of thousands—or more—tokens.
A larger context window does not automatically mean better performance. The model still needs clear prompts, relevant information, and effective context management.
There is no universal price for one LLM token. Providers usually charge per 1 million tokens, with separate prices for input and output.
To calculate the price of one token:
Use this formula:
Price per token = price per 1,000,000 tokens ÷ 1,000,000
Your actual cost depends on the model, input or output type, cached tokens, context length, batch pricing, and any retries or tool calls.