Token estimates, context usage and cost at your rates
Tokens are the units language models read, write and bill by, and no character count converts to them exactly: every model’s tokenizer splits text differently. This page therefore does two honest jobs. It estimates the tokens in your text with a documented estimator, printed in full below and labelled an estimate wherever it appears, with the range the true count usually falls inside. And where you already know token counts, from an API response or a provider’s own tokenizer, it does exact work: context-window usage and remaining headroom, and cost at the input and output rates you enter.
Estimate tokens in text
Exact counts you already have
Disclaimer: This calculator gives estimates for general information only. It is not financial, medical or other professional advice. Token estimates come from the documented estimator on this page, not from any model’s own tokenizer; check billing decisions against your provider’s tokenizer and prices.
What this calculator does
It separates the two questions people conflate. “Roughly how many tokens is this text?” is an estimation problem, because tokenizers are proprietary splitting schemes and the same sentence costs different counts on different models; the page answers it with a stated rule and a stated range, and refuses to pretend otherwise. “Given these exact counts, what happens?” is arithmetic: what share of a context window a conversation occupies, what headroom remains before the model starts forgetting or refusing, and what a request costs at published per-million rates, scaled to a thousand requests so budgets can be planned. Keeping the estimate and the arithmetic visibly apart is the page’s main design decision, and the reason the two tools sit in separate sections with separate buttons.
How to use it
- Use the estimate for planning, the provider’s tokenizer for billing. Before sending a large document you need an order of magnitude: will this fit, roughly what will it cost. The estimator answers that in a second. For the invoice-grade count, every major provider offers its own tokenizer or returns exact usage in the API response; feed those numbers into the second section, where everything downstream is exact.
- Budget output tokens generously. Input is the text you control; output is the text the model chooses, and hitting an output limit mid-answer truncates it. When planning context usage, reserve the maximum output you have configured, not the average you hope for, in the headroom judgement; the usage percentage here uses the counts you give it, and a response longer than your entry is the classic way real usage exceeds the plan.
- Context usage is about memory, not just fit. A conversation at 95% of its window is one long reply from losing its beginning, because systems drop or compress the oldest content when the window fills. The remaining-tokens line is the number to watch across a long session, and starting a fresh conversation with a summary is cheaper than discovering the loss afterwards.
- Rates change; enter today’s. Per-million prices are revised often enough that any printed table ages badly, which is why the rates are fields, not fixtures. The cost per 1,000 requests line exists because per-request costs in fractions of a cent are impossible to budget from, and multiplying by a realistic volume is the step from trivia to a number a budget can hold.
- Code and non-English text estimate worst. The estimator’s rule is calibrated on English prose. Code has dense punctuation (each symbol a token), and many languages tokenize less efficiently than English in models trained predominantly on it. The stated range widens in reality for both; treat estimates there as lower bounds with ambition.
How it is calculated
- The estimator: split the text on whitespace. For each piece, count letters and digits (core characters) and everything else (punctuation and symbols). Piece tokens = ceiling(core / 4) when core is above zero, plus 1 per punctuation character. Total = the sum over pieces. The stated range is the estimate x 0.85 to x 1.15, rounded, reflecting where true counts for English prose usually land against common tokenizers; it is a heuristic range, not a guarantee.
- Context: usage % = (input + output) / window x 100. Remaining = window – (input + output), negative when exceeded, in which case the results say so plainly. Cost: input cost = input tokens x input rate / 1,000,000; output cost likewise; per-1,000-requests = total x 1,000. Costs round to cents, or to 4 decimals when under a dollar, because request costs live there.
Worked examples
Estimating a sentence. “The quick brown fox jumps over the lazy dog.” contains 44 characters and 9 words. The estimator: The 1, quick 2, brown 2, fox 1, jumps 2, over 1, the 1, lazy 1, dog. 2 (one for its letters, one for the full stop) = 13 estimated tokens, with a stated range of 11 to 15. Real tokenizers split this sentence into roughly ten tokens, inside the range, which is all an estimator should promise: the right neighbourhood, honestly fenced.
Usage and cost with exact counts. Input 1,500 tokens, output 500, window 128,000. Total 2,000 tokens: context usage 1.56%, remaining 126,000 tokens. At $3.00 per million input and $15.00 per million output, the request costs $0.0045 in and $0.0075 out, $0.0120 total, which is $12.00 per 1,000 requests. The example shows why both displays matter: the request looks free and the thousand look like a budget line, and both are the same money.
Reading your results
For the estimate, read the range before the headline: if a decision (will it fit in the smaller window, which pricing tier) flips between the low and high ends, the estimate has told you it cannot settle the question and the provider’s tokenizer must. For usage, read percentages as memory pressure, not fullness pride: under 50% is comfortable, over 90% is a conversation living on borrowed turns. For cost, the honest figure is always the volume line; per-request costs flatter every architecture until the requests arrive in their thousands.
Limitations
- The estimator is not a tokenizer. Real tokenizers merge frequent letter combinations into single tokens by learned tables this page does not reproduce. The estimator mimics their average behaviour on English prose (roughly 4 characters per token, punctuation expensive) and says so. Exact counts for a specific model come only from that model’s tokenizer.
- System prompts and formatting count too. Real requests carry instructions, role markers and formatting overhead beyond the visible text, and chat templates add per-message tokens the estimator never sees. Production prompts cost more than their text suggests, typically by a small fixed overhead per message plus the system’s own instructions.
- Prices are inputs, not data. The page holds no rate card. Cached-input discounts, batch pricing, tiered rates and free allowances all exist in real pricing and none are modelled; the cost section prices exactly the two rates entered against exactly the counts entered.
- Context windows are the model’s, entered here by selection. Effective usable context can be lower than the headline window on some systems, and output reserves reduce it further. The window list covers common sizes; the custom field exists because the list cannot be complete for long.
Frequently asked questions
How many tokens are in my text?
Exactly, that depends on the model’s tokenizer, and any page giving one exact figure for all models is guessing in a confident voice. Roughly, for English prose, the estimate on this page and its range: the estimator counts about one token per four characters of letters and digits, plus one per punctuation mark, which tracks common tokenizers to within about 15% on ordinary prose. For a billing-grade count, paste the text into your provider’s own tokenizer tool, then use the second section here for the usage and cost arithmetic on that exact count.
Why do tokens matter more than characters or words?
Because everything in the pipeline is denominated in them: context windows are token limits, prices are per million tokens, and output caps are token counts. A 10,000-word document is not a specification a model can be checked against; its token count is. Words mislead in both directions: short common words are single tokens while a long technical term may be four, and punctuation-heavy code spends tokens far faster than prose of the same length, which is why a calculator that works in tokens, even estimated ones, plans better than rules of thumb in words.
What happens when I exceed the context window?
Depending on the system, the request is refused, or the oldest content is dropped or summarised to make room, silently in some products. Either way the model no longer sees the full conversation, and answers degrade in the specific way of someone who missed the start of the meeting. The remaining-tokens figure in the second section is the early warning: when it approaches your maximum reply length, the next exchange is the one that starts costing memory.
Why is output priced higher than input?
Because generating is the expensive direction: input tokens are processed in parallel batches, while output tokens are produced one step at a time, each step running the full model. Providers price that asymmetry in, commonly at three to five times the input rate, which is why the rates here are separate fields and why verbosity is a cost decision. A prompt that halves the average reply length often saves more than a negotiated input discount.
Related calculators
Method: documented whitespace-and-character-class estimator (ceiling of core characters / 4 per piece, plus one per punctuation character) with a stated heuristic range, and exact arithmetic for context usage and cost at user-entered rates, exactly as defined on this page. Last reviewed: 13 October 2026.