LLM Prompt Token Counter & Cost Calculator

How This Counter Actually Turns Your Text Into a Number

Short version: nothing here runs a real vendor tokenizer. The tool walks your text with a pattern that splits it the way modern subword tokenizers do, contractions, runs of letters, runs of digits, runs of punctuation, and whitespace, then scales the result for whichever model you have selected. Every count on this page is labeled estimated because it is one.

It's a 200k context window.

It | 's | a | 200 | k | context | window | .

Eight boundaries come out of that ten-word sentence, and two of them are worth noticing. It's splits into It and 's, because the pattern checks for a short list of English contractions before it tries to match a plain run of letters. And 200k splits into 200 and k, because a run of digits and a run of letters are two different categories to this pattern even when nothing separates them. Neither split is a mistake. It is exactly how the estimator is built, and it is close to how production subword tokenizers handle the same input, which is why a shorthand like a number followed by a lowercase k quietly costs two tokens instead of one.

The character count next to the token count is not a separate measurement. It is your text's length in characters divided by whichever token count is currently on screen, which means switching the model dropdown changes the reported chars-per-token figure even though you have not touched the text. That number moves because the token count underneath it moves.

The "words" figure just to the left of the character count is a different measurement again. It comes from splitting your text on whitespace, not from the boundary pattern at all, so a hyphenated compound or a long URL counts as a single word there even though the token boundaries inside it might be several. Words, characters and tokens are three separate counts on this page, and they only ever agree by coincidence.

Why the Same Text Reports a Different Token Count Per Model

The boundaries do not change, the multiplier does. Every model in the dropdown starts from the same raw count, then gets scaled by a factor tied to its vendor, because a pattern shaped around GPT-style tokenization does not split every other vendor's text the same way it splits its own.

250

250 tokens (GPT-4o)
295 tokens (Claude Opus 5)

The 1.18 figure attached to Anthropic's models exists because a GPT-shaped boundary pattern tends to undercount how Claude's own tokenizer splits ordinary prose, by roughly fifteen to twenty percent, and by more once the text turns into code or moves away from English. Google and DeepSeek sit much closer to the baseline at 1.05, and the open-weight families land at 1.10. None of these numbers come from running the actual vendor tokenizer against your text. They come from a fixed multiplier assigned once per vendor family, applied the same way to every prompt that vendor's models see here.

How the Estimate Turns Into a Dollar Figure

Input and output are priced and shown separately, on purpose. The cost you see for your prompt only covers the tokens you typed. Anything the model would generate in reply is a second, independently priced number driven by the Projected Completion Tokens slider.

The primary "Est. Prompt Cost" card multiplies the adjusted token count for your selected model by that model's input price per million tokens, and shows six decimal places because prompt costs at everyday lengths land well under a cent. The Multi-Model Cost Matrix in the sidebar does the same input math for every model in the catalog at once, then adds a second number: your projected output tokens, which default to 1,000 and can be dragged anywhere from 0 to 8,000, multiplied by that model's separate output price per million.

Prompt cost: $0.002500

Output cost: $0.010000
Total: $0.012500

Every row in the Multi-Model Cost Matrix reprices your prompt from scratch rather than reusing the token count shown for your selected model. Each row runs the same raw boundary count back through the same per-vendor scaling described above, using its own model's vendor family, so a Claude row and a Gemini row in the same table can show different token counts for the identical text you pasted, not just different prices for the same count.

That four-to-one gap between input and output pricing on GPT-4o is not unusual. It shows up across almost every model in the catalog: Claude's models charge five times as much to generate a token as to read one, Gemini and DeepSeek sit around four times, and Mistral Large 2 sits around three times. The open-weight entries, Llama 3.3 70B and Qwen 2.5 72B, are the exception, with output priced barely above input. Reading only the sidebar's "Prompt Cost" column and ignoring "Total" hides most of the real cost difference on any prompt where the model is expected to write more than a short reply.

What the Context Window Bar Is Measuring

It is your estimated token count divided by the selected model's own context window, nothing more. That window is read from the catalog entry for whichever model you have chosen, and it is not the same number twice as you switch models.

