Tokens in AI: the unit behind context and usage, not a word count
Understand AI tokens without confusing them with words, requests or credits. Work through input, output, cache, context and per-million pricing examples.
Tokens are the units a language model processes and generates. They are not simply words, chat messages, API requests or dollars. A token can correspond to part of a word, a whole word, punctuation or other text structure, depending on the tokenizer. Understanding that distinction helps explain why a short visible question can have a large input count and why a short answer can still be expensive.
This guide focuses on how to use token information in a practical workload budget. It does not claim to count arbitrary text exactly in your browser. To estimate hosted expense, obtain model-appropriate counts and apply the correct rates; to compare supported Ollama monthly plans, use the calculator. A reliable estimate keeps measurement, pricing and subscription arithmetic as separate steps.
What a token count measures
The OpenAI token explanation distinguishes model-dependent tokenization from word counting. It notes that language, encoding and surrounding text affect results. Its rough English relationships are estimates, not a universal conversion. For OpenAI reasoning models, internal reasoning can also contribute to output usage beyond the text displayed to the user.
Imagine comparing a short English paragraph, a block of source code and a Chinese paragraph. Equal character counts do not establish equal token counts. Neither does saving all three in files with the same byte size. A planning shortcut may be adequate for a rough early estimate, but it should not be presented as an exact bill or as proof that a request fits a strict limit.
Five quantities that belong in different columns
| Quantity | What you use it for | What it does not establish |
|---|---|---|
| Visible words | Editorial length and readability | Exact model input size |
| Input tokens | Request size and input usage | The number of output tokens yet to be generated |
| Output tokens | Generated usage under the provider's definition | Only the words visible on screen |
| Requests | Call volume and concurrency planning | A fixed cost per message |
| Dollar-valued consumption | Applying rates to measured categories | The final subscription cash payment |
A dashboard can legitimately show all five quantities. Confusion arises when a calculation silently switches units: counting words, multiplying by a per-token price and calling the result exact. Label every input and preserve the denominator. If a rate is per million tokens, the calculation must divide the corresponding token count by one million before multiplying by that rate.
Build a complete input inventory
Your newest message may be only a small part of a request. An application can also send instructions, conversation history, retrieved text and tool definitions. The OpenAI input-token counting guide documents counting a complete supported Responses input before generation, including structured request content. A plain-text count alone may omit relevant request structure.
For an original worksheet, allocate a hypothetical request as 500 tokens of instructions, 1,500 of selected documents, 800 of conversation and 200 of the new question. That totals 3,000 input tokens before any unmodeled structure. These are invented allocations, not a tokenization of actual text. Their value is showing where optimization effort belongs: shortening the 200-token question cannot remove most of a 3,000-token request.
Count before a call; reconcile after it
A preflight count helps determine whether the intended input fits and gives one part of a cost estimate. It cannot know the exact answer length before generation. After a call, inspect the provider's usage response and compare it with the estimate. Keep the model identifier, endpoint and date because field meanings and available categories depend on the API. Preserve aggregates without retaining sensitive prompt content unnecessarily.
For Ollama, the usage documentation identifies prompt_eval_count as input tokens, prompt_eval_cached_count as cached prompt tokens and eval_count as output tokens. It distinguishes timing fields, measured in nanoseconds, from token counts. These fields support measurement; they are not dollar amounts or evidence that every request was billed by a cloud provider.
A worked per-million pricing example
Assume, purely for arithmetic, that a hypothetical service charges $2 per million uncached input tokens and $8 per million output tokens. A request using 3,000 uncached input tokens and 500 output tokens costs 3,000 ÷ 1,000,000 × $2 = $0.006 for input, plus 500 ÷ 1,000,000 × $8 = $0.004 for output. The combined example consumption is $0.01.
At 10,000 identical requests, that synthetic workload becomes $100 before other charges or plan effects. If output doubles to 1,000 tokens, each request becomes $0.014 and the same request count becomes $140. The model name and request count have not changed; response length changed the result. These invented rates are not current Ollama or OpenAI prices. Substitute verified rates and measured categories for a real forecast.
Cached input is a category, not a second copy of input
Where the provider reports cached tokens as a subset of total input, separate the subset from uncached input before applying different rates. For instance, 3,000 total input tokens with 2,000 cached leaves 1,000 uncached. Charging all 3,000 at the normal rate and then adding another 2,000 at the cache rate double counts part of the input. Confirm the exact API's definitions rather than assuming all providers report identical fields.
Do not assume every repeated sentence qualifies for a discount. Cache eligibility, write costs, lifetime and rate categories are provider-specific. The Ollama cache and peak-pricing guide explains this site's supported rate assumptions. A forecasting spreadsheet should distinguish a hoped-for cache share from a measured one, especially when the repeated prefix changes frequently.
Context capacity and monthly spending are different limits
A large context window concerns the amount of information a model can work with in a request. A monthly allowance concerns accumulated usage over a billing period. You can hit a request-size boundary with money remaining, or exhaust a spending budget through many small requests that individually fit. Increasing a subscription fee should not be assumed to enlarge the selected model's context.
Similarly, an output limit is a ceiling, not a promise that every response will use that many tokens. Keep room for the intended response and check the target model's documented input and output rules. If a workflow grows too large, select relevant passages, shorten noisy tool output or split the task deliberately. Splitting can add repeated instructions and extra calls, so compare completed-task cost rather than assuming smaller requests are always cheaper.
Use token counts to improve a workload
Start with a few representative successful and unsuccessful tasks. Record input categories, output usage, retries and acceptance results. Identify the largest avoidable source of work: repeated documents, unnecessarily long responses or unsuccessful attempts. Change one factor and repeat the same acceptance test. A reduction in tokens is valuable only if the result still solves the problem reliably.
Finally convert total consumption into the payment model you actually use. A subscription can include an allowance, while local inference can have no cloud token bill at all. The credits and cash guide explains that last accounting step. Do not confuse cheaper metered consumption with guaranteed savings when a fixed fee remains unchanged.
Frequently asked questions
How many words are in one million tokens?
There is no exact universal number. Language, tokenizer and text type change the relationship. Use an explicitly approximate conversion for rough planning or the target model's tokenizer for actual text.
Can I predict the entire bill from input tokens?
No. You also need generated usage, applicable cache categories, rates, other billable capabilities and the payment model. An input count is one measurement, not a complete invoice.
Does a local token count mean I owe a provider money?
No. Tokens measure model work whether inference is local or hosted. Establish the destination and billing relationship before assigning a cloud price to the count.