Developer tool · LLM context windows
See exactly when your chat outgrows its context window
Build a multi-turn conversation and watch it fill 8K, 32K, 128K and 200K token windows at the same time. Then compare five truncation strategies and see what each one keeps, drops and costs — before your users hit the limit in production.
How full is each window?
Click any segment to jump to that message. The black tick is the hard window limit; red hatching past it is what the API would reject.
Growth: cumulative tokens per message
Truncation lab: what survives?
When the conversation no longer fits, something has to go. Pick the window you deploy on and compare five strategies on this conversation. The system prompt is always kept; the reply reserve is always protected.
| Strategy | Fits? | Prompt tokens | Messages kept | History retained | Oldest kept |
|---|
Select a row to preview exactly which messages survive, then copy the trimmed conversation as API-ready JSON.
Preview
What does resending history cost?
Chat APIs are stateless, so every turn resends the full history. “Cumulative resend cost” sums the size of every request so far — that is why long chats get expensive quadratically, and why truncation and prompt caching pay for themselves.
How to use the visualizer
- Load or write a conversation. Pick a preset such as the coding assistant or RAG agent, or edit the system prompt and messages directly. Token counts update as you type.
- Read the four window bars. Each bar stacks your messages inside an 8K, 32K, 128K or 200K window. The striped segment at the end is the reserve you keep free for the model’s reply.
- Find the overflow turn. The growth chart plots cumulative tokens per message and marks the exact turn where each window fills, plus how many average turns remain.
- Compare truncation strategies. In the truncation lab, pick a target window and compare what drop-oldest, sliding-window, head plus tail, summarization and per-message caps keep or lose, then copy the result as JSON.
What the four windows actually hold
For English prose, one token is roughly 0.75 words — about 4 characters. Code, JSON and many non-English languages cost more tokens per word, so treat these as best-case capacities.
| Window | Tokens | ≈ Words | ≈ Pages* | Feels like | Typical use |
|---|---|---|---|---|---|
| 8K | 8,192 | 6,100 | 12 | A long article | Small / on-device models, short support chats |
| 32K | 32,768 | 24,500 | 49 | A novella chapter | Coding assistants, RAG with a few documents |
| 128K | 131,072 | 98,000 | 196 | A short novel | Long agents, whole codebases, document Q&A |
| 200K | 200,000 | 150,000 | 300 | A full novel | Research sessions, large transcripts, legal review |
*At roughly 500 words per page. Note that “200K” models budget exactly 200,000 tokens, while 8K / 32K / 128K are powers of two (8,192 / 32,768 / 131,072). The visualizer uses the exact numbers.
How tokens are counted here
Real tokenizers (OpenAI’s BPE family, Anthropic’s tokenizer, Llama SentencePiece) split text into learned sub-word pieces, so counts differ slightly per model. This page estimates counts in your browser with a BPE-style heuristic: text is segmented into words, numbers, punctuation and whitespace; each piece is scored by length (short words cost 1 token, longer words roughly 1 token per 4 characters, digits roughly 1 per 2–3 characters, CJK characters about 1 each). It then adds 4 tokens of chat-format overhead per message plus a 3-token conversation primer, matching the accounting OpenAI documents for chat completions. Expect results within roughly 10–15% of a vendor tokenizer for English and code — close enough to plan windows and budgets, not to audit an invoice. For exact counts, run your model vendor’s tokenizer, and count your own words with the Word Counter.
The five truncation strategies, honestly
1. Drop oldest turns
Remove whole user+assistant exchanges from the front until the prompt fits. This is the safest default: a reply is never separated from its question, and the model never sees a dangling “as I said above” with nothing above. The cost is amnesia about early instructions — which is why the system prompt is never dropped.
2. Sliding window (last N messages)
Keep filling from the newest message backwards. It squeezes in slightly more recent text than turn-based dropping, but it can start mid-exchange, leaving an assistant answer whose question was cut. Many frameworks ship this by default; check yours.
3. Head + tail
Pin the first exchange (often the real task definition) plus as much recent history as fits, and sacrifice the middle. This suits long tasks where “what are we doing?” was settled in turn 1 and the middle was exploration.
4. Summarize, then continue
Replace the dropped history with a short summary message — here modeled at 5–30% of the original size plus a small fixed cost. You pay one extra model call per compaction, but names, decisions and constraints survive in compressed form. This is what serious long-running agents do; the headless agents guide covers the surrounding automation.
5. Cap each message
Truncate every message to a token ceiling. Useless for ordinary chat, essential when a single pasted log file, web page or tool result is 90% of your prompt. Cap tool results first — they are usually the fattest and least precious tokens you own.
Whichever you choose, always reserve reply space and re-check fit after trimming: a strategy that lands at 99% of the window leaves the model one token to answer with.
Questions
What is a context window?
A context window is the maximum number of tokens a language model can consider in one request: system prompt, conversation history, tool results and its own reply all share the same budget. An 8K window holds 8,192 tokens; a 200K window holds 200,000. Anything that does not fit must be truncated, summarized or left out, because the model cannot see it.
How many words fit in 8K, 32K, 128K and 200K tokens?
For English prose, one token is roughly 0.75 words (about 4 characters). So 8,192 tokens is about 6,100 words or 12 pages, 32,768 is about 24,500 words, 131,072 is about 98,000 words — a short novel — and 200,000 is about 150,000 words. Code, JSON and non-English text usually cost more tokens per word.
Why does a long chat cost more on every turn?
Chat APIs are stateless: every request resends the whole history. Turn 30 therefore re-pays for turns 1 to 29, so total input cost grows roughly with the square of the conversation length. The cost panel sums each request’s cumulative size to show the real bill, and a prompt-cache discount slider models cached-prefix pricing.
What happens when a conversation exceeds the context window?
The API rejects the request with an error unless your code trims it first. In practice you must also reserve space for the reply: a 32K window with a 2,000-token reply reserve leaves about 30K for the prompt. This tool subtracts your reserve from every window before judging fit.
Which truncation strategy should I use?
Dropping the oldest whole turns is the safest default because it never orphans an assistant reply from its question. Summarization keeps the gist of early turns at a small token cost and suits long support or research chats. Head plus tail fits tasks where the first instruction must survive. Per-message caps help when one pasted document or tool result is the problem. Compare all five on your own conversation in the truncation lab above.
How accurate is the token counter?
It is a browser-side estimate modeled on BPE tokenizers such as OpenAI’s cl100k: words, numbers and punctuation are segmented and scored, then 4 tokens of chat-format overhead are added per message. Expect it to land within roughly 10 to 15 percent of a model’s true count for English and code. For billing-exact numbers, run the model vendor’s own tokenizer.
Tools that pair with this one
Same desk, different job. All free, all in the browser.