Token Counter, Cost, Context & VRAM
Estimate how many tokens a prompt uses, what it costs across the major LLM APIs, which model context windows can hold it, and how much GPU VRAM a model needs to run locally — for budgeting RAG pipelines, weighing model choices, picking a GPU, and avoiding bill surprises.
How to use & examples
- Paste your prompt or context into the box (or click Try an example).
- Set the output assumption — a ratio of the input, or a fixed token budget. Output is billed separately and is usually dearer than input.
- Set the number of calls to project a volume total.
- Read the token estimate per tokenizer family and the cost matrix per model.
- Any price looks wrong or outdated? Edit it inline — the matrix recomputes live. Add your own model with Add a model.
- Export the estimate (JSON / CSV / Markdown) with the as-of date and your assumptions baked in.
| Case | Input | What you get |
|---|---|---|
| Good (prose) | ~1k words of English | ~1.3k GPT tokens (est.); cost e.g. GPT-4o-mini < $0.001/call |
| Edge (code) | A dense JSON / config blob | Higher token count — the symbol-density penalty kicks in above 25% punctuation |
| Edge (CJK) | Chinese / Japanese text | Roughly 1–2 tokens per character; estimate adjusts upward |
| Edge (empty) | Nothing pasted | 0 tokens, $0 — no fabricated numbers |
How the token number is derived: characters ÷ a per-family chars-per-token ratio
(GPT 4.0, Claude 3.8, Gemini 3.7, Llama 3.9), times a code/symbol-density penalty, plus an added
contribution for CJK/non-Latin characters, with a per-word floor. It is a calibrated approximation,
not the vendor's real BPE. Cost formula:
perCall = inputTokens÷1e6 × $in/Mtok + outputTokens÷1e6 × $out/Mtok,
and volume = perCall × calls. Prices are in US dollars per 1,000,000 tokens.
—
Output assumption
Most APIs price input and output separately, with output ~3–5× dearer. Set the assumed response length:
Volume
Token estimates by tokenizer family
| Tokenizer family | Input (est.) | Output (est.) | Total (est.) |
|---|
Cost matrix
Prices in USD per 1M tokens. Each row shows the date its price was checked against the provider (the hosted open-model rows are illustrative, from ). Figures are a list-price snapshot and may be outdated — edit any cell to use your own, and always confirm with the provider. Sources are linked per row.
| Model | Input $/1M | Output $/1M | Per call | Volume total | Source | Remove |
|---|
Add a model
Not listed, or want a custom tier? Add your own row. Custom prices are yours — no source is implied.
Export estimate
Exports include the as-of date, your assumptions, and the honesty caveats, matching what you see here.
How the estimates work (method & limits)
- GPT family (cl100k / o200k base): chars ÷ 4.0, × a symbol-density penalty, plus a word-count floor. OpenAI and OpenAI-compatible models; Mistral is close.
- Claude: chars ÷ 3.8 (slightly less efficient on English than GPT). Claude Opus 4.7 and later models use a newer tokenizer that Anthropic says produces about 30% more tokens, so their rows multiply the Claude estimate by 1.3.
- Long prompts: some models charge a higher rate above a prompt size (OpenAI GPT-6 and GPT-5.5 above 272K tokens, Claude Haiku 5.5 above 100k, Gemini 2.5 Pro and 3.1 Pro above 200k). The matrix switches to that rate automatically.
- Gemini: chars ÷ 3.7 (SentencePiece; often fewer tokens on multilingual text).
- Llama 3 / DeepSeek / Qwen / Mistral: chars ÷ 3.9 (128k-vocab BPE, similar to GPT-4o).
- CJK / non-Latin: each character adds ~1–2 tokens on top of the Latin estimate.
- Code & high-symbol text: a 4–10% penalty applies once punctuation density passes 15% / 25%.
- Limits: this is a calibrated heuristic, not the real BPE. It can be off by 10–30% on code and non-Latin scripts. For exact counts use tiktoken (OpenAI), the Anthropic
count_tokensAPI, or the vendor's tokenizer.
Add files
Drop text files here
· .txt, .md, .json, .csv, .log, .py, .js, .go etc, up to 5 MB each
Response budget
Reserve room for the model's reply. Most chat sessions need 500-2000 tokens; agentic / verbose JSON outputs may need 4-8k.
Fit by model
| Model | Context | Fill (input + budget) | Verdict |
|---|
What "fits" really means
- Input + reserved output must fit within the advertised context. The response budget is added to the input estimate before comparing. Token counts are the same heuristic estimates as the Cost tab, not exact counts.
- Effective recall degrades long before the hard limit. Anthropic and Google publish "needle-in-a-haystack" benchmarks showing usable recall well below 100% for very long contexts.
- Costs scale linearly with input tokens. Use the Cost estimate tab to price the call.
- Some vendors charge more for prompts above a threshold (e.g. Gemini 2.5 Pro > 200k tokens) — the Cost tab switches to that rate automatically.
Will that model fit on this GPU? Pick a preset or enter your own shape, choose a quantization, set the context length, and see the breakdown: weights, KV cache, activations, total VRAM. Pure arithmetic, nothing leaves your browser.
Model
For GQA models (Llama 3, Mistral). MHA: equal to attention heads. MQA: 1.
DeepSeek V2/V3/R1 cache one compressed vector per layer (512 + 64 = 576 values) instead of K and V per head. 0 = standard attention.
Quantization & runtime
Estimates are an arithmetic upper-bound for inference. Real numbers vary ± ~10% across runtimes. For training, multiply weights by ~3-5× (gradients + optimizer states).
Common GPUs
| GPU | VRAM | Fit |
|---|
Math behind the numbers
- Weights = params × bytes-per-param. FP16 = 2 B/p, INT4 = 0.5 B/p, GGUF varies.
- KV cache = 2 (K and V) × batch × ctx × layers × kv-heads × head-dim × bytes-per-elem.
- Activations add ~7-15% on top depending on runtime; we use the runtime overhead slider.
- Long contexts are dominated by KV cache; quantising KV (INT8 / INT4) is the biggest lever.
- Multi-GPU reduces per-GPU memory, but inter-GPU comms add overhead. We don't model that — check vLLM / TGI docs.