How to Calculate AI Tokens and API Cost
Learn what AI tokens are, how input and output billing works, and how to estimate API cost before sending a production request.
AI APIs do not usually bill by character, word, or page. They process tokens: small units produced by a model-specific tokenizer. Token counts determine whether a request fits the context window and, for most commercial APIs, how much the request costs.
A reliable estimate separates input from output, includes the full request envelope, and accepts that different model families may tokenize the same text differently. This guide builds that estimate from the ground up and shows where simple rules of thumb stop being accurate.
Check the estimate or cleanup workflow locally in your browser without uploading your content.
What an AI token actually represents
A token can be a whole short word, part of a longer word, punctuation, whitespace, or a fragment of code. The tokenizer maps text into numeric IDs from a vocabulary the model understands. English prose often averages several characters per token, but code, unusual names, numbers, emoji, and multilingual text can behave very differently.
The familiar shortcut that one token is roughly three quarters of an English word can help with a first guess, but it is not a billing guarantee. Chinese characters may be represented individually or in learned combinations, and a new tokenizer can change the count for identical text. Use a tokenizer aligned with the target model or the provider's count endpoint when the result affects a strict limit or financial commitment.
Input tokens and output tokens are separate
Input tokens include the information sent to the model: system and developer instructions, user messages, selected conversation history, retrieved documents, tool definitions, and sometimes encoded media. Output tokens include the generated answer and, depending on the provider and model, visible or hidden reasoning tokens.
The two categories usually have different rates. If a request sends 8,000 input tokens and is allowed to generate 2,000 output tokens, calculate each side with its own price. Do not multiply the combined 10,000 by only the input rate. Also distinguish the maximum output limit from actual output: a limit is a safety cap, while billing normally follows tokens actually processed under the provider's terms.
| Component | Usually billed as | Common oversight |
|---|---|---|
| System and developer instructions | Input | Repeated on every request |
| Conversation history | Input | Grows with each turn |
| Retrieved files or search passages | Input | Can dwarf the user's question |
| Model answer | Output | Often priced above input |
| Reasoning or thinking tokens | Provider-specific output | May not all be visible |
Step-by-step API cost formula
First, count or estimate the full input. Second, select an expected output length based on similar calls rather than copying the model's maximum. Third, retrieve the current standard input and output price for the exact model. Finally, calculate input tokens multiplied by input dollars per million, plus output tokens multiplied by output dollars per million.
Suppose a workflow sends 12,000 input tokens and typically receives 1,500 output tokens. At $1.50 per million input and $9 per million output, input costs $0.018 and output costs $0.0135, for an estimated total of $0.0315. Ten thousand equivalent calls would be about $315 before retries, caching, tools, search, storage, taxes, or regional premiums.
- Input cost = input tokens × input price ÷ 1,000,000.
- Output cost = output tokens × output price ÷ 1,000,000.
- Estimated request cost = input cost + output cost + separately priced features.
- Estimated monthly cost = request cost × expected calls, adjusted for workload distribution and retries.
Context windows are capacity limits, not free allowances
A context window is the total capacity available to the request and generation under a model's rules. A model advertised with a large context window can accept more material, but sending the full window is not automatically useful or inexpensive. Long prompts can increase latency, dilute relevant evidence, and cross a provider's higher pricing threshold.
Reserve room for output. If input nearly fills the context window, the model may have insufficient space to answer or the API may reject the request. In chat applications, do not resend unlimited history. Keep recent turns, summarize older material, retrieve only relevant passages, and measure whether additional context actually improves accepted results.
From one request to a production forecast
Real traffic is a distribution. Create small, typical, large, and abuse-case samples, then measure input and output for each. Weight those groups by expected frequency. Averages alone hide long-tail requests, so track percentiles and set hard application limits. Include development, evaluation, monitoring, and retry calls that do not appear as end-user sessions.
After launch, compare estimates with provider usage daily at first. Investigate changes in tokens per successful task, retry rate, output length, cache-hit rate, and traffic mix. A prompt edit that adds 500 stable tokens to every call may look harmless in testing but becomes significant at millions of requests.
| Bucket | What to record | Why it matters |
|---|---|---|
| Typical requests | p50 input and output | Represents the center of traffic |
| Large requests | p90/p95 and maximum | Protects against long-tail cost |
| Failures and retries | Retry percentage | Repeated requests still consume capacity and may bill |
| Internal traffic | Tests and evaluations | Often omitted from product forecasts |
Reduce cost without blindly shortening every prompt
Remove duplicated boilerplate, retrieve fewer but more relevant passages, summarize old history, cap output length, and route simple tasks to an appropriate smaller model. Cache stable prefixes only after measuring reuse. For asynchronous work, evaluate official batch modes, but account for latency and operational constraints.
Do not remove instructions that protect quality or safety merely to save tokens. A concise prompt that causes malformed output and retries can be more expensive. Optimize cost per accepted task, and keep a regression set so token reductions do not silently reduce reliability.
Frequently asked questions
How many words are in 1,000 tokens?
For English prose, a rough estimate is around 750 words, but the actual count varies by tokenizer, language, formatting, numbers, and code.
Does the context window include the answer?
Usually the model's context rules cover input plus generated output, but exact limits and categories are provider-specific. Reserve output capacity.
Am I billed for the maximum output setting?
Providers generally bill processed tokens rather than the unused maximum, but the setting controls the upper bound. Check the exact provider terms.
Why does a local estimate differ from my invoice?
The provider may use a different tokenizer or include system messages, tools, media, reasoning, caching, and retries that the local text estimate does not see.