A four-state context-window budget bar: the assembled prompt packed part by part, the reply's reserve subtracted from the window instead of stacked on top of it, the overflow framed against the budget that actually applies, and the tokens the eviction order takes first cut out of the part that owns them.
Preview in your theme
Loading preview…
This component is part of Pro
The install command, prompt and concept map are included with a Pro license — one purchase unlocks every Pro component, forever.
status="ready" · turn fifteen of a retrieval-augmented coding agent. 196,140 tokens against a 200,000-token window reads as a fit — until you subtract the 16,000 held back for the reply, which leaves 184,000 and puts the prompt 12,140 over. The dashed frame is that overflow; the hatched cut inside Retrieved chunks is where the eviction order takes it from, and the thin bar underneath is the same prompt once the plan has run. Press a chip to leave that part out and watch the verdict move.
Context window
Meridian 3.5 Ultra · 200,000-token window · counts from mx-bpe-200k
196,140 of 184,000 available · 12,140 over
12,140 over
more than the prompt budget allows
196,140 assembled against 184,000 available
200,000 window less 16,000 held back for the reply
98%
of the window is prompt
the reply's reserve of 16,000 has 12,140 of prompt sitting in it
nothing is unclaimed — the prompt is inside the reply's reserve
Lower bar: the same prompt after the eviction plan — 184,000 tokens, exactly the budget, with the reply's reserve intact.
reply reserve 16,000, the prompt is sitting in itprompt 98% of the window
Over by 12,140. The order takes 12,140 out of Retrieved chunks (96,300 → 84,160). The eviction order is Retrieved chunks (1), Conversation history (2) and Tool definitions (3). System prompt and Current turn are pinned and never enter the order, holding 4,150 tokens.
Reserved output is space, not content: it comes out of the window before a single part is packed, so the prompt competes for 184,000 tokens rather than 200,000, and it can never itself be evicted. Counts are whatever your tokenizer reported (mx-bpe-200k) — this card never tokenises.
Context window for Meridian 3.5 Ultra as currently assembled: 5 of 5 parts included, 196,140 tokens against 184,000 available (200,000 window less 16,000 reserved for the reply), 12,140 over.
Part
Tokens
Share of the assembled prompt
Eviction order
Trimmed by the plan
Kept
System prompt
1,840
1%
pinned
0
1,840
Tool definitions
7,450
4%
3
0
7,450
Retrieved chunks
96,300
49%
1
12,140
84,160
Conversation history
88,240
45%
2
0
88,240
Current turn
2,310
1%
pinned
0
2,310
Assembled prompt
196,140
100%
—
12,140
184,000
Reserved for the reply
16,000
—
never evicted
0
16,000
Context window
200,000
—
—
—
12,140 over
status="ready", the same window eight turns earlier · it fits, with 113,310 tokens unclaimed, so the card states the eviction policy without firing it: nothing is evicted, but Retrieved chunks would still be the first to go. Shares are apportioned by largest remainder, so the five parts read exactly 100% here and in every filter state after it.
Context window
Meridian 3.5 Ultra · 200,000-token window · counts from mx-bpe-200k
70,690 of 184,000 available · 113,310 free
113,310 free
left in the prompt budget
70,690 assembled against 184,000 available
200,000 window less 16,000 held back for the reply
35%
of the window is prompt
the reply's reserve is a further 8%
57% of the window is still unclaimed
reply reserve 16,000 · 8% of the windowfree 113,310 · 57%
Nothing is evicted: 113,310 tokens of headroom are still unclaimed. If it ran over, Retrieved chunks would go first. The eviction order is Retrieved chunks (1), Conversation history (2) and Tool definitions (3). System prompt and Current turn are pinned and never enter the order, holding 3,100 tokens.
Reserved output is space, not content: it comes out of the window before a single part is packed, so the prompt competes for 184,000 tokens rather than 200,000, and it can never itself be evicted. Counts are whatever your tokenizer reported (mx-bpe-200k) — this card never tokenises.
Context window for Meridian 3.5 Ultra as currently assembled: 5 of 5 parts included, 70,690 tokens against 184,000 available (200,000 window less 16,000 reserved for the reply), 113,310 free.
Part
Tokens
Share of the assembled prompt
Eviction order
Trimmed by the plan
Kept
System prompt
1,840
3%
pinned
0
1,840
Tool definitions
7,450
10%
3
0
7,450
Retrieved chunks
41,200
58%
1
0
41,200
Conversation history
18,940
27%
2
0
18,940
Current turn
1,260
2%
pinned
0
1,260
Assembled prompt
70,690
100%
—
0
70,690
Reserved for the reply
16,000
—
never evicted
0
16,000
Context window
200,000
—
—
—
113,310 free
status="empty" · a valid contract carrying the window and the reply reserve but nothing assembled yet, worded so it cannot be mistaken for a failed fetch — a limit is configuration, known long before the first chunk is retrieved.
Context window
Meridian 3.5 Ultra · 200,000-token window · counts from mx-bpe-200k
What the assembled prompt is made of, against the room the model actually leaves for it
Nothing assembled into this window yet
The window and the reply's reserve are configuration, known before the first chunk is retrieved: 200,000 tokens with 16,000 held back leaves 184,000 for the prompt.
status="loading" · a skeleton holding the two stat tiles, the budget bar and the part chips, aria-hidden, honouring prefers-reduced-motion, with no timer involved.
Context window
Meridian 3.5 Ultra · 200,000-token window · counts from mx-bpe-200k
What the assembled prompt is made of, against the room the model actually leaves for it
Loading context window
status="error" · the assembler never reported back. Try again only appears when onRetry is passed, and clicking it flips the card to ready.
Context window
Meridian 3.5 Ultra · 200,000-token window · counts from mx-bpe-200k
What the assembled prompt is made of, against the room the model actually leaves for it
Zyeon UI