Context Window Checker

▸ Estimate, not a tokenizer

Token counts use the ~4 chars/token heuristic — good to roughly ±15% on prose, worse on code. Window sizes are the advertised limits and they change. Never ship within 10% of a ceiling on these numbers alone.

▸ What's going in

System prompt 0 tok

▸ Instructions, tool schemas, persona. Resent every single turn.

Retrieved context 0 tok

▸ RAG chunks, file dumps, tool results. Usually the biggest slice.

Chat history 0 tok

▸ Every prior turn you replay — user and assistant both.

User turn 0 tok

▸ The actual question. Almost never the thing blowing the budget.

Where the budget goes

Nothing pasted yet.

Reserve for output

tokens held back for the reply

▸ The answer comes out of the same window as the prompt. Reasoning and thinking tokens count here too.

▸ Budget

0

prompt tokens (est.)

Reserved for output: 4,000
Window needed: 4,000
Characters in: 0
Windows that fit: —

Runs in your browser · nothing uploaded

Does it fit?

Context window sizes with tokens used, percentage consumed, headroom left after the output reserve, and a fit status for each model tier
Model tier	Window	Consumed	Left after reserve	Status
Small local / legacy Llama-2 class, small quantized builds	8,192	0%	—	Fits
32K self-hosted / legacy Mistral, older GPT-4, plenty of OSS servers	32,768	0%	—	Fits
GPT-class standard The 128K tier most GPT deployments run on	128,000	0%	—	Fits
Claude Opus / Sonnet The default 200K window	200,000	0%	—	Fits
Claude Haiku Same 200K window, cheaper tokens	200,000	0%	—	Fits
GPT-class extended Long-context tier on newer GPT models	400,000	0%	—	Fits
Claude 1M context Sonnet / Opus long-context variants, tier-gated	1,000,000	0%	—	Fits
Gemini-class 1,048,576 tokens — 2^20, Pro and Flash	1,048,576	0%	—	Fits

▸ Pink is the prompt, yellow is the reserved reply. Tight fires at 75% of the window or when less than 10% is left over. Window sizes checked August 2026 — confirm against the model card before you architect around one.

A context window is not memory

This is the confusion that costs the most money. The context window is the working set for one request: system prompt, tools, retrieved chunks, the transcript you chose to replay, and the new question — all of it uploaded and paid for again on every single call. The model holds none of it afterwards. Return the response, and the state is gone.

Memory is the part that survives: a row in Postgres, a vector store, a summary file, a user profile. When a chat product "remembers" your name from last week, something outside the model wrote it down and something outside the model decided to paste it back in. A million-token window does not give you memory. It gives you a bigger sheet of paper to re-copy your notes onto, every turn, at full price.

	Context window	Memory
Lifetime	One request	Until you delete it
Lives in	The request body	Your database or vector store
Cost model	Per token, per call, every call	Storage — effectively free
Grows by	Pasting more in	Writing something down
Fails by	Overflow error or silent truncation	Stale or missing records
Fixed by	Retrieval, summarisation, trimming	Schema and write logic

Input and output share one budget

The window is a total, not an inbox. If a model advertises 200,000 tokens and your prompt eats 197,000, the reply gets 3,000 — and you will find out by reading a sentence that stops mid-word, not by catching an exception. That is why this tool subtracts a reserve before it grades anything. Four thousand covers a couple of pages of prose. Raise it hard if the model writes code, emits long JSON, or has extended thinking switched on, because reasoning tokens are output tokens: budgeted from the same pool and billed at the output rate.

Two limits, not one. Most providers also cap max_tokens well below the context window, so a 1M-token window with a 64K output ceiling cannot write you a novel no matter how much headroom the bar shows. Check both numbers on the model card.

Long context degrades in the middle

Fitting is not the same as working. The lost in the middle effect — measured by Liu et al. in 2023 and still visible in current models — is that recall is strongest for material at the very start and the very end of a long context, and weakest for material buried in the middle. Push a fact to 50-60% depth in a 400K-token prompt and the odds of the model using it correctly drop noticeably compared to the same fact in a 20K-token prompt.

