Context-window planner

"1M tokens" is not 1M usable tokens

Current-generation models advertise a large context window, and it's tempting to treat that number as the budget for what you can send. It isn't. Every request also needs room for the model's response, and on models where thinking is on by default or always on, thinking itself consumes tokens out of the same pool before the visible answer even starts. A request that looks like it comfortably fits the window on paper can still fail once thinking and output are actually accounted for, especially at higher effort levels where thinking runs longest.

What this tool estimates

Paste or describe your codebase or document set and this tool estimates how much of the window it occupies, what's realistically left over once a plausible response and — where relevant — thinking overhead are subtracted, and roughly where you cross from "comfortably fits" into "fits, but barely." That last zone matters more than it looks: a request that technically fits but leaves almost nothing for the response tends to produce answers that get cut off mid-thought rather than a clean error telling you what happened.

Where compaction starts earning its keep

Once you're feeding in something that grows over a long working session — an extended conversation, an agentic coding run that keeps accumulating file contents and tool output — the question stops being "does this fit" and becomes "when does trimming what's no longer needed start paying for itself." Compaction and context editing both cost something to run, so applying them too early wastes effort for no benefit, and applying them too late means you've already paid for tokens you didn't need in context. This tool flags roughly where that crossover sits for your described workload, rather than leaving it as a guess.

Codebases versus documents

A codebase and a long document consume a context window differently even at a similar total size, because code tends to tokenize less efficiently than prose does for a given character count, and a codebase often needs file boundaries and paths preserved as structure rather than compressed away. If you're planning a request that mixes both — reference documentation alongside the code it describes — size them separately rather than assuming one estimate covers both, since the ratio between them isn't fixed.

Before you commit to a plan

An estimate is only as good as the model it's estimated against, since window size and how efficiently your specific text tokenizes both vary by model. Once you've got a rough shape from this tool, run your actual text through the token & cost estimator for the exact count against the model you intend to call, rather than treating the estimate here as the final number.