A model does not receive text as words. A tokenizer converts text into integer token identifiers drawn from a fixed vocabulary. The model processes those identifiers and later converts generated identifiers back into text.
One token may represent a whole short word, part of a longer word, punctuation, whitespace, or a byte sequence. Token counts therefore vary by language, formatting, and tokenizer.
- Input text
The example text is "unbelievable agents!". Characters and words are not the unit the model receives.
- Tokenizer
An illustrative split is [un] [believ] [able] [ agents] [!], with IDs 41, 9021, 73, 1884, and 9. Real splits vary by tokenizer.
- Context allocation
Instructions, goal, history, retrieved evidence, and tool results share the request budget.
- Output reserve
Leave capacity for generated output under the model’s actual context and output limits. The tray is schematic, not a token-capacity scale.
Token counts depend on the tokenizer. Word counts cannot establish context limits.
How to read this model
A slotted input tray and a segmented budget holder. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Subword tokenization balances vocabulary and sequence length
A word-level vocabulary cannot represent every name, spelling, and code identifier without becoming enormous. A character-level vocabulary handles any text but produces long sequences. Subword tokenizers use common pieces as single tokens and split uncommon text into smaller pieces.
For example, a tokenizer might represent authorization as one token, several subword tokens, or a different split when capitalization or leading whitespace changes. Never estimate production limits from word count alone. Use the tokenizer or token-usage fields for the selected model.
The context window is a request limit
The context window limits how many tokens the model can consider for one request. Provider accounting rules determine which inputs and outputs count toward that limit. Inputs commonly include system instructions, conversation history, tool definitions, retrieved text, images represented through model-specific encodings, and tool results.
When a request exceeds the limit, an API may reject it or an application may remove content before sending it. Silent truncation is dangerous because it can remove the instruction, fact, or prior decision that made the task safe.
An application needs an explicit context policy:
- Reserve space for the expected output.
- Keep governing instructions and current user intent.
- Keep state required for the next decision.
- Select relevant evidence.
- Compress or remove older conversational detail.
- Record durable facts outside the prompt.
More context is not always better
Every extra token consumes cost and attention capacity. Irrelevant text can distract the model or introduce conflicting instructions. Relevant information buried in a long prompt may receive less effective use than information placed near the current task.
Context engineering is therefore a selection problem. The goal is not to fill the window. The goal is to supply the smallest context that preserves the required evidence, policy, and state.
Summaries are lossy
A summary reduces token use by choosing what to retain. That choice can remove exceptions, uncertainty, identifiers, or unresolved disagreement. Store authoritative facts in structured state and use summaries for conversational continuity.
For an order-support agent, the database remains the source of truth for payment status. A summary such as “payment completed” must not override a later database result of REVERSED.
Context is not memory
Context exists for one model request. Memory is information the application stores and may retrieve into a later request. A long conversation can look like memory, but it lasts only while the application continues to supply those messages.
This separation lets the application apply retention, authorization, correction, and deletion rules before old information returns to the model.