For a clean cross-provider pricing table with GPT-4.1, Claude, Gemini, and Llama side by side, see LLM Pricing 2026. This page focuses on token math and calculating your actual spend for real workloads.
How much is 1 million tokens? It is roughly 750,000 English words, about 1,500 pages of plain text, and anywhere from pennies to meaningful API spend depending on the model and whether those tokens are inputs or outputs.
One million tokens is roughly 750,000 English words, or about 1,500 pages of plain text Related analysis.
The dollar answer needs more context. Models charge separately for text you send them and text they generate. Input tokens cover prompts, instructions, chat history, retrieved documents, and tool results. Output tokens cover the response. A workload that reads a lot and writes little has a different bill from one that generates long reports, code, or structured data.
This is the token math guide. Use it to estimate a workload before you pick a model, then use our cross-provider LLM pricing comparison when you need to compare providers side by side.
TLDR
One million tokens equals roughly 750,000 English words or about 1,500 pages of plain text. Cost depends on the model and whether tokens are input or output. Repeated prompts can cost far less with caching, while batch processing cuts Claude token prices.
Key Takeaways
- One million tokens is a large volume of prose, but code and JSON consume tokens faster.
- Input and output tokens have separate prices, and output usually costs more.
- GPT-4.1 Nano is the cheapest capable option in the figures on this page.
- Prompt caching and batch processing can reduce costs before you change models.
How Much Is 1 Million Tokens
The practical answer is words, pages, and dollars.
For ordinary English prose, one million tokens is roughly 750,000 English words, or about 1,500 pages of plain text Related analysis.
That is enough text to make token pricing feel abstract until you map it to an actual product. A support assistant may consume tokens through a system prompt, customer question, conversation history, and retrieved help-center passages. A document workflow may send long source files and receive a short classification. A coding agent can move through repositories, terminal output, diffs, and generated code. The visible response is often only a small part of what the model processed.
Dollars depend on model selection and token direction. The cheapest capable model is GPT-4.1 Nano at $0.10 input and $0.40 output per million tokens Related analysis.
That price is useful as a floor for workloads that fit a smaller model. It should not become an automatic model choice. Cheap inference loses its appeal if the model produces unreliable classifications, weak tool calls, or output your team has to repair. The right estimate starts with quality requirements, then asks how much text the workload sends and receives.
GPT-4.1 costs $2.00 input and $8.00 output per 1 million tokens Related analysis.
Claude Sonnet 4.6 costs $3 input and $15 output per 1 million tokens Related analysis.
Those differences compound quickly when an application has long context, substantial retrieval, or generated output that users expect to be detailed. A short chatbot reply can be cheap while the hidden context behind it does most of the spending.
Tokens to Words and Pages
A token is a chunk of text a language model processes. It is not the same thing as a word, character, sentence, or byte. Tokenizers break text apart based on patterns in language, punctuation, whitespace, and common fragments.
One token is roughly 0.75 words of English text Related analysis.
That conversion works well enough for planning prose-heavy workloads. If you know the word count of a document, prompt library, knowledge base, or generated report, you can estimate token volume before writing code or loading a provider dashboard.
It gets less tidy outside plain English. Code tokenizes heavier than prose because syntax, variable names, punctuation, indentation, and file paths create many smaller pieces. JSON and XML do the same thing. A product that asks a model to read and return structured data should measure representative payloads instead of using a prose conversion and hoping for the best.
The same issue appears with multilingual products. English provides a useful shorthand because it is often what teams use for early estimates. A model does not bill a user for “words,” though. It bills for tokens. If your app handles code, formatted documents, tables, or languages with different token patterns, inspect real requests before treating a word count as a budget.
Pages are also a rough translation. Plain text pages are easier to reason about than PDFs with headers, tables, citations, images, and layout artifacts. When a document extraction step turns a file into messy text, the token count can rise in ways the original page count does not reveal.
The useful habit is simple: estimate with words when scoping, then measure tokens with real samples before committing to an architecture. That keeps a rough forecast from becoming a budget.
Input Tokens and Output Tokens
Input tokens are everything your application gives the model. That includes the user’s request, your system instructions, examples, previous messages, retrieved passages, schemas, and tool results.
Output tokens are the text or structured data the model returns.
Providers price these directions separately because generating a response requires more work than reading a prompt. That is why an application can have low input spend but a much larger bill once it begins producing long answers, detailed analyses, or large JSON objects.
A classification workflow often leans toward input. You may send a document, email, or support request and receive a short label. A writing assistant leans toward output. It may receive a compact prompt and generate a long draft. Retrieval-augmented generation can be input-heavy because each answer includes retrieved material alongside the user’s question.
Chat history is another quiet cost center. Conversations grow over time. If an app resends every prior message on every turn, the model reprocesses that context each time. Some history is necessary. Much of it is often stale, redundant, or better represented as a compact summary.
Prompt design affects the bill too. A long instruction set can be worth it when it prevents errors, improves formatting, or avoids retries. It can also become expensive baggage when copied into every request without changing the result. Teams should treat prompts like production code: keep the parts that earn their space and remove the parts nobody can defend.
The distinction also changes how you compare models. A model with an attractive input rate may still be expensive for a product that generates substantial output. A model with a higher input rate can be the better fit if it delivers concise, accurate responses without repeated calls.
What 1 Million Tokens Costs by Model
The table below separates input from output pricing. These figures are per million tokens, so they are most useful as a comparison baseline rather than a prediction of any specific application bill.
| Model | Input cost per 1 million tokens | Output cost per 1 million tokens | Best fit |
|---|---|---|---|
| GPT-4.1 Nano | $0.10 | $0.40 | High-volume tasks where a smaller capable model fits |
| GPT-4.1 | $2.00 | $8.00 | Higher-quality general-purpose workloads |
| Claude Sonnet 4.6 | $3 | $15 | Workloads that need Claude Sonnet capabilities |
The cheapest capable model is GPT-4.1 Nano at $0.10 input and $0.40 output per million tokens Related analysis.
GPT-4.1 costs $2.00 input and $8.00 output per 1 million tokens Related analysis.
Claude Sonnet 4.6 costs $3 input and $15 output per 1 million tokens Related analysis.
A table like this answers a procurement question. It does not answer the engineering question: how many tokens will your application use?
That answer comes from workload shape. Measure representative requests. Include the system prompt, expected user input, retrieved context, tools, output format, and conversation history. Then separate the result into input and output. A single blended token estimate hides the part of the workload that may be driving cost.
You also need to account for retries. A model that fails a structured-output request may force another call. A cheap model can become expensive when the application has to validate, repair, and rerun its responses. The calculation belongs at the workflow level, rather than only in a pricing table.
For current rates across providers, use the LLM pricing per million tokens tool. If you are choosing between providers, the OpenAI API pricing and Anthropic API pricing pages break out the relevant rates.
How to Estimate a Real API Bill
Start with a representative request, not an idealized prompt pasted into a playground.
Take a real user interaction. Include every piece of text the model sees: instructions, examples, user content, retrieved passages, prior messages, and any machine-readable format your app sends. Then capture the response you expect the product to return.
Now ask a more useful question than “what does a million tokens cost?” Ask which part of the request is repeated, which part varies, and which part can be shortened without losing quality.
Static instructions may be reused across every call. Retrieved context may differ widely based on the question. Generated output may be tightly controlled in a classification system and unpredictable in a writing product. Each of those components points to a different cost-control decision.
A long document can be expensive to process, but it may still be cheaper than building an elaborate pipeline around it. The goal is not to minimize token use at any cost. The goal is to spend on the tokens that improve the result and stop paying for text that does not.
This is why token usage belongs in product analytics. Track input and output separately. Track the model used. Track task type. Track whether a request succeeded on the first attempt. Without that detail, teams tend to respond to a rising bill by switching to a weaker model when the actual problem was a bloated prompt or unnecessary context.
The best cost estimates become more accurate after launch. Early planning uses representative samples. Production data shows what users actually ask, how long their conversations become, and where your prompts have accumulated clutter.
Per-1M-Token Pricing: Every Major Model
All prices current as of September 2026. Input tokens are what you send; output tokens are what the model generates.
Frontier Models (Highest Capability)
| Model | Input / 1M Tokens | Output / 1M Tokens | Effective Ratio |
|---|---|---|---|
| Claude Opus 4 | $15.00 | $75.00 | 5.0x |
| o3 (OpenAI) | $2.00 | $8.00 | 4.0x |
| GPT-4.1 | $2.00 | $8.00 | 4.0x |
| GPT-4o | $2.50 | $10.00 | 4.0x |
| Gemini 2.5 Pro | $1.25 | $10.00 | 8.0x |
Mid-Tier Models (Best Price-Performance)
| Model | Input / 1M Tokens | Output / 1M Tokens | Effective Ratio |
|---|---|---|---|
| Claude Sonnet 4 | $3.00 | $15.00 | 5.0x |
| Mistral Large 2 | $2.00 | $6.00 | 3.0x |
| Cohere Command R+ | $2.50 | $10.00 | 4.0x |
| o4-mini (OpenAI) | $1.10 | $4.40 | 4.0x |
Budget Models (High Volume / Low Cost)
| Model | Input / 1M Tokens | Output / 1M Tokens | Effective Ratio |
|---|---|---|---|
| GPT-4.1 mini | $0.40 | $1.60 | 4.0x |
| Claude Haiku 3.5 | $0.80 | $4.00 | 5.0x |
| Gemini 2.5 Flash | $0.15 | $0.60 | 4.0x |
| Gemini 2.0 Flash | $0.10 | $0.40 | 4.0x |
| GPT-4.1 nano | $0.10 | $0.40 | 4.0x |
| Mistral Small | $0.10 | $0.30 | 3.0x |
| Cohere Command R | $0.15 | $0.60 | 4.0x |
| Llama 4 Maverick (hosted) | $0.20 | $0.60 | 3.0x |
| Llama 4 Scout (hosted) | $0.10 | $0.25 | 2.5x |
Why Output Tokens Cost More
Every provider charges more for output tokens than input tokens. The ratio ranges from 2.5x (Llama 4 Scout) to 8x (Gemini 2.5 Pro). This isn't arbitrary pricing. Generating output requires the model to run its full forward pass for each token sequentially, while input tokens can be processed in parallel batches.
This asymmetry has a practical implication: controlling output length is the single most effective cost optimization. A prompt that generates 500 tokens of output costs 2-5x less than one that generates 2,000 tokens, even with identical input.
Real-World Cost Calculations
Abstract per-million pricing is hard to reason about. Here are concrete examples.
Example 1: Email Classification System
You're classifying incoming customer emails by topic and priority.
- System prompt: 500 tokens (fixed per request)
- Average email: 270 tokens
- Output (classification + reasoning): 50 tokens
- Volume: 5,000 emails/day
| Model | Daily Cost | Monthly Cost |
|---|---|---|
| GPT-4.1 | $9.70 | $291 |
| GPT-4.1 mini | $1.94 | $58 |
| GPT-4.1 nano | $0.49 | $15 |
| Gemini 2.5 Flash | $0.73 | $22 |
| Claude Haiku 3.5 | $4.08 | $122 |
For a simple classification task, the difference between the cheapest and most expensive reasonable option is 20x. If classification accuracy is similar across models (test this with your data), there's no reason to pay $291/month when $15/month works.
Example 2: Content Generation Platform
You're generating blog post drafts from outlines.
- System prompt: 1,000 tokens
- User input (outline + instructions): 500 tokens
- Output (draft article): 4,000 tokens (~3,000 words)
- Volume: 200 articles/day
| Model | Daily Cost | Monthly Cost |
|---|---|---|
| GPT-4.1 | $7.00 | $210 |
| Claude Sonnet 4 | $12.90 | $387 |
| Gemini 2.5 Pro | $8.38 | $251 |
| GPT-4.1 mini | $1.40 | $42 |
| Gemini 2.5 Flash | $0.53 | $16 |
Content generation is output-heavy, so the output token price dominates. Claude Sonnet's $15/1M output pricing makes it expensive for this workload despite competitive input pricing.
Example 3: RAG-Based Q&A System
Knowledge base chatbot retrieving context from documents.
- System prompt: 800 tokens
- Retrieved context: 3,000 tokens (average 4 chunks)
- User question: 50 tokens
- Answer: 300 tokens
- Volume: 2,000 queries/day
| Model | Daily Cost | Monthly Cost |
|---|---|---|
| GPT-4.1 | $20.20 | $606 |
| Claude Sonnet 4 | $32.10 | $963 |
| GPT-4.1 mini | $4.04 | $121 |
| Gemini 2.5 Flash | $1.52 | $46 |
| Llama 4 Maverick (hosted) | $1.90 | $57 |
RAG systems are input-heavy (large context windows), so input token pricing matters more. Prompt caching can dramatically reduce costs here since the system prompt repeats every request.
Per-1K Tokens vs. Per-1M Tokens
Some documentation quotes prices per 1K tokens, others per 1M tokens. The industry has largely standardized on per-1M-token pricing, but you'll still encounter per-1K pricing in older docs.
Conversion: divide the per-1M price by 1,000 to get per-1K pricing. GPT-4.1 at $2.00/1M input = $0.002/1K input.
Hidden Costs to Account For
Reasoning Token Overhead
OpenAI's o3 and o4-mini models generate internal reasoning tokens that you're billed for as output tokens but never see. A simple question might generate 500 visible output tokens but consume 3,000 reasoning tokens internally. Your actual cost is 7x what you'd estimate from the visible output alone.
Retry and Error Costs
Rate limits, timeouts, and malformed outputs mean you'll retry some percentage of requests. Budget for 5-15% overhead depending on your error handling logic and the provider's reliability.
Embedding Costs
If you're building RAG systems, you also pay for embedding your documents. OpenAI's text-embedding-3-small costs $0.02/1M tokens. See our Best Embedding Models 2026 guide for a full comparison.
Fine-Tuning Costs
Training tokens for fine-tuning cost 2-8x more than inference tokens. OpenAI charges $25.00/1M training tokens for GPT-4.1 mini. Factor this into your total cost of ownership if you plan to fine-tune.
How to Cut Your Token Bill
The first place to look is repeated input. If every request includes the same instructions, examples, policies, or document context, prompt caching can reduce the cost of sending that material again.
Prompt caching takes up to 90% off repeated input and the Batch API cuts token prices by 50% on Claude models Related analysis.
Caching works best when the repeated prefix is stable. Put reusable instructions and reference material in a consistent place. Avoid changing the static portion of a prompt unnecessarily. Small prompt edits can matter if they prevent the cache from recognizing the repeated content.
Batch processing is a different trade. It suits work that does not need an immediate answer: document enrichment, backfills, evaluation runs, content classification, or large offline transformations. If a job can wait, lower pricing may beat real-time convenience.
Context trimming is another practical move. Keep the history that affects the next response. Summarize or discard the rest. Retrieval systems should return the passages that answer the question, not every vaguely related chunk in the knowledge base. More context can raise cost and make answers worse by burying the relevant facts.
Output limits deserve attention too. Ask for the response format the product needs. A user who needs a short classification does not benefit from a long explanation behind the scenes. A structured result should contain the fields your application uses, not an essay wrapped around them.
Model routing can help when the workload has clear tiers. Routine tasks may fit a smaller model, while difficult requests go to a more capable one. The routing rule needs real evaluation behind it. If it creates a stream of weak answers that require escalation or retrying, the apparent savings disappear.
The common thread is measurement. Find the expensive part of the request before changing the model. In many systems, the bill comes from repeated context and excess output, not from a single bad price choice.
Token Math Is a Product Decision
Token pricing looks like an infrastructure detail until it shapes which features are viable.
A generous chat experience with deep memory may delight users and carry a high input cost. A research feature may need long retrieved context to be trustworthy. An automation tool may need structured output that costs more to generate but saves a human far more time than it costs.
Those are product decisions. Pricing helps you make them with open eyes.
One million tokens is roughly 750,000 English words, or about 1,500 pages of plain text Related analysis. That scale is enough to process substantial material, but it is also enough for sloppy context handling to become expensive.
Estimate the workload with real samples. Separate input from output. Check whether code, JSON, documents, or chat history are inflating the count. Then compare model rates using the cross-provider LLM pricing comparison instead of choosing based on a headline price alone.
The model price is visible. The workflow is where the bill gets made.
Sources
- PE Collective LLM pricing per million tokens: 750,000 English words and 1,500 pages
- PE Collective OpenAI API pricing: $2.00 input and $8.00 output
- PE Collective Anthropic API pricing: $3 input and $15 output
- PE Collective Claude pricing guide: 90% prompt caching and 50% Batch API reduction
