How CalculateToken counts tokens and estimates AI costs

A language model does not read characters or words. It reads tokens — subword units produced by a tokenizer that was fit to a training corpus by finding the most frequent adjacent byte pairs and merging them, repeated until a fixed vocabulary size is reached. A common word usually survives as one token; a rare one, an identifier, or a string of digits gets split into several. Every provider bills per token and measures its context window in them, which is why counting characters or splitting on whitespace does not produce a number anyone can bill against.

The mechanism, and what it predicts about specific text — code, non-English prose, JSON, random strings — is covered at length in What a token actually is. This page covers what happens after counting: how a count becomes a price.

This site uses two genuinely different methods, and which one applies depends on the provider, not on the model you pick.

• GPT models are counted exactly. OpenAI publishes its byte-pair tokenizers (the o200k_base and cl100k_baseencodings), and a JavaScript implementation of them runs in your browser. The number shown is the same one OpenAI’s own encoder would produce for the same text — nothing is approximated, and your text is never sent anywhere to produce it.
• Claude and Gemini are estimated.Neither Anthropic nor Google publishes a tokenizer that can run outside their own servers, and calling a live API per keystroke is not a real option for a tool meant to update as you type. Both are estimated from character length, using a characters-per-token ratio measured per provider against real text — not a generic “divide by four” rule. Every estimated row carries a visible est badge; nothing here presents an estimate as an exact count.

The ratio behind each estimate is not asserted without a source: see Counting tokens for how counting works end to end, and the per-model pages linked below for the specific ratio and tokenizer generation in use for that model.

Every model prices input and output separately, and the two rates are rarely close — output commonly costs three to eight times what input does, depending on the model. This calculator counts and prices the text you provide as input. It has no way to know how long a model’s reply will be before that reply exists, so output cost is not predicted; it is priced per token at the model’s published output rate, for you to multiply by an expected reply length yourself.

That asymmetry is also why a short prompt asking for a long answer can cost more than a long prompt asking for a short one — the input/output toggle above the results table exists specifically so both sides of that trade are visible rather than only the half a visitor happened to think to check.

A model’s context window is the maximum number of tokens it will accept in one request, input and output combined — not a soft limit or a recommendation, a hard ceiling the API enforces. It is a completely separate fact from price: a model can be cheap per token and still refuse a request that is too long for its window, and two models can share an identical window while charging very different rates. Both figures are shown together on every model page for exactly that reason — reading either alone answers half the question.

Several models in this catalogue — the GPT-5.6 line and Gemini 3.1 Pro among them — publish a second pricing tier: below a stated input-token threshold, the normal rate applies; the moment a request’s input exceeds it, the entire request, not just the tokens past the line, is billed at a multiplied rate. This calculator applies that rule wherever a model declares it, using the actual token count of the text you entered — a model priced without accounting for its own tier would understate a large paste by exactly that multiplier. The mechanics and the exact thresholds in play today are worked through with real numbers in The long-context cliff.

Several providers discount tokens that repeat across consecutive requests — a system prompt or a long document resent every turn can be billed at a fraction of the normal input rate on a cache hit. This calculator does not model that discount, deliberately: whether a given request hits a cache depends on how the calling application is built — request ordering, cache time-to-live, provider-specific cache controls — and none of that is recoverable from a block of pasted text. Modelling a discount that may or may not apply would understate some bills and overstate others with no way to tell which from here. The number shown is the uncached rate, which is the ceiling a real bill will not exceed for the tokens counted.

Once a token count exists, the arithmetic is direct: tokens divided by one million, multiplied by the provider’s published per-million rate for the mode selected (input or output), adjusted for two things where they apply — a promotional rate in effect for a limited time, and the long-context multiplier described above, applied to whichever rate the promotion left in effect. Nothing else adjusts the figure. Every rate used is listed, per model, on that model’s own page, next to a link to the provider’s own pricing page so it can be checked independently rather than taken on trust.

This calculator prices one block of text against a provider’s published list rates. A real invoice can differ from that for reasons outside what a single prompt can tell you:

• A production request usually carries more than the message a user typed — a system prompt, tool or function definitions, and resent conversation history all count as input tokens on every call. See The tokens before your prompt starts for what that adds up to.
• Cached-input discounts, covered above, are not modelled here and can lower a real bill below this estimate.
• Retried requests, failed calls that still consumed input tokens, and batch-API discounts where a provider offers one are all outside what a pasted block of text can represent.
• Providers change prices. This site’s catalogue is checked against each provider’s own pricing page, but a rate can move between that check and the moment you read this.

Use this tool to compare models against each other and to catch an order-of-magnitude mistake before it reaches production. Verify anything you are about to commit budget to against your provider’s own billing dashboard.

The catalogue currently covers 15models. The “last updated” date at the top of this page is not hand-typed — it is derived at build time from the last commit that changed the pricing table itself, so it cannot go stale by being forgotten. A banner appears on the site once that date is more than thirty days old; this market has moved fast enough recently — a promotion expiring, two models retiring within weeks of each other — that a slower warning would miss real changes.

Every article and page that quotes a specific price, context window, or retirement date declares what it quotes, and the build fails if a quoted figure no longer matches the catalogue. A stale number in a published page is worse than no page — it stays indexed, gets cited, and nobody reopens it to check — so this is enforced at build time rather than left to review.

• Claude and Gemini counts are estimates, not exact figures — see above.
• Cached-input pricing is not modelled, for the reason given above.
• Output cost is priced per token at the model’s rate, not predicted — this tool does not know how long a model’s reply will be.
• Batch-API and other volume discounts, where a provider offers them, are not modelled.
• This is one site’s reading of publicly published rates, not a data feed from any provider. Independent verification against your own billing is always the last step before committing to a number.

If a rate, a window, or a claim on this site looks wrong, the fastest way to fix it is to say so — here is how to reach us. The project is also open source; the pricing table and every check described above are visible in the repository, and a correction that comes with the source it was checked against is the fastest kind to act on.