The context window holds input tokens AND output tokens together. Every token the model reads and every token it writes spends the same budget.
A long answer leaves less room for input on the next turn. Budgeting must reserve space for the reply, not just the prompt.
Five contributors spend the budget on a typical assisted task. All five are input except the generated reply.
Contributor | Example | Counts as |
|---|---|---|
System prompt | Role and rules set by the tool | Input tokens. |
Conversation history | Earlier turns kept for context | Input tokens. |
Pasted material | RTL, logs, specs, tool output | Input tokens. |
Tool and retrieval results | Files an agent reads back | Input tokens. |
Generated reply | The answer being written | Output tokens. |
Token counts are tokenizer-dependent, so estimation uses approximate EXAMPLE rates. A common rough rule is about 3 to 4 characters per token for English prose with common tokenizers, and fewer for code, numbers, hex and non-Latin text.
The calc block plans an EXAMPLE session with 4 chars per token for prose and 3 for code. Real counts vary by model and tokenizer: measure them on the tool in use.
EXAMPLE rates (stated parameters; real tokenizers vary):
prose 4 chars per token, code 3 chars per token
system prompt: 400 chars prose -> 400 / 4 = 100 tokens
recent chat: 3000 chars prose -> 3000 / 4 = 750 tokens
spec extract: 2400 chars code -> 2400 / 3 = 800 tokens
answer reserve: 2000 chars prose -> 2000 / 4 = 500 tokens
planned total = 100 + 750 + 800 + 500 = 2150 tokensAbout 800 tokens. 2400 divided by 3 is 800, approximate because the rate is an EXAMPLE parameter.
From new input or from generated output. Both draw on the same remaining budget.