Token Counter & Cost Calculator

What a token actually is

Language models do not read characters or words. They read tokens: sub-word units produced by a byte-pair encoding trained on a corpus. Common words are usually a single token, uncommon ones split into several, and the split is not intuitive.

For ordinary English prose, roughly four characters per token is a decent rule of thumb. That rule breaks down quickly elsewhere. Code is denser because punctuation and indentation consume tokens. JSON is worse still — every brace, quote and colon costs something. Languages that do not use spaces, such as Chinese and Japanese, are much denser per character, and text in scripts poorly represented in the training corpus can cost several tokens per character.

This is why token counts matter beyond curiosity. They determine whether a document fits the context window, what a request costs, and how much of your budget goes on prompt overhead rather than useful content.

Which counts are exact, and which are not

This distinction is worth being blunt about, because most token counters obscure it.

OpenAI publishes its tokenizer vocabularies — cl100k_base for GPT-4 and GPT-3.5, o200k_base for GPT-4o and later — so a browser can reproduce those counts exactly. When you select one of those, the number shown is the number the API will charge for.

No other major vendor publishes a client-side tokenizer. For Claude, the authoritative count comes from Anthropic's `count_tokens` API endpoint, which requires an API key and a network request — neither of which a purely client-side tool has. Any browser tool claiming an exact Claude token count is estimating and not saying so.

The estimates here are derived from a measured characters-per-token ratio with an adjustment for dense scripts. Expect them to land within roughly 10–15% for English prose, and to drift further on code, structured data and non-Latin text. Use them for planning; use the API for billing reconciliation.

Reading the context window figure

The context window is the total budget for everything the model sees in one request: your system prompt, the conversation history, any documents you have attached, and the response it generates. Exceeding it is an error, not a graceful truncation.

The bar shows how much of the window your input consumes. Two things people underestimate: conversation history grows every turn, because the whole history is resent each time, and the output has to fit in the same window as the input.

A million-token window sounds like it removes the problem, and for a single document it usually does. For a long agentic loop it does not — history accumulates, and the cost of resending it grows linearly with the conversation.

This is where prompt caching earns its keep. Where a large stable prefix is reused across requests, caching can cut its input cost by around 90%. The saving is largest exactly where the context problem is worst.

Estimating cost honestly

Pricing is quoted per million tokens, split between input and output, and output is invariably the more expensive side — often five times the input rate. A workload that generates long responses costs very differently from one that reads long documents and answers briefly, even at identical total token counts.

The calls multiplier is there because unit cost is rarely the interesting number. A request costing a fraction of a cent is irrelevant alone and material at a million a month, and that is the figure worth putting in front of anyone approving a budget.

This tool states Anthropic's published rates with the date they were captured, and deliberately does not assert rates for other vendors — a stale price in a cost calculator is worse than no price, because it looks authoritative. Enter current rates yourself for anything else.

Two adjustments are worth remembering when budgeting: batch processing typically costs around half the standard rate for work that is not latency-sensitive, and prompt caching substantially reduces the cost of any repeated prefix.