Cost per attempt
--
INSTRUMENT | Reliability testing
LLM Token Counter: Context Budget and Cost per Attempt
1 cited source
Count tokens for a named model, see what the request reserves in the context window once output is set aside, and price one attempt at your own rates. Exact where we bundle the encoding.
Paste text, pick a model, and get the token count, what the request reserves in the context window, and one attempt's cost at your own rates. It starts on a sample: 44 characters, 10 tokens.
The count is exact for OpenAI families and an estimate elsewhere, and says which. A count is a budget: runtimes cut a payload at a token cap before the model reads it, and silent context truncation is a named failure mode.
Showing your last valid result. Update the inputs above to recompute.
Text tokens
10
exact | o200k_base, OpenAI's encoding | this text only
Everything the count implies for one request.
| Quantity | Value | How it is derived |
|---|---|---|
| Code points | 44 | characters, counted once each |
| Code points per token | 4.40 | code points ÷ tokens |
| Input tokens | 10 | text tokens + overhead |
| Output reserved | 0 | what you set aside for the reply |
| Reserved total | 10 | input + output |
| Context window | 1,050,000 | read off the vendor's page |
| Share of window used | 0.0% | reserved ÷ window |
| Tokens left | 1,049,990 | window − reserved |
o200k_base | asset letk-1 | limits read 2026-08-25. The provider's own count can differ.
These are your own rates. We filled nothing in.
Floor on one success
--
Enter your own rates to price this request. The right-hand figure divides the attempt by the pass rate, so it is a floor: it counts no review, no retry and no fallback.
reserved = text tokens + overhead + output; share = reserved ÷ windowHow?
How this is calculated
Two modes, never blurred. Where we bundle the encoding, the
text is run through that encoding's own byte-pair merge and the count is
exact: the same number the encoding's reference implementation gives, checked
case by case in our unit tests against it. o200k_base and
cl100k_base, both OpenAI's, are the two we bundle. Every other
family is estimated from characters per token and labeled an estimate, with
the range it sits in and the encoding those measurements came from.
Why Claude and Gemini are estimates. Neither vendor publishes a tokenizer you can run locally. Counting them exactly means asking the provider, which is a model call, and this page makes none. So they get the ratio estimate, and the caption says so rather than printing an OpenAI number under a Claude label.
The Claude 4.7 change, and why its range is wide. Anthropic states that Claude 4.7 and later use a newer tokenizer, that the same text produces about 30 percent more tokens than on earlier models, and that the exact increase depends on the content. Its own pages put that increase at two different figures: the token-counting page says about 30 percent, while the models overview says a million tokens holds roughly 555,000 words on the current tokenizer against about 750,000 before it, which is nearer 35 percent. So the two Claude rows are separate rows with separate numbers, and the newer one divides the measured ratios by 1.20 through 1.40 rather than by a single figure. Picking one number would have printed a false precision on top of an estimate.
What the wrapper adds. A paste box counts text. A real request also carries the chat wrapper around each message and whatever you set aside for the reply. OpenAI documents that wrapper for its own chat models: three tokens per message and three priming the reply, called an estimate there too, not a guarantee for every current or future model. This page carries the same estimate across the OpenAI family. No other provider publishes a wrapper rule at all, so their overhead is zero and the page says the cost is real but unpublished rather than inventing one. System prompts and tool schemas count only if you paste them.
Worked example (the sample, on the default model, with two messages and 1,000 output tokens reserved):
text tokens = 10 under o200k_base
overhead = 3 × 2 + 3 = 9
input tokens = 10 + 9 = 19
reserved = 19 + 1,000 = 1,019
cost = (19 × input price + 1,000 × output price) ÷ 1,000,000,
because published prices are quoted per million tokens.
What the estimate rests on, and which band your text takes. There are two bands, and the split is about how densely a script packs into tokens rather than about which alphabet it uses. The standard band was measured on prose, source code and JSON in Latin, Cyrillic, Arabic, Devanagari, Greek, Hebrew and Vietnamese, which all land between 2.69 and 5.00 characters per token. The dense band was measured on Han, Japanese, Hangul and Thai, which land between 1.33 and 2.63. Text takes the dense band when more than half of its non-space characters are in one of those scripts. A page that sorted scripts into "Latin" and "everything else" would put Russian prose in the dense band and overstate its token count by about three times, which is why this one sorts by what it measured.
None of these points was measured under Claude's or Gemini's own tokenizer, because there is none to measure with, and the caption says so every time an estimate is shown. Until a band carries twelve points across four kinds of text, the page also says its range is not validated. Neither band carries that today: the standard band has thirteen points across three kinds of text, and the dense band has seven across two.
Formula: reserved = text tokens + overhead + output; share = reserved ÷ window
A token count is a budget, not a receipt
The number a token counter gives you is the start of three different questions, and most counters answer only the first. How big is this text. Will the request fit. What will it cost to run enough times to trust the answer.
How big is this text. This is the part that can be exact, and only for the families whose encoding we ship. A tokenizer is a specific table of byte sequences and merge priorities that one vendor trained, and it treats scripts very unevenly: the same sentence in Japanese and in Spanish does not cost anything like the same number of tokens. Two vendors counting the same sentence get different numbers, and the same vendor counting it a year later can get a different number again, which is exactly what happened to Claude at 4.7. That is why this page keys its map on the encoding rather than on a model name: model names age faster than encodings do.
Will the request fit. A context window is not a target to fill. The share of the window a request spends is the number worth watching, because the useful capacity is smaller than the stated one: retrieval performance falls when the relevant passage sits in the middle of a long context rather than at either end, which is the finding in the paper listed under Sources. A request at 90 percent of the window has not used the window well. It has left no room for the reply, and it has put its own evidence in the region a model reads least reliably. That is the reason this readout subtracts the output you reserve before it tells you what is left, and the reason the chunk-size calculator reports the same share for a retrieval plan rather than a raw chunk count.
What will it cost. An attempt price is the easy half. Multiply tokens by your rate and you have what one call costs, which is what the price block above gives you. The hard half is that a call which fails costs the same as one that succeeds. Divide the attempt by the pass rate and you get a floor on what one success costs, and it is only a floor: it counts no human review, no retry, no fallback to a larger model, and none of the time spent noticing the failure in the first place. A tool that quotes you the attempt price and stops has told you the cheapest possible version of your bill.
Sizing a whole evaluation run rather than one request is a different calculation, with trials, graders and review time in it; the eval budget calculator does that one, and shares this page's dated rate presets so the two agree on what a model costs.
Where the numbers on this page come from, and where they stop. The context window and output cap on every row were read off the vendor's own page by a person, on the date shown under the table. Prices are yours by default, and a preset fills them only when you ask, showing the day we read it. Nothing on this page calls a provider, so nothing here can tell you what the provider's own counter would say. Where the two disagree, the provider is right and this page is an estimate of it, which is the honest order.
Questions
Why is the Claude count an estimate and not a real count?
Anthropic publishes no tokenizer you can run on your own machine. The only exact Claude count comes from asking Anthropic's own endpoint, which is a model call, and this page makes none: everything happens in your browser and nothing leaves it. So Claude rows get a character-ratio estimate with a stated range, and the caption says how many points that range rests on and which encoding they were measured under. Running an OpenAI tokenizer and putting a Claude label on the result would give you a confident number that is wrong, which is worse than an honest range.
Why are there two Claude rows?
Because Claude changed tokenizer at 4.7 and the same text now costs more tokens. Anthropic states the increase is about 30 percent and that the exact figure depends on the content, and its own two pages give slightly different numbers for it. One row covers Opus 5, Sonnet 5, Fable 5 and the 4.7 and 4.8 Opus models; the other covers Haiku 4.5, which predates the change. Picking the wrong one moves your answer by roughly a third, which on a token counter is the whole answer.
The count here does not match what my provider billed me. Which is right?
The provider. This page counts the text you pasted, and a billed request also carries a system prompt, tool definitions, prior turns, and whatever the runtime adds around them. Set the message count and the reserved output above to close part of that gap, and paste your system prompt if you want it counted. Even then, providers describe their own counts as estimates that can differ by a small amount, so treat any local count as a budget you plan against rather than an invoice you reconcile to.
What does the range next to an estimate mean?
The point figure divides your character count by the middle of a measured band; the range divides it by the two edges of that band. The band is wide because the real ratio moves a long way with the kind of text: dense prose, minified code and Chinese characters all tokenize at very different rates. A counter that prints one number for every kind of text hides the spread. When the range is too wide to be useful, that is the answer: the estimate cannot tell you more than that.
Is anything I paste sent anywhere?
No. The tokenizer is a file your browser downloads once, and the counting runs on your machine. Nothing you type is sent to us, to a model provider, or into an analytics event; the page records that a count happened, never what was counted. The tokenizer file itself is only fetched the first time you ask for an exact count, so opening the page costs you nothing.