Context Window Calculator
See where a model's context window actually goes — prompt, tools, history, attachments and the reply's own space — and exactly what to cut when it overflows.
Context budget
GPT-4o · 128,000 tokensLoading the o200k_base vocabulary — 965.7 KB, once per browser.
2,015/ 128,000 tokens
1.6% used
- Input
- 15
- Remaining
- 125,985
- More turns that fit
- 503
- Room for history
- 125,985
System prompt
0 tokens · 283 BTool definitions
0 tokens · 418 BConversation history
0 tokens · 278 BAttachments / retrieved docs
0 tokens · 409 BUser message
0 tokens · 68 BCounted in your browser with a real BPE tokenizer — nothing is uploaded. For the cost of a workload this size, use the LLM Cost Calculator; for one prompt counted exactly, the Prompt Token Counter.
About the Context Window Calculator
This context window calculator shows where a model's context actually goes. Paste your system prompt, tool definitions, conversation history, retrieved documents and the user's message into separate boxes, and each one is tokenized with a real BPE tokenizer and drawn as its share of the window.
The part most estimates get wrong is that the window is shared with the reply. A 128K context window holding 120K of input has not got room for a 16K answer — it has 8K, and asking for more gets you a truncated response or a hard rejection. So the space reserved for the reply is part of the budget here, drawn in the same bar, and the tool tells you when the input fits on its own but not alongside the reply you are expecting.
Once it does not fit, generic advice is useless: shortening your prompt does nothing when retrieved documents are 90% of the input. The suggestions here are computed from your own numbers — which segment is largest, what reservation would actually fit, and the fix specific to that segment, since a long system prompt and a long conversation history are solved in completely different ways.
Everything runs in your browser. The tokenizer vocabulary downloads once and is cached; after that, no prompt you paste leaves the machine.
- Five separate segments — system prompt, tool definitions, history, attachments and user message — counted independently
- Exact BPE token counts for models with a public tokenizer; a labelled estimate for the rest, never presented as exact
- Space reserved for the reply counted against the window, not treated as free
- Per-message chat framing included as a visible, toggleable number rather than folded silently into the total
- How many more conversation turns fit, at your average turn size
- The largest history you could keep while still leaving room for the reply
- Overflow advice specific to whichever segment is actually dominating
- The model's per-response output cap checked separately from its context window
How to use it
- Pick your model. The context window and output cap come from the provider's published specification.
- Paste each part of your request into its own box. Splitting them is the point — a single total tells you nothing about what to cut.
- Set the reply reservation to the longest response you actually need. Measure it rather than guessing; most applications reserve far more than they use.
- Read the bar. Each colour is a segment, grey is the reservation, and the empty space is your headroom.
- If it overflows, work down the suggestions. They are ordered by how much room each change frees.
Real-world use cases
AI application developers
Size a RAG or agent request before sending it, seeing exactly which segment — system prompt, tools, retrieved documents, history — is eating the window rather than guessing from a rejected request.
Backend & platform engineers
Debug a context-length error by checking whether it is the input or the reserved reply space that is actually the problem, since a provider's error message adds the two together.
AI product engineers
Decide how many turns of conversation history a chat feature can safely keep before truncating, using the tool's turn-count estimate instead of an arbitrary cutoff.
Agent & tool-use developers
Check how much of the window a growing tool schema is consuming on every single call, before it silently crowds out the actual conversation.
AI engineering leads
Evaluate whether upgrading to a model with a larger context window actually solves a capacity problem, or whether the real fix is sending less input in the first place.
Examples
A typical support-assistant request
System prompt: 55 tokens Tool definitions: 120 tokens History: 85 tokens Attachments: 80 tokens User message: 15 tokens Reserved reply: 2,000 tokens
Input: 366 tokens Total used: 2,366 / 128,000 (1.8%) Remaining: 125,634 More turns that fit: 502
Comfortable — but note that tool definitions are the largest input segment, and they are resent on every single request.
Input fits, the reply does not
Input: 120,000 tokens Reserved reply: 16,000 tokens Window: 128,000 tokens
Over the 128,000-token window by 8,000. The input fits on its own, but not alongside 16,000 tokens reserved for the reply. Reducing the reservation to 8,000 tokens would fit.
This is the failure the tool exists for. Every check that looks only at input tokens says this request is fine.
The input alone is too big
Attachments: 300,000 tokens Window: 128,000 tokens
Over the 128,000-token window by 174,000. The input alone does not fit, so no reservation change will help. Something has to be cut or split across requests. Attachments / retrieved docs is the largest segment at 300,000 tokens — 98% of your input. Retrieve fewer, smaller chunks.
The advice names the segment and the fix rather than telling you to shorten your prompt.
Reserving more than the model will generate
Reserved reply: 30,000 tokens on a model capped at 16,384
Reserving 30,000 tokens for the response, but this model generates at most 16,384 in one reply. Reserving more than 16,384 cannot help — the response is capped before the context window is.
The context window and the maximum output are two different limits, and reserving against the wrong one wastes input space for nothing.
Common errors
| Message | Cause | Fix |
|---|---|---|
| This model's maximum context length is 128000 tokens, however you requested ... | Input plus requested max_tokens exceeds the window. The error adds the two together, which is why it can fire when your input clearly fits. | Lower max_tokens, or cut input. This tool shows the sum before you send it, and tells you which of the two is the problem. |
| The response stops mid-sentence | The reply hit its token limit rather than finishing — either max_tokens was too low or the remaining window was. | Check finish_reason: length means truncation, stop means the model finished. Raise the reservation if there is room, and shorten the input if there is not. |
| The conversation works for a while and then starts failing | History grows with every turn while everything else stays constant, so the request creeps up on the limit. | Cap history by tokens rather than by turns — turns vary hugely in size. The "more turns that fit" figure here is exactly this countdown. |
| The count here does not match what the provider billed | Either the model's tokenizer is not public and the count is a labelled estimate, or the framing overhead differs from the four-tokens-per-message convention used here. | Compare against the usage figures in an API response for a real request. The framing toggle lets you see how much of the difference it accounts for. |
| Tool definitions seem to cost more than expected | The whole tool schema is serialised into the request on every call, including descriptions and every parameter. | Send only the tools reachable in the current step. Trimming descriptions helps too, though it usually costs accuracy in tool selection. |
| Retrieved documents dominate the window | Retrieval returning too many chunks, or chunks that are too large. | Rank and truncate. Fewer, better chunks are almost always both cheaper and more accurate than sending everything and hoping the model finds the relevant part. |
Frequently asked questions
›Is my prompt uploaded anywhere?
No. Tokenizing happens in your browser using a vocabulary file the page downloads once and caches. After that first download the page works offline, and no prompt you paste is ever transmitted — which is the point, since a real system prompt is often the most sensitive part of an application.
›Why does the reply take up space in the context window?
Because the window is the total the model can hold at once, not a limit on what you send. Input and generated output share it. This is why an API call can be rejected with a context-length error when your input is well under the limit: the provider adds your requested max_tokens to the input before checking. Any tool that counts only input tokens will tell you that request is fine.
›How is this different from the Prompt Token Counter?
The counter answers "how many tokens is this text, and what does it cost" for one blob of text. This one answers "will my whole request fit, and what do I cut if it does not" — which needs the parts kept separate, the reply's space accounted for, and advice about the segment that is actually dominating. They share the same tokenizer, so the numbers agree.
›What is the chat framing overhead?
Chat endpoints wrap each message in role and delimiter tokens, so the billed input is always slightly more than the sum of your text. The exact framing is not documented and differs between providers, so it is offered here as a visible toggle using the widely-cited four tokens per message plus three per request. It is never folded silently into the headline number, because that would turn an exact count into a guess without saying so.
›Which models can be counted exactly?
Those whose tokenizer is public — the OpenAI models using cl100k_base or o200k_base. Anthropic does not publish a tokenizer, so Claude counts come from a calibrated ratio against a known encoding and are labelled estimated wherever they appear. An estimate is never rendered as an exact figure; if the model you pick cannot be counted exactly, the page says so.
›How do I decide the reply reservation?
From measurement, not intuition. Log the completion token counts from a few hundred real responses and take a high percentile — the 95th is usually a good reservation. Most applications reserve the model's maximum by default, which quietly costs them a large slice of usable input space for a reply length they never actually produce.
›Does a bigger context window solve this?
It moves the wall, and it is not free. Cost scales with tokens sent, so filling a million-token window on every request is expensive, and models generally attend less reliably to material buried in the middle of a very long context than to the same material in a short one. Fitting more in is usually the wrong goal; sending less of it is the better one.
›Is my prompt data sent anywhere when I use this tool?
No — worth restating clearly, since the tool is designed for exactly the kind of sensitive input (system prompts, retrieved internal documents) people are most cautious about. Tokenizing runs locally after the vocabulary file downloads once; nothing you type in any of the five segment boxes is transmitted.
Last updated