LLM Token Counter & Cost Estimator
Paste text to instantly count tokens for Claude / GPT / Gemini / Llama / Mistral. Estimates $USD cost from per-token pricing, shows % of each model's context window (200K / 1M etc.).
⚠ Pricing as of 2026-04. Verify on official pages: Anthropic · OpenAI · Google
📐 Estimation method
- • ASCII: ~4 chars / token (GPT BPE average)
- • CJK: ~1.5 tokens / char (both GPT and Claude)
- • Exact values may vary ±10-20% by model
| Model | Input | Output | In $/MT | Out $/MT | Total cost | Ctx | Used |
|---|
📖 Where people get stuck
Paste text and this estimates the token count and the approximate cost across the major models. Everything runs in the browser. These are estimates: each vendor ships its own tokenizer, and the same sentence can differ by around ten percent between models. When you need exact numbers, use the official token-counting API of the vendor. This screen is for checking you have the order of magnitude right.
| Case | What happens | What to do |
|---|---|---|
| Estimating CJK cost with English intuition | English runs at roughly four characters per token, while Japanese, Chinese and Korean run at one to two tokens per character. For the same character count that is five to eight times as many tokens. Budget from an English prompt and then switch to Japanese, and the bill lands at several times what you planned. | Measure with real text in the language you will actually use. Take the input and output tokens for one request and multiply by your monthly request count before deciding. To reduce cost, translating the data into English is usually worse than writing only the instruction in English and leaving the input in its original language — the instruction is identical on every request, so shortening it pays off across all of them. |
| Budgeting from input tokens alone | Output tokens typically cost three to five times what input tokens cost. Summarising a long document is cheap because the input is large and the output small; generating long text from a short instruction puts nearly the whole bill on the output side even when the input is a few dozen tokens. In a conversation, the further trap is that the entire history rides along as input on every turn. | Estimate input and output separately, multiply each by its own rate, then add. Where the output length is unpredictable, cap it with max_tokens and budget at that cap to stay on the safe side. In conversations, send the last N turns or a running summary instead of the whole history so the token count stops growing with the turn count. |
| Assuming it is fine because it fits the context window | Fitting and being used properly are different things. Within a long input, material in the middle is repeatedly observed to get less attention than material at the start or the end — the lost-in-the-middle effect. Filling the window also raises both the per-request cost and the latency. | Put the important instruction at the end of the input. Pasting the material first and then writing the instruction is more reliable than the reverse. When the document is large, that is the point to stop passing all of it and retrieve only the relevant parts instead — the chunking side of that is covered on the RAG text chunker. |
If you send the same content on every request, check whether prompt caching applies. Caching the leading portion that does not change between requests — a system prompt, a reference document — cuts the input rate for that portion substantially. Taking advantage of it requires structuring the prompt so the unchanging part comes first, so it is worth designing for from the start rather than rewriting later. Rates and eligibility differ per model; check the vendor pricing page.
❓ Frequently Asked Questions
Accurate?
Pricing as of when?
Batch / cache?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.