Direct answer
Make room for the answer before adding more context
A context window is a shared budget. Instructions, code, history, retrieval, tool schemas, and generated output all compete for capacity. Enter counts from your own tokenizer or usage report to see whether the assembled workload fits—and which bucket offers the clearest reduction.
Build your context budget
Enter token counts from the tokenizer or usage report you trust. The starter values are an editable planning example—not limits for a named model.
Fits in the context window
90.6% used
12,000 tokens remain unassigned.
Total budgeted
116,000
100,000 prompt/context + 16,000 output reserve
Window capacity
128,000
Use the effective limit for your exact model, provider, and request mode.
Unassigned headroom
12,000
Available for uncertainty or additional context.
Visual budget
Where the context window goes
Budget fits
- System4,000
- Repo52,000
- History24,000
- RAG12,000
- Tools8,000
- Output16,000
Illustrative budgets
Use these to explore the controls, then replace every value with your own measurements.
Action plan
Reduction scenarios
Each scenario changes one or two controllable buckets. Savings are based on your current entries and are not model guarantees.
Summarize half the history
Replace older turns and verbose tool output with a checked summary.
−12,000
24,000 free
Focus the repository set
Keep the active files and interfaces; retrieve other code only when needed.
−26,000
38,000 free
Trim retrieval and schemas
Reduce duplicate RAG chunks and expose only tools needed for this step.
−9,200
21,200 free
Exact token counts require the selected model's tokenizer. Numeric inputs and calculations stay in this browser; no prompt or source text is requested.
Transparent method
How context-window budgeting works
Start with the effective context size for the exact model and request mode. Add every known consumer, including the output you want the model to produce. A positive difference is headroom; a negative difference is overflow. Because wrappers and automatic retrieval may be invisible, leave a safety margin instead of planning to exactly 100%.
Inventory
Measure each component after your application has assembled it. A short user message does not prove the full request is short.
Reserve
Hold back space for the response and for uncertain overhead. If quality depends on a 10K-token patch, budget that before loading more files.
Prioritize
Keep instructions and decisive evidence; summarize old turns, deduplicate retrieval, and fetch peripheral files only when the task reaches them.
Worked example
A 128K planning worksheet with 12K headroom
These are illustrative inputs, not the documented limit or usage pattern of a named model.
| Bucket | Tokens | Decision |
|---|---|---|
| System + tool schemas | 12,000 | Keep required rules; expose only relevant tools. |
| Repository + RAG | 64,000 | Prefer active files and non-duplicate evidence. |
| Conversation history | 24,000 | Summarize resolved exploration, preserve decisions. |
| Output reserve | 16,000 | Protect enough room for the requested implementation. |
| Budgeted / capacity | 116,000 / 128,000 | 12,000 tokens remain for overhead and uncertainty. |
What to reduce first
Usually safer to compress
- Duplicate retrieval chunks and repeated file contents
- Resolved chat turns and verbose successful tool output
- Unrelated schemas and peripheral repository files
Protect or verify before cutting
- Safety rules, acceptance criteria, and user constraints
- Interfaces and call sites that establish correctness
- The output reserve required by the requested deliverable
Sources
- Anthropic context-window documentation
Official overview of context-window behavior; exact limits depend on the selected model and provider.
Frequently asked questions
What counts toward an AI context window?
The exact request format is provider-specific, but the budget commonly includes instructions, message history, source or retrieved content, tool definitions and results, plus generated output. Some interfaces hide part of that assembly, which is why this calculator keeps each planning bucket visible.
Should the output reserve be inside the context limit?
Budget it inside the limit unless your provider explicitly documents a different accounting rule. Reserving output early prevents an input that technically fits from leaving too little space for the answer you need.
Why can a request fail when my visible prompt looks short?
The visible prompt may be only one part of the assembled request. System instructions, prior messages, tool schemas, retrieved chunks, attachments, and wrapper formatting can all consume context before generation begins.
Does a larger context window always improve the answer?
No. More capacity can prevent truncation, but irrelevant or duplicated context may make the useful evidence harder to find and can add latency or cost. A focused context set is often easier to inspect, cache, and reproduce.
Is this an exact tokenizer?
No. It adds numeric token counts that you supply. For a hard limit, count the fully assembled request with the tokenizer and message-format rules for the exact model and provider you will call.