Context Window Calculator: Budget a Task Before You Start
Estimate the space for instructions, documents, conversation, tool results, and the answer. A worked calculation shows how to leave room for the task to finish.
Updated 5 min read
A context window calculator estimates whether your instructions, source material, conversation, tool results, and planned answer fit the selected model’s working space. Use the model’s own token counter when available, then reserve space for output and the information later steps may add.
Tokens are the small text or media units a model processes; they are not the same as words or file bytes. fenbs keeps the durable project record outside a single request, so you can select current rules and relevant progress instead of budgeting for an entire work history.
Which limits should the calculation use?
First identify the exact model and the interface sending the request. A model page, an application’s attachment allowance, and a service’s usage quota can describe different limits. A document that uploads successfully may still be too large to include in full alongside your other material.
Read how that model defines input, output, and total context. Some documentation describes a shared window containing both the prompt and the response; other interfaces expose separate input and output ceilings. Do not subtract an output allowance from an input limit unless the service’s accounting calls for it.
Anthropic’s context window documentation (opens in a new tab) explains its request accounting, including instructions and tool content. Keep changing capacities behind the vendor link. The AI context window guide explains the general concept without tying your budget to a particular model release.
What belongs in the input total?
Count the request you will actually send, not just the document you are looking at. A short question can travel with a long conversation, instructions added by the application, and definitions describing the tools the assistant can use. When an app hides those components, treat your manual count as incomplete.
- Instructions: the task, project rules, output requirements, and application instructions you can inspect.
- History: earlier user messages, assistant answers, and tool exchanges included with this request.
- Sources: selected document text, code, images, or other supported material.
- Tools: tool descriptions and results already present in the conversation.
- Expected additions: the search results, file reads, or other information the remaining steps may introduce.
Count each component once in your own worksheet. If a request counter already includes the conversation and tool descriptions, adding them again makes the estimate misleading. Write down what the count covers so another person can reproduce it.
How do you calculate a budget with a shared window?
For a model whose input and output share one capacity, add the current input, expected growth, intended output, and a working reserve. Subtract that total from the documented capacity. Positive headroom means the estimate fits; it does not guarantee the answer will be accurate.
current_input = instructions + history + sources + current_tool_content planned_total = current_input + expected_growth + output_budget + reserve headroom = documented_shared_capacity - planned_total Also check: current_input <= any separate input limit output_budget <= the model and interface output limits
Use the reserve for uncertainty about content size and application overhead, not as permission to ignore a known limit. If the interface reports a complete token count, use that measurement. If it reports only visible text, leave more room or reduce the task until your estimate is dependable.
For separate input and output limits, check both independently and then apply any additional combined rule the vendor documents. A response cap is a maximum, not a promise that every answer will use that many tokens.
What does a worked calculation look like?
Suppose an imaginary service has a shared capacity of 32,000 tokens. These numbers illustrate arithmetic only; they are not specifications for a real product. You want to review a report, look up supporting passages, and write a short findings document.
| Component | Budget | Reason |
|---|---|---|
| Instructions and project rules | 2,000 | Goal, scope, and required answer format |
| Conversation history | 3,000 | Earlier exchanges still needed for this review |
| Report passages | 9,000 | Relevant source sections |
| Existing tool content | 2,000 | Results already included in the request |
| Expected growth | 6,000 | Additional source reads during the review |
| Answer allowance | 4,000 | Room for the findings document |
| Working reserve | 3,000 | Uncertainty in the estimate |
| Planned total | 29,000 | Leaves 3,000 below the hypothetical capacity |
The initial input is 16,000 tokens. Adding growth, output, and reserve gives 29,000, leaving 3,000 of headroom. If the task needs another 8,000-token appendix, change the plan before sending it: select the relevant appendix section or review it in a separate bounded step.
Do not remove the report’s exception section merely because it is long. First decide which question the review must answer. Select evidence based on that question, then adjust the budget around the material required for a sound answer.
How close can a word-based estimate get?
A word-based estimate is useful for early planning but should not be treated as an exact token count. Code, tables, unusual identifiers, different languages, and media can behave differently from ordinary English prose. Two files with similar page counts can require different amounts of context.
Google’s token counting guide (opens in a new tab) describes counting model input and inspecting usage. Anthropic’s token counting endpoint (opens in a new tab) accepts structured request content for supported inputs. Use the counter for the model and input types you actually plan to send.
After the task, compare the estimate with the service’s reported usage when it is available. Keep the difference with your notes. Repeated underestimates usually point to something missing from the worksheet, such as tool exchanges or history carried between turns.
Budget for the task, keep the project
Keep project decisions, current task plans, and Where we left off in fenbs. Ask a supported connected assistant to read that record and select the facts needed for the current question. Save the result and remaining work afterward, so the next calculation starts from a current checkpoint.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account. One person can start free, with no credit card.
- Add the project and task. State the question to answer, the required sources, and what a complete result should contain.
- Record approved continuing constraints in Decisions and rules, and put concise background in AI context notes.
- Connect a supported app through Integrations. Ask it to read the project context, then count the actual request using the relevant provider or application controls.
- Save task progress and Where we left off after the work, including sources checked and anything still unresolved.
fenbs is not a token counter and does not enlarge another product’s window. If you only need to measure a single prompt, the model’s counting tool is the better fit. Its role here is keeping reusable work outside the input you are calculating.
What if the estimate fits but the answer is weak?
Check relevance, clarity, and conflicting instructions before increasing the allowance. A technically valid request can still contain too many competing facts or ask a question its sources cannot answer. Our AI context rot guide covers that distinction.
For the broader habit of selecting, refreshing, and checking information between tasks, see context window management. You can explore related methods in the context engineering topic hub. A useful calculation supports a clear task; it does not replace one.