Token & cost estimator

The number you've been estimating is probably wrong

If you've been sizing Claude requests with tiktoken, stop — tiktoken is OpenAI's tokenizer, built against a different vocabulary entirely, and it documentedly undercounts ordinary Claude prose. The gap is worse on code and non-English text, where token boundaries diverge from GPT's vocabulary even further. The only correct source is Anthropic's own counting endpoint, and it counts against the exact model you're about to call, because token counts on this site's model lineup are not identical model to model even for the same input text.

What paste-and-count actually shows you

Paste text below and this tool returns its real token count and the resulting cost across every current model side by side — not one estimate, but the actual spread, because the cheapest and most expensive models in the current lineup differ by an order of magnitude per token. It also shows the tiktoken figure for the same text next to the real one, so the size of the error is visible rather than asserted. For most teams that gap has been invisible for the simple reason that nothing before now put both numbers on the same screen.

Why the count itself moves between model generations

Token count for identical text is not even stable within Claude's own model family. The tokenizer introduced with the newest Opus generation counts differently from the one older Opus models still use, and the newest Sonnet counts noticeably more tokens than its predecessor did for the same input at the same headline per-token price — which means a sticker-price cut is not automatically a bill cut once you re-run the actual count. If you're planning a model upgrade rather than just pricing a single request, re-count your real prompts against the new model id before assuming the old estimate still holds; do not carry a token budget forward from one generation to the next unchecked.

Where this feeds into the rest of the site

A token count on its own is only half the picture once a request is part of a repeated pattern rather than a one-off. If the same prefix recurs across requests, the prompt-caching savings calculator takes the count this tool gives you and prices it against the cache-read and cache-write rates instead of the standard per-token rate. And if you're trying to fit a whole codebase or document set rather than a single paste, the context-window planner is the better starting point — it estimates volume rather than pricing a single block of text.

What this tool does not do

It does not estimate output tokens, because output length is a property of what the model chooses to say, not of your input — there is no reliable way to predict it from the prompt alone. Where you need a full request cost including a plausible output, the subscription vs API cost calculator is the tool built for that, taking a typical output length as one of its inputs rather than guessing one.