Three things follow. Put the instruction that matters last, right before the question, not at the top of a wall of retrieved text. Rank your retrieved chunks and cut the tail instead of pasting all fifty "just in case" — irrelevant chunks are not free, they actively dilute attention. And when a long-context evaluation looks perfect, check whether it was a needle-in-a-haystack test, which measures literal lookup, not multi-hop reasoning across scattered facts. The second is what your app actually does, and it degrades much earlier.

What a full window costs you

Three separate bills arrive when you decide to stuff the window.

Tokens, every turn. A 120K-token context replayed across a 20-turn conversation is 2.4M input tokens for one session. Prompt caching is the fix that actually works — a stable prefix (system prompt, tool schemas, the document) reads back at a fraction of the input price. It only helps if the prefix is byte-identical, so put anything volatile, like a timestamp or a per-user greeting, after the cached block, never before it.
Latency, before the first token. Prefill attention scales roughly with the square of sequence length, so time-to-first-token climbs faster than the prompt does. Users notice the wait far more than they notice a slightly worse answer.
KV cache memory, if you self-host. The cache grows linearly with context length and it is not small. Llama-3-8B with grouped-query attention is 32 layers × 8 KV heads × 128 dims × 2 (keys and values) × 2 bytes ≈ 128 KB per token. A single 128K-token request is about 16 GB of VRAM — roughly what the fp16 weights themselves occupy, for one user. That is why your throughput collapses when you raise the max context on a shared GPU.

Retrieve instead of stuffing

My rule of thumb: under about 30K tokens and static, paste it and cache it — RAG is not worth the infrastructure. Above that, or if the corpus changes, or if you have more source material than one window can hold, retrieve. Retrieval is not only cheaper, it is usually more accurate, because eight well-ranked chunks beat two hundred pages of noise at getting the model to cite the right paragraph.

The one case that genuinely justifies a huge window is a single indivisible artefact you must reason over end to end — a full contract, a long transcript, a codebase you are refactoring across files. Chunking those destroys the relationships that make the task work. Everything else is usually a retrieval problem wearing a long-context costume, and the tell is simple: if you cannot say which part of the pasted context answered the question, you pasted too much.

Questions people ask.

How accurate is this context window checker?

The token count is an estimate, not a tokenizer. It blends the ~4-characters-per-token rule with a word-based count, which lands within roughly 10-20% for English prose and drifts wider on code, JSON, and non-Latin scripts. The window sizes and the fit arithmetic are exact. Treat a result within 10% of a limit as a coin flip and verify with the provider's own token counting endpoint before you ship it.

Does the model's answer count against the context window?

Yes. Input tokens and output tokens come out of the same budget on almost every API, which is why this tool makes you reserve tokens for the reply. If your prompt uses 197,000 of a 200,000-token window, the model has 3,000 tokens left to answer with — and you will get a truncated response rather than an error. Some models also cap max output well below the window, so check both numbers.

What happens if I exceed the context window?

You get a hard 400-class error from the API, not a graceful degradation. Chat products paper over this by silently dropping the oldest turns or summarising them, which is why an assistant can forget something you said twenty messages ago. If you are building on the raw API, you have to do that trimming yourself, and doing it badly is how a system prompt gets evicted mid-conversation.

How many tokens should I reserve for output?

Start at 4,000 for a normal answer, 8,000-16,000 if the model writes code or long structured JSON, and 32,000 or more if you have extended thinking or reasoning tokens switched on — reasoning tokens are billed and budgeted as output. Reserve the p95 of what you actually see in logs, not the average. The default here is 4,000 because that covers a couple of pages of prose with room to spare.

Is a 1M token context window actually usable?

Usable, yes. Advisable, rarely. Retrieval accuracy sags for facts buried in the middle of a long context — the 'lost in the middle' effect — so a needle at 60% depth in a 900K-token prompt is meaningfully harder to find than the same needle in a 20K-token prompt. On top of that you pay for every token on every turn, time-to-first-token climbs with prefill, and KV cache memory grows linearly. Big windows are a safety net for the occasional oversized input, not a replacement for retrieval.

Is a context window the same as memory?

No. The context window is the working set for one request: everything you resend, every time, priced per call. Memory is state that survives between requests — a database row, a vector store, a summary file. A model with a 1M-token window still remembers nothing once the request returns. If your app needs to recall a preference from last Tuesday, that is a storage problem, and stuffing the transcript back into the window is the expensive way to fake it.

Context Window Checker.