Tokens are the unit every LLM API bills and budgets on. A prompt that "looks short" in the editor can still burn thousands of tokens once the system message, tool schemas, and conversation history are included — and a context window isn't a soft suggestion; when you blow past it, the model truncates, fails, or silently drops the beginning of the conversation.
What a token actually is
A token is a subword chunk, not a word. English averages roughly 4 characters per token, so "tokenization" is about 1 token, but "uncharacteristically" might be three. Code, JSON, and non-English text usually consume more tokens per character than plain English, which is why pasting a large config into a chat feels expensive fast.
You cannot reliably count tokens by counting words. The only accurate approach is to run the same tokenizer the model uses (or a close public equivalent) against the exact string you're about to send.
Why token counts matter before cost does
Cost is tokens × price. Context is tokens ≤ limit. Most production failures show up as context problems first:
- A RAG pipeline that appends every retrieved chunk until the request fails
- A chat UI that never summarizes history and eventually hits the model's ceiling
- A "simple" eval suite whose system prompt + few-shot examples already eat half the window
An LLM Token Counter lets you paste a prompt (or a full message transcript) and see the count before you wire it into billing dashboards.
Turning tokens into dollars
Once you know input and output tokens for a model, pricing is arithmetic — but the rates differ by model family and by whether you're reading vs writing tokens. Output is usually more expensive. Streaming doesn't change the bill; retries and tool-call loops do.
A practical workflow:
- Count tokens for a realistic prompt and a realistic completion length
- Multiply by per-1K (or per-1M) rates for that model
- Scale by expected daily requests
An OpenAI Pricing Calculator is useful for step 2–3 when you're comparing models before locking an architecture.
Context windows are not "unlimited chat"
A 128K or 200K context window sounds huge until you account for:
- System instructions and tool/function definitions
- Retrieved documents
- Multi-turn history
- The model's own output budget (some providers reserve room for completion)
A Context Window Calculator answers the question developers actually ask: "how much of this model's window am I already using?" — not just "how many tokens is this string."
Quick decision guide
- Estimating whether a prompt fits → count tokens, then check against the model window
- Estimating monthly spend → tokens × price × volume
- Debugging "context length exceeded" → measure the full assembled request, not just the user message
- Comparing models → same prompt, different tokenizers and rates; don't assume parity
None of this needs a server round-trip for the measurement itself. Counting and estimating locally keeps proprietary prompts and customer data on your machine while you iterate.
Related reading
If you're also shipping APIs that return large JSON payloads into an LLM pipeline, 5 JSON tools every developer should bookmark covers validating and minifying those payloads before they become expensive context.