// 20 / PROMPT OPS · 28 Oct 2026
// the idea
A request to a language model is not one block of text. In anything real it is four or five: a system prompt that sets the rules, some documents you looked up for this particular question, the conversation so far, and the new message. They are assembled by code, sent together, and billed together — and most teams only ever see the total on the invoice.
Two things hide in that assembly. The first is cost: the documents you retrieve are usually the biggest piece by far, and they are re-sent on every turn whether or not they changed. The second is truncation: every model has a hard ceiling on how much it can read at once, and when a long chat crosses it, something is silently thrown away. If you didn't choose what, the framework chose for you.
Token Window puts both on one screen. Paste the pieces, pick a model, and the window fills up in front of you, colour-coded by piece, with the cost per call and the cost at a busy day's volume. Then drag the window smaller and watch which piece gets cut first.
A token is the unit a model reads in — about three-quarters of an English word. "The meeting ran long" is roughly five tokens. The context window is how many a model can take in one request: 8,000 is a few pages, 200,000 is a long novel.
Say you've built a support bot. Each request is a 600-token system prompt, around 3,000 tokens of help-centre articles retrieved for the question, the last ten turns of conversation (2,500 tokens), and the customer's new message (80 tokens). Call it 6,200 tokens in, every time.
system prompt ██ 600 10%
retrieved articles ██████████ 3,000 48%
chat history ████████ 2,500 40%
new message ▏ 80 1%
─────────────────────────────────────────
input per call 6,180 $0.0185
at 50,000 calls / day $927 / day
Nearly half of every call is the retrieved articles. Trim them from four to two and the daily bill drops by a quarter. That's the cost side. Now move the same bot to a local 8K model to save the money entirely: it fits — until turn twenty of a long chat, when it doesn't. Set the chat history to be cut first and the bot "forgets" the customer's order number halfway through. Set the articles to be cut first and it answers from memory instead of policy. Neither is right by accident; you have to decide. The tool makes you decide.
Try it — no key needed
Hit Load example for the support bot above, then drag the try window slider down to 8K and watch the chat history disappear.
// what it does
One box per piece — system prompt, retrieved context, chat history, user message, or anything else you add. Each gets a live token estimate and a cut order: 1 is sacrificed first when space runs out, higher numbers survive longest. That number is the whole point of the tool; it forces the question most pipelines never ask.
Presets for the common shapes — a 200K hosted model, a 128K one, a 1M long-context model, a 32K cheap one, local 8K and 4K — with window size and input/output prices all editable, because vendor pricing changes more often than any page can track. A reserve for reply field holds back the room the model's own answer needs; it comes out of the same window and people forget it.
A single bar, scaled to the model's window, with each piece drawn in its colour and the reply reserve hatched at the right-hand end. Five numbers underneath: input tokens, percentage of window used, cost per call, the biggest piece, and how much is cut at this window. The bar animates as you type, which is what makes the idea stick.
A logarithmic slider from 512 tokens to a million. Drag it and the verdict panel lists each piece as kept, trimmed or dropped entirely, in your cut order, with a plain sentence about what that would mean. Beside it, the cost table runs the current model out to 1,000 calls, a busy day and a busy month, and breaks the per-call cost down by piece so you can see which one to attack.
// how it was built
Real tokenizers are model-specific vocabularies of tens of thousands of entries; shipping one in a single-file page would mean a multi-megabyte download for a tool that needs to feel instant. Instead the estimate is a small heuristic that knows the things that matter: short English words are one token, longer ones split roughly every four characters, numbers split every three, every punctuation mark and symbol costs one, and runs of indentation in code cost too. Against real tokenizers it lands within about ten per cent on prose, which is more than enough for a budgeting decision, and the page labels it as an estimate everywhere it appears.
// words ≤4 chars are one token; longer split ~every 4.2 chars
if (/^[A-Za-z]/.test(p)) t += p.length <= 4 ? 1 : Math.ceil(p.length / 4.2);
else if (/^\d+$/.test(p)) t += Math.ceil(p.length / 3); // numbers are expensive
else t += 1; // every symbol costs one
Sort the pieces by cut order, walk them, and remove tokens from each until the total fits under window − reserve. A piece can be trimmed partially, which is how a real "drop the oldest turns" policy behaves. It's eight lines, and it's deliberately simple: the tool isn't trying to reproduce any particular framework's eviction policy, it's trying to show that there is one, and that you should pick it.
Hard-coding a vendor's price list into a static page is a promise to be wrong within a quarter. The presets carry round numbers that are in the right neighbourhood and every field is editable; the note under them tells you to type in your provider's current figures. The interesting output isn't the dollar amount anyway — it's the ratio between pieces and the multiplication out to real volume.
// what this demonstrates
Context windows have grown so large that it's tempting to stop thinking about them. But bigger windows made two problems worse, not better: it is now easy to spend a fortune sending the same documents on every turn, and when teams move a feature to a smaller, cheaper or local model to save that money, they discover the truncation question they never answered.
Token Window is the second piece of a small prompt-operations toolkit on this site. Promptwatch asks whether a change to a prompt broke anything. This one asks what the prompt costs and what gets sacrificed when space runs out. Both come from the same conviction: the interesting work in AI right now is not writing the prompt, it's running it.
An optional lazy-loaded BPE vocabulary for the most common model families, so the estimate becomes exact when you want it to.
Simulate a conversation growing one exchange at a time and plot the turn at which each window size starts cutting.
Most vendors now discount repeated prefixes; model which pieces are stable enough to cache and show the saving.
Load a Promptwatch suite and see both prompts' footprints side by side — did the candidate quietly double the bill?
The tool is the source — view the page and it's all there, MIT. tokenwindow.html