Understand context windows and tokens
6 min read
Updated
Understand context windows and tokens
Diagnose missing details in a long conversation and prepare a verifiable restart.
Direct answer
The context window is the working capacity available for a response. It is measured in tokens, not messages. An old exchange visible on screen is not necessarily present in full in what the model receives. Check decisions and their references when restarting; a useful summary can preserve the main points while losing a decisive detail.
Glossary
Terms explained here
Open a term for a short definition, then continue to its full sourced entry if useful.
01
Context, tokens and memory are different
A token is a unit used to represent content processed by the model; in text it may be a word or a fragment. Segmentation depends on the model and language. There is no universally reliable conversion between pages, words and tokens.
Context may include instructions, messages, document excerpts and tool results; the response also uses a budget. Persistent memory, where a product provides it, retains information across sessions and must make it available again. It is neither the context window nor a guaranteed archive of the entire dialogue.
02
Do not immediately assume overflow
Example: after long technical logs, the agent returns to an old deadline. First check the date in the reference document and ask which passage it is using. A contradiction can also result from an outdated source, an ambiguous instruction or a misreading.
Counterexample: a short, incorrect response does not prove that the window was full. Look for a usage indicator, a limit error or a summary notice in the product. Without that information, the cause remains a hypothesis.
03
Understand what can change during a conversation
Depending on the product, an overlong conversation may cause request rejection, removal of older items or compaction into a summary. Truncation removes content; compaction replaces it with a shorter representation that may lose details. A large window does not guarantee correct use of every detail.
Check the limit and behavior of the model actually selected in current documentation. Account usage quotas, maximum output length and context capacity are distinct limits: a subscription or a shorter answer alone does not diagnose the problem.
04
Prepare a short, checkable restart
Keep a document you control with the current objective, dated decisions, constraints, reference files or links, completed work with evidence, next action and open questions. Check this summary against the sources before using it in a new conversation.
Example restart: “Agreed deadline: 18 October, quote v3 page 2. The 12th is superseded. Compare amounts only; change nothing.” Supply the necessary passage and request a restatement of the constraint before continuing. This checks the restart without guaranteeing every subsequent response.
- Current objective and next step: what the restart should produce.
- Dated decisions and constraints: what still applies and what was superseded.
- References and evidence: where to retrieve the original passage or result.
- Open questions: what must remain unknown rather than be reconstructed.
05
Resume one step, then compare
After restarting, request a short output for the next step and compare it with the reference document. Specifically check a superseded decision and a still-active constraint: these are details an overly vague summary may omit.
If the same error returns despite the supplied passage, stop extending the history. Isolate the contradiction in a short request, check that the file is actually readable and retain both conflicting versions. A new conversation without this clarification does not resolve the cause.
Keep this
Checklist
- 01The first output after restarting was compared with a source decision and constraint.
- 02The current source is identified.
- 03Suspected overflow is distinguished from observed overflow.
- 04The summary retains decisions, constraints and references.
- 05Necessary excerpts are accessible in the restart.
- 06A missing or conflicting decision is resolved before action.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- Understand and count tokens (opens in a new tab)Google · Tokenization units and input size measurement; no fixed word-to-token conversion is adopted.
- Long context (opens in a new tab)Google · Context capacity and strategies for summarizing or removing content; model capacities are not fixed here.
- Context windows (opens in a new tab)Anthropic · Primary source for technical distinctions; original SkillCodex procedure and examples.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Understand context windows and tokens” step by step
# Apply the “Understand context windows and tokens” guide in your agent ## Objective The context window is the working capacity available for a response. It is measured in tokens, not messages. An old exchange visible on screen is not necessarily present in full in what the model receives. Check decisions and their references when restarting; a useful summary can preserve the main points while losing a decisive detail. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Diagnose missing details in a long conversation and prepare a verifiable restart. - Preserve the correct decisions already in place. ## Guide steps - 1. Context, tokens and memory are different — A token is a unit used to represent content processed by the model; in text it may be a word or a fragment. Segmentation depends on the model and language. There is no universally reliable conversion between pages, words and tokens. - 2. Do not immediately assume overflow — Example: after long technical logs, the agent returns to an old deadline. First check the date in the reference document and ask which passage it is using. A contradiction can also result from an outdated source, an ambiguous instruction or a misreading. - 3. Understand what can change during a conversation — Depending on the product, an overlong conversation may cause request rejection, removal of older items or compaction into a summary. Truncation removes content; compaction replaces it with a shorter representation that may lose details. A large window does not guarantee correct use of every detail. - 4. Prepare a short, checkable restart — Keep a document you control with the current objective, dated decisions, constraints, reference files or links, completed work with evidence, next action and open questions. Check this summary against the sources before using it in a new conversation. - 5. Resume one step, then compare — After restarting, request a short output for the next step and compare it with the reference document. Specifically check a superseded decision and a still-active constraint: these are details an overly vague summary may omit. ## Acceptance criteria — Checklist - The first output after restarting was compared with a source decision and constraint. - The current source is identified. - Suspected overflow is distinguished from observed overflow. - The summary retains decisions, constraints and references. - Necessary excerpts are accessible in the restart. - A missing or conflicting decision is resolved before action. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:5bd468135d4ca7e4a36bad44b7f4697d30101696fcc5d0a3c1babe163298c67a
Diagnose a problem
Diagnose a “Understand context windows and tokens” guide gap
# Diagnose a failed application of the “Understand context windows and tokens” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. Context, tokens and memory are different — A token is a unit used to represent content processed by the model; in text it may be a word or a fragment. Segmentation depends on the model and language. There is no universally reliable conversion between pages, words and tokens. - 2. Do not immediately assume overflow — Example: after long technical logs, the agent returns to an old deadline. First check the date in the reference document and ask which passage it is using. A contradiction can also result from an outdated source, an ambiguous instruction or a misreading. - 3. Understand what can change during a conversation — Depending on the product, an overlong conversation may cause request rejection, removal of older items or compaction into a summary. Truncation removes content; compaction replaces it with a shorter representation that may lose details. A large window does not guarantee correct use of every detail. - 4. Prepare a short, checkable restart — Keep a document you control with the current objective, dated decisions, constraints, reference files or links, completed work with evidence, next action and open questions. Check this summary against the sources before using it in a new conversation. - 5. Resume one step, then compare — After restarting, request a short output for the next step and compare it with the reference document. Specifically check a superseded decision and a still-active constraint: these are details an overly vague summary may omit. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Checklist - The first output after restarting was compared with a source decision and constraint. - The current source is identified. - Suspected overflow is distinguished from observed overflow. - The summary retains decisions, constraints and references. - Necessary excerpts are accessible in the restart. - A missing or conflicting decision is resolved before action. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:c000030f947d5fe4984bc07300e645e213a8e27883d60ef74cc8df7563ff358d
Pack digest: sha256:239ba1b0dc9e882b0fee88f328c526262a608c450bbb6451574c6bf111ced082