Context Window Visualizer

A model’s context window is one fixed budget of tokens, and everything in a request competes for it at once. The system prompt, every tool definition, the whole chat history, the retrieved documents, the user’s message and the space for the answer all have to fit together. This visualizer adds them up, draws each as a band in the window, and proposes what to cut when they do not fit.

What it computes

input     = system + tools + history + retrieved + user
committed = input + output reserve
over      = max(0, committed − window)
free      = max(0, window − committed)
status    = Overflow if over > 0
            Tight    if committed / window > 0.85
            OK       otherwise

• Window is one of five presets: 8K (8,192 tokens), 32K (32,768), 128K (128,000), 200K (200,000) and 1M (1,000,000).
• Output reserve is room held back for the reply. It counts against the window even though you do not send it.
• The input tokens card shows input as a share of the window, capped at 100%.
• On overflow, the compaction plan takes the overage from chat history first, up to all of it, then from retrieved context, and warns if both together are not enough.

Token counts are shown as thousands with one decimal, such as 11.2k, and whole thousands at 100,000 and above.

A worked example

The defaults describe a modest agent turn in an 8K window:

1. Input alone is 11,200 / 8,192 = 137% of the window, so the card shows 100%.
2. Committed exceeds the window by 13,200 − 8,192 = 5,008 tokens, so the bar turns red and reads Over budget by 5.0k tokens.
3. The plan takes all 5,008 from chat history, which has 6,000, so it reads Summarize 5.0k tokens of chat history and retrieved context is untouched.
4. Switch to the 32K preset instead: the same request uses 13,200 / 32,768 = 40%, leaves 19.6k free, and the status is OK.

Note who the tenants are: the user’s actual question is 200 tokens, under 2% of the input, while re-sent history is more than half.

Assumptions and limits

• You supply the counts. The tool does not tokenize text. Different models split the same text into different numbers of tokens, so measure with the target model’s tokenizer.
• Compaction is idealized. The plan treats summarized history as removed entirely. A real summary still costs tokens, so recover somewhat more than the overage.
• Fitting is not the same as using well. Models often attend less reliably to material buried in the middle of a long context, so a prompt that fits can still underperform.
• One request. History grows every turn; the tool shows a single snapshot, not when you will hit the limit.
• No price. Bigger windows cost more per call because every input token is billed. Pair this with a cost calculator before choosing a window.

How to use the result

• Keep committed below 85%. Tight is a warning that one long tool result or retrieved document will tip the turn into overflow.
• Attack the biggest band first. Summarize history on a schedule rather than at the brink, retrieve fewer and better chunks, and load tool definitions only when the task needs them.
• Size the reserve to the task. Too small truncates answers; too large wastes window the input could use.
• Move up a window only after trimming. A larger window raises the cost of every call and hides growth that will return.