The catalog's context windows span a wide range: DeepSeek's two models are the smallest at 64,000 tokens, most of the OpenAI and open-weight models sit at 128,000 or 200,000, several Claude and Gemini models reach a full 1,000,000, and Gemini 1.5 Pro tops the list at 2,000,000. A prompt that barely registers against the largest window can be most of the way to the limit on the smallest one.

Just over 78% used
About 14,000 tokens left

2.5% used
About 1,950,000 tokens left

The percentage bar is visually capped at 100%, so a full bar only tells you the prompt has reached or passed the limit, not by how much. A prompt at 105% of a model's window and a prompt at 300% of it both render as a completely full bar. If a prompt is close to a model's window, check the actual token count and the window size in the label above the bar rather than judging distance from the limit by how full the bar looks.

Why Code and Non-Latin Text Do Not Behave Like English Prose Here

The boundary pattern groups characters by category, not by meaning. A run of letters becomes one boundary no matter how long that run is or what language it is written in, and that single rule is responsible for most of the surprises you will see outside plain English sentences.

blue sky today now

4 (blue, sky, today, now)

阳光正好

1 (one unbroken letter run)

Those two examples are visually similar in length and both are made of letters as far as the pattern is concerned, but English separates its words with spaces and Chinese does not, so the letter-run rule sweeps the entire unspaced phrase into a single boundary. Real subword tokenizers spend far closer to one token per character on dense, unspaced scripts like Chinese and Japanese, so this estimator's count on that kind of text should be read as a rough lower bound, not a real figure, and the per-vendor multiplier described earlier does nothing to correct it, since that multiplier is applied by model family rather than by the language it detects.

The same category rule cuts the other way on long numbers and dense punctuation. A run of digits becomes one boundary regardless of how many digits are in it, so a ten-digit reference number counts the same as a single-digit one. A run of adjacent symbols becomes one boundary too, as long as nothing interrupts it, which is common in minified code and compact JSON: brackets, semicolons and arrows chained together with no letters or spaces between them collapse into a single piece here, where a production tokenizer more often splits that same run into several individual symbol tokens. Whitespace is the one category this estimator treats close to how real tokenizers do: indentation, blank lines and trailing spaces each register as their own boundary, so heavily formatted code and prompts padded with extra blank lines genuinely do cost more, on this counter and on the model you eventually send them to.

What to Trim First, Based on the Math Above

Cut the expected reply length before you cut the prompt

Across most of the catalog, generating a token costs several times more than reading one: roughly five times on Claude's models, roughly four times on GPT-4o, Gemini and DeepSeek, and roughly three times on Mistral Large 2. The open-weight entries, Llama 3.3 70B and Qwen 2.5 72B, are the exception, with output priced only slightly above input. Given that spread, asking a model to answer in three sentences instead of three paragraphs usually saves more than trimming an equivalent number of words from the prompt itself, unless you are sending the same short prompt at very high volume.

Strip decorative punctuation

ASCII dividers, repeated dashes or equals signs used as section breaks, and boxed comment banners in code each become their own punctuation boundaries under the rules described above. None of that formatting changes what the model reads as instructions, so removing it before you paste lowers the token count without losing anything the model would have used.

Minify structured data before pasting it

Pretty-printed JSON or YAML carries indentation and line breaks that this estimator counts as real boundaries, the same way a production tokenizer does. Collapsing a payload to its compact form before including it in a prompt removes that whitespace and often merges scattered punctuation into fewer, denser runs as well.

Pick a context window that fits the job, not the biggest one available

Since the catalog's windows run from 64,000 tokens up to 2,000,000, the same reference document can look nearly full on one model and barely noticeable on another. Check the percentage bar for the model you actually intend to use rather than assuming a large window on a different model tells you anything about the one you picked.

Use Visual Tokens to find where the count is coming from

Switching to the Visual Tokens view color-codes every boundary the estimator found and shows each one's position and character length on hover. Scanning that view over a long prompt is a faster way to spot repeated formatting or punctuation-heavy sections eating into your count than reading the single number at the top of the page.

Frequently Asked Questions

Understanding LLM Tokens and Context Costs

Large Language Models (LLMs) do not read text letter by letter or word by word. Instead, they process sequences of tokens, which are chunks of characters representing common character combinations, words, numbers, or punctuation.

Understanding your exact token count is crucial for optimizing system prompts, preventing context window overflow, and reducing API costs across production applications.

Tokenization Comparison Across Top Models