Context Window Calculator

What Is a Context Window?

The context window is the maximum number of tokens a language model can process in a single request — including system prompt, conversation history, MCP tool responses, user input, and model output combined. Understanding context management is critical because modern agentic applications compete for this limited space across multiple dimensions[openai-models].

The available space for your input depends on the model's total window minus the output you expect to generate:

Where $W$ is the model's total context window in tokens. If a model supports 1,000,000 tokens and you expect 10,000 output tokens, your available input space is 990,000 tokens.

The total usage percentage of your context window is:

For agentic applications, the context must accommodate not just your prompt and response, but MCP server responses, intermediate reasoning chains, and accumulated conversation history. A single agent turn might use:

Where $N_{\text{system}}$ is system prompt overhead, $N_{\text{history}}$ is accumulated conversation, $N_{\text{tools}}$ is MCP server responses, and $N_{\text{reasoning}}$ is internal chain-of-thought.

Context Window Comparison

Context windows have expanded from GPT-3.5's 4,096 tokens to 1,000,000+ across all frontier models[deepseek-models]:

How Agent Memory Consumes Context

Agentic applications — those running in Claude Code, OpenCode, OpenClaw, Cursor, or custom MCP clients — consume context differently than straightforward chat completions because they accumulate memory across turns[mcp-spec].

MCP server responses are the largest hidden consumer of context. An agent connected to MCP servers for filesystem access, web search, database queries, and GitHub integration produces tool responses that fill the context window rapidly. A single database query returning 100 rows of customer data might consume 5,000-10,000 input tokens. If the agent makes 10 such queries during a session, that is 50,000-100,000 tokens of tool response data alone — before any actual reasoning or output.

Conversation history accumulation follows a simple but dangerous pattern: each turn adds its input and output to the history for the next turn. After 20 turns averaging 2,000 tokens each, the history alone consumes 40,000 tokens. For long-running agent sessions handling complex tasks, history can easily consume 100,000-200,000 tokens of the context window[anthropic-models].

Reasoning chains — the internal monologue models generate before answering — consume output tokens that are not returned to the user but occupy the context window. Deep reasoning models generate extensive chain-of-thought that stays in context for subsequent turns. A model that generates 4,000 tokens of reasoning per turn across 10 turns has committed 40,000 tokens to reasoning alone.

The practical constraint is that available context shrinks with every turn:

When $W_{\text{remaining}}$ approaches zero, the model must decide what to discard. This process is called context compaction.

Session Compaction Strategies

Each tool manages context compaction differently, affecting which information survives and what gets discarded when the window fills[google-models].

The choice of compaction strategy directly affects whether the model retains critical information from earlier turns. OpenClaw's budget-based compaction preserves messages weighted by recency and relevance, which is effective for tasks where the most recent interactions matter most. Claude Code's diff-based retention is optimized for coding workflows where the structural changes (file edits, git commits) matter more than the reasoning that led to them.

The "Lost in the Middle" Problem

Even within an uncompacted context window, models do not use all positions equally. Research by Liu et al. demonstrated that model performance degrades when relevant information is placed in the middle of the prompt, while information at the beginning and end receives higher attention weights[lost-in-middle].

This finding has practical implications for context management:

• Place critical instructions at the start of your prompt — they receive highest attention.
• Place critical data at the end of your prompt — recent content receives strong recency bias.
• Avoid burying key information in the middle of a long context. If you must include 100 pages of documents, put instructions before and after the document block.
• Re-state important constraints at both the beginning and end of your prompt to address both primacy and recency biases.

For agentic applications, the lost-in-the-middle effect compounds across turns. Information from turn 5 of a 20-turn session is likely to be less accessible than information from turns 1-2 or 18-20. If your agent needs to reference a specific decision from mid-session, you may need to explicitly instruct it to retain that information or log it externally.

Effective Context Management

The key to managing context windows effectively is knowing what competes for space. Every token in your prompt, every MCP response, every reasoning step, and every output token reduces available space. The calculator above helps you visualize this competition.

For short agentic tasks (under 10 turns), any model with a 200K+ context window suffices. Allocate roughly 10% of the window to system prompts and conversation overhead, 60% to task input, and 30% for output and reasoning.

For long-running agentic sessions (20-50 turns), plan for context compaction. Set up your workflow to log intermediate results to external storage and instruct the model to summarize before compaction. Monitor context usage and trigger manual compaction when utilization exceeds 70%.

For context-heavy tasks involving large documents or codebases, reserve 80% of the window for the actual content and 20% for overhead. Models with 1M+ context windows can handle entire codebases or book-length documents, but the cost and latency scale with token count. Use chunking for static analysis and full context only for tasks that genuinely require all information simultaneously.

Tool-Specific Context Considerations

Different development environments impose different context management constraints that affect which models and strategies are viable[mcp-spec].

Claude Code uses diff-based retention that keeps file changes and git history while discarding intermediary reasoning. This is efficient for coding workflows but means that the model may not remember why it made a particular change — only what changed. Context is rarely a bottleneck for individual files but becomes constrained during multi-file refactoring sessions.

OpenCode retains full conversation history without compaction. This provides maximum context for complex multi-step tasks but risks hitting context limits on long sessions. The ~1,800-token system prompt consumes roughly 0.17% of a 1M window but 0.9% of a 200K window — a significant difference for Haiku 4.5 users.

OpenClaw compacts at 70% context budget, weighting messages by recency and relevance. This balances retention against context pressure, making it suitable for long-running agentic sessions.

Cursor Agent uses a sliding window approach that drops the oldest messages when limits are reached. This ensures predictable context usage but may lose information from earlier turns. Cursor's overhead is highest among common tools at ~2,000 tokens of system prompt.

Limitations

• Output limits vary: Gemini 3.6 Flash and DeepSeek V4 limit output to 8,192 tokens within their 1M context windows. GPT-5.6 and Claude Opus 5 support 128,000 output tokens. These constraints affect which tasks are feasible within each model.
• No intermediate compaction modeling: The calculator shows total usage but does not model how compaction strategies change effective capacity over time. Long-running sessions may compact at different thresholds.
• MCP overhead is averaged: Tool response sizes vary. A simple file read adds 50 tokens; a large database query adds 50,000 tokens. Model your specific tool chain for accurate estimates.
• Reasoning overhead excluded: Deep reasoning models generate internal chain-of-thought that consumes context but is not visible or directly measurable. This hidden overhead reduces effective capacity by 20-40% on complex tasks.
• Context window ≠ retention quality: A 1M token window does not mean the model uses all 1M tokens equally. The lost-in-the-middle effect means effective capacity for critical information may be much lower than the advertised maximum.

Frequently Asked Questions

❓ How much context does an MCP tool call consume?

✅ Each tool call adds the tool's response as input tokens. A simple tool like file search returns 50-200 tokens. A database query can return 5,000-50,000 tokens. Vector search results average 2,000-8,000 tokens. Total MCP overhead depends on the number and complexity of tools used per task.

❓ Why do some models have 1M context but only 8K output?

✅ Not all tokens in the context window are available for both input and output. Gemini 3.6 Flash and DeepSeek V4 reserve most of the 1M for input, capping output at 8,192 tokens. GPT-5.6 and Claude Opus 5 allocate 128,000 for output within their full context windows.

❓ What happens to context when I use multiple MCP servers?

✅ Each MCP server's responses accumulate in the context window independently. Using 5 MCP servers that each return 5,000 tokens per call adds 25,000 tokens to input per turn. Over a 10-turn agent session, that is 250,000 tokens — a quarter of a 1M context window.

❓ How does session compaction affect my application?

✅ Compaction discards some conversation history to free up context. Different strategies preserve different types of information. If your application relies on details from early turns, choose a compaction strategy (like OpenClaw's budget-based) that weights recency and relevance, not just recency.

❓ Should I always use the largest available context window?

✅ No. Processing 1M tokens costs approximately 250x more than processing 4K tokens. Use only the context you need. The 1M windows are for tasks like full codebase analysis or book-length document processing. For most tasks, 32K-200K is sufficient.

❓ How does the lost-in-the-middle effect impact agentic workflows?

✅ Information from mid-session turns receives lower attention weight than information at the start or end of the session. If your agent needs to reference a mid-session decision, explicitly log it or re-state it at the end of the prompt before the next turn.

❓ What is the best compaction strategy for long coding sessions?

✅ Claude Code's diff-based retention preserves structural changes (file edits, git commits) while discarding intermediary reasoning. This works well for coding where the change history matters more than the reasoning process.

❓ Can I exceed the context window if I monitor usage per turn?

✅ Yes, if you implement per-turn token counting and trigger compaction or summarization before hitting the limit. The calculator helps you see how close you are to the threshold, but dynamic monitoring requires integration with the model's tokenizer API.