Shipping a complex prompt only to find a massive invoice charged against your account waiting on the other side is a modern engineering rite of passage, and the reason it keeps happening is that legacy workflows offer no native way to count, estimate, or audit text thresholds before a request fires. For teams running even moderate AI workloads, token costs have become the new server costs, creeping up and compounding across teams, projects, and sessions until someone on the finance side demands to know where the spike came from. Token counting before the API call fires is the only way to answer that question from the engineering side before an invoice does it for you.
Most tools that give you a token count call the API first, which means you have already paid for the count the moment you get the answer. That is a control problem, not a workflow problem. If you cannot verify the size of what you send before it leaves your machine, you cannot make routing or budgeting decisions that survive scrutiny in a client invoice or a post-mortem cost review. Prompts that cost a dollar to validate already exceed what the count is worth in the first place.
Counting tokens locally in the browser puts that control back in your hands. The prompt stays on your machine, the count updates as you type, and the numbers you see are the same ones the API invoices against. There is no extra round-trip needed to know whether a prompt will fit the window, whether it will overshoot the budget, and whether it needs trimming before it goes out. This article explains where tokenizer differences come from, what the context bar colours actually mean, how routing by size and task type controls costs, where exact counts are essential and where an approximation serves, and why the location of the count matters as much as the number itself.
Why token counting belongs in your pre-send workflow
Every AI bill overrun shares the same anatomy. A developer ships on a Friday afternoon under $50 this month, and the billing alert fires Monday at over $300. No code was changed, no prompt was altered, and the session simply turned over on itself, devouring tokens line after line until the output budget alone crossed the monthly threshold. With text sizes invisible until the API responds, developers have no way to verify the actual token volume before the charge lands. A silent session crossing budget is the new normal. The cost surprise isn’t that tokens are expensive. It is that token counts are invisible before the API processes the text. Counting before the request fires changes which model handles which prompt.
This is where a local token counter becomes the first useful answer. Count tokens before the prompt leaves your machine. You will know instantly whether the prompt fits the model window, whether it costs more than expected, and whether it needs to be trimmed, split, or re-routed to a cheaper model. Because the counting runs locally, nothing leaves your machine, no request exits, and the token count is exact. The counters are live.
What tokenization actually is and why model families disagree
Tokens are the billing unit for every major AI API. The context window, the maximum text a model can hold in memory at once, is also measured in tokens, not characters or words. A 1M-token context window sounds enormous until a single dense research paper exceeds 100K tokens by itself.1
Because every provider trains its vocabulary separately, the same prompt produces different token counts from OpenAI, Anthropic, Google, DeepSeek, and others. A prompt safe for one model’s window may silently exceed another’s five times over. The following table from CapyToolkit’s browser-based token counter that counts prompts across 35+ AI models without an API call, refreshed in May 2026, includes input and output prices across 35+ providers alongside context window and tokenizer type, so you can compare all dimensions at once.
| Model family | Tokenizer | Approx. Context | Input $/M | Output $/M |
|---|---|---|---|---|
| Claude Opus 4.8 | Anthropic exact | 1M | $5.00 | $25.00 |
| Claude Sonnet 4.6 | Anthropic exact | 1M | $3.00 | $15.00 |
| Claude Haiku 4.5 | Anthropic exact | 200K | $1.00 | $5.00 |
| GPT-5.5 | tiktoken (o200k_base) | 1.05M | $5.00 | $30.00 |
| Gemini 3.5 Flash | character / 3.8 ~ | 1M | ~$0.30 | ~$1.00 |
| Gemini 3.1 Flash-Lite | character / 3.8 ~ | 1M | $0.25 | $0.25 |
| DeepSeek V4 Pro | cl100k_base ~ | 1M | $0.44 | $0.87 |
| Kimi K2.6 | character / 3.8 ~ | 262K+ | ~$0.60 | ~$2.50 |
| MiniMax M2.7 | character / 3.8 ~ | 1M | ~$0.40 | ~$2.20 |
| Qwen 3.6 35B | cl100k_base ~ | 1M | ~$0.30 | ~$1.80 |
| GLM 5.1 | character / 3.8 ~ | 128K | ~$0.50 | ~$1.50 |
Tilde (~) marks indicate approximate tokenizer modes. DeepSeek and Qwen develop and maintain their own open-source tokenizers; local browser tools fall back to an approximate mapping when no native JS/WASM port is available in-client.
How token counts vary across model families
Tokenizers differ by method and by consequence. For GPT models, tiktoken ships as a published open-source library based on the vocabulary OpenAI publishes in the tiktoken repository, and the resulting count is byte-for-byte identical to what the API returns.2 Claude provides the @anthropic-ai/tokenizer NPM package, and that matches their billing endpoint. Both tools run in the browser with no network request and no server call.
Approximate tokenizers use a character-division rule of thumb, dividing the text length by roughly 3.8 characters per token.3 This suffices for typical English prose within a 12 to 15 percent margin. The problem shows up at the edges. A single word like “tokenization” might cost one token in a modern GPT vocabulary but two tokens in an older vocabulary that splits it as “token” plus “ization”. Under an approximate scheme that split disappears, and a string of technical vocabulary, uncommon proper nouns, or well-formatted code compounds the error over thousands of characters. Code-heavy prompts and multilingual text are the most exposed cases. Approximate tokenizers return fast counts that are close enough for sizing comparisons, directionally correct, and useful for triage. Exact counts are free when running in-browser, and they carry no hidden cost. When you are billing a client by token or building a cost-tracking dashboard, use the exact tokenizer. For all other purposes the approximate count gives a correct enough signal to make the provisioning decision.
The context bar is not cosmetic
Most providers display a second metric alongside the token count: a colour-coded context bar that translates the raw number into a visual signal of proximity to the model’s limit. The bar starts green to show the prompt fits comfortably under the window. At 75 percent it shifts to amber, and at 95 percent it turns red. Across the 37 models in the tool, each bar is independently calibrated against that model’s own architectural limits rather than a shared common denominator.4
These threshold signals are not cosmetic. An amber bar at 75 percent means only a quarter of the context window is left for the model’s reply. A red bar at 95 percent signals that truncation or rejection is imminent. GPT-5.5 at 1.05M tokens might still show green for a prompt that truncates Claude Haiku at 200K. Conversely, a prompt safe for most providers might still tip a model with a smaller window into red. The bars exist because context budgets are per-model.
Four context thresholds govern most production use cases:
- Below 75 percent in the green zone. The prompt fits safely, continue monitoring as conversation usage grows.
- Between 75 and 94 percent in the amber zone. Shorten the prompt or split it across two calls.
- Between 95 and 99 percent in the red zone. Prune the conversation history, summarize older turns, or re-route to a larger-context model before the API rejects or truncates the input.
- At or beyond 100 percent. The API will reject or silently truncate. Route to a larger-context model if reduction is not possible.
Context-awareness must be the default in any production pipeline. New users often reach amber before noticing, usually driven by unchecked conversation loops, recursive RAG document retrieval, and continuous system instruction bloating: a system instruction starting at 500 tokens and growing to 2,000 tokens over a few months of iteration reduces per-request budget for every call with no environment reflecting the change. Without a live count, it stays hidden until the bill arrives.
Route prompts by context needs and cost tier
The pre-send token count is the point at which you decide where a prompt goes. Consider the prompt size and content characteristics, not the model your team uses by default. You cannot reliably re-tokenize at the provider after sending. Once a request fires, the token count represents something already charged. Routing decisions must be made beforehand. Run exact counts that match what the API invoices for critical budget items or client-billed work. For directional estimates, approximate counts are directionally accurate. They do not replace exact counts when client billing or a precision audit depends on validated token totals.
Triage routing by context state
The amber and red bars in any token count interface serve as a triage gate. If a model is in the red after you’ve counted, do not retry on the same model. The context problem does not change across retries. Check whether a cheaper, higher-context alternative can handle it instead. Switching from Claude Opus at $5 per million input tokens to Claude Haiku at $1 per million input tokens preserves functionality while cutting the input cost by 5×.5 Output tokens typically run 4–5× more expensive than input tokens across major providers, a ratio visible in how large language model API pricing is structured across provider tiers. For large volumes that gap becomes consistent savings.
Cost efficiency by task type
For task-type routing, cheaper models consistently hold their own on summarization, classification, and structured extraction. The quality gap matters most when the task involves coding, reasoning, or creative writing. Routing by task type is a simple way to control spend without losing much accuracy on bulk work. The difference between a $1 / MTok input tier and a $5 / MTok input tier compounds quickly at volume. For a team running 10,000 summarisation calls a month at 10,000 tokens each, switching from Opus to Haiku cuts the input bill from $500 to $100.6
Three cost-aware workflow patterns
Pattern 1. Conversation history pruning. Summarise or compress the oldest multi-turn exchanges before a conversation’s live prompt length crosses the 75 percent amber threshold. The saved tokens cost nothing extra; you have paid only the summarization compute, not the ongoing cost of a bloated context trail.
Pattern 2. RAG pipeline cost gate. Count the assembled prompt, system instructions and retrieved documents all bundled with the current user query, before the LLM API call goes out. If the total is above your target model threshold, prune the retrieved set or route to a larger-context model before the request fires. A pre-flight check costs zero against the cost of an API call that truncates or fails.
Pattern 3. Batch job cost gate. For overnight batch inference, pre-stage the full set, sum token counts against a daily rate cap, and then send. If one prompt in a thousand would overshoot, catching it before the first token is processed prevents the batch from failing mid-run and gives you time to split, compress, or downgrade before the provider cluster wakes up. You cannot catch this after the first API call has fired. The batch cost estimator that totals token counts across a full prompt set before any API call fires makes this pre-staging step direct. Pair this pattern with CapyToolkit’s free browser-based developer tools that keep all data off third-party servers for a fully local pre-flight workflow.
When to trust the exact count and when ~ will suffice
A short English prompt under 4,000 tokens: approximate error is below two percent. A code-heavy prompt, a prompt that includes non-English characters, or a very long assembled context of more than 40,000 tokens: the gap between approximate and exact widens. The error direction matters more than the error magnitude. Approximate counts overestimate slightly for dense code content, and they come in above the exact number because short identifiers and braces tend to fall below the average character-to-token ratio. For English prose the approximation stays close enough for use in sizing and routing.7
GPT-5.5 and Claude provide exact, on-browser token counts without a network call. That means you can load the page once, then count prompts entirely offline. DeepSeek and Qwen maintain distinct open-source tokenizers, and both operate vocabularies well above 100K tokens for multilingual and source-code efficiency; local browser tools fall back to a close approximation when no native JS/WASM port of the exact tokenizer is available in-client.89 For Gemini, Kimi, MiniMax, and Grok, local tools deploy a character-division formula as a high-fidelity proxy; these providers do not always publish lightweight native tokenizer libraries for in-client use, so the in-client environment approximates token limits via the ~3.8 character-to-token ratio observed across browser-based token counters and confirmed in the Google Gemini API documentation.4 The conservative nature of the approximate approach means it is directionally useful, not a substitute for an exact route.
For billing clients by the token, an invoice requires exact counts from the provider’s own system. For cost-tracking dashboards, approximate counts over time are directionally useful. For every situation in between, test the model you are counting against before you rely on the counts for a production decision.
Keeping your token counts honest and private
The most overlooked constraint in token counting is where the count happens. If you count tokens on the provider using an API call, you have already transmitted the prompt content. The token count accuracy is no longer under your control once it depends on the provider processing the text, and by the time the response arrives, you have already paid for it.
The context window overflow checker that flags when a prompt is about to exceed model limits in the browser keeps all counting entirely in the browser tab. Based on the same libraries the providers publish, the count matches what the API bills because the same tokenizer logic has already been run. You can verify this easily: open your browser DevTools Network tab, type into the box, and observe that no outbound requests fire. Every character of your prompt stays on your machine.
- 1.
Google AI for Developers, “Long context,” ai.google.dev, accessed June 2026. https://ai.google.dev/gemini-api/docs/long-context
- 2.
OpenAI, “Counting tokens,” developers.openai.com, accessed June 2026. https://developers.openai.com/api/docs/guides/token-counting
- 3.
OpenAI, “What are tokens and how to count them?,” help.openai.com, accessed June 2026. https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
- 4.
Google AI for Developers, “Understand and count tokens,” ai.google.dev, accessed June 2026. https://ai.google.dev/gemini-api/docs/tokens.md.txt
- 5.
Anthropic, “Models overview,” platform.claude.com, accessed June 2026. https://platform.claude.com/docs/en/about-claude/models/overview
- 6.
Anthropic, “Pricing,” platform.claude.com, accessed June 2026. https://platform.claude.com/docs/en/about-claude/pricing
- 7.
“Byte-pair encoding,” Wikipedia, accessed June 2026. https://en.wikipedia.org/wiki/Byte_pair_encoding
- 8.
Jinze Bai et al., “Qwen Technical Report,” arXiv preprint, September 2023. https://arxiv.org/abs/2309.16609
- 9.
DeepSeek-AI, “DeepSeek-V3 Technical Report,” arXiv preprint, December 2024. https://arxiv.org/abs/2412.19437
