Understand the working context
Shared methods · A shared method; linked tool guides explain the exact steps.
This page covers tools outside your selection. You can still read it. Find matching guides
Distinguish a model's working input from stored files, retrieval, compaction, memory, and cumulative usage.
A model answers from the input made available for that request. The surrounding product decides how instructions, conversation history, files, retrieved passages, and tool results enter that working context.
A stored conversation or attached file is not a promise that its entire contents are included unchanged on every turn. Products can retrieve selected material, summarize, compact, truncate, or reuse cached input. Their behavior differs.
Separate capacity, persistence, and usage
The context limit concerns what one request can accommodate under the model's rules. Cumulative usage adds work across requests. A project, repository file, or saved memory can persist outside the current context and be loaded later.
Use the provider references for selected API limits and access guidance. API limits do not establish the exact working limits of a chat or IDE surface. A quota notice is also different from a context-limit error.
Repeated input can increase cumulative usage, but caching and product accounting affect the cost. Do not infer a subscription charge from attachment size alone.
Give a coding task a durable task record
For a search-focus bug, maintain a short record:
Goal: preserve input focus while results update.
Evidence: reproduction and relevant component paths at the recorded revision.
Constraints: preserve existing search matching and keyboard behavior.
Done: reproduced failure, reviewed fix, appropriate checks passed.
Open: whether the empty-result state has the same focus problem.
Keep source pointers with the summary. An agent that needs the original component can inspect it through its configured tools. A chat session needs the material supplied or made available through its own supported surface.
Recognize a context problem carefully
A repeated question or forgotten constraint can indicate missing or poorly selected context. It can also reflect ambiguity, a reasoning error, or failed retrieval. Those symptoms alone do not prove the window is full.
Inspect available context indicators, retrieved sources, and tool output. Ask the tool to name the constraints and the source revision it is using, then compare its answer with the record. Treat the answer as a checkable claim.
Handle long work according to the product
Claude Code and Codex document context-management strategies for long work. Their commands and automatic behavior are product-specific. Preserve useful progress on a coherent task, and verify important constraints after compaction.
Use Claude Code context guidance, Codex task planning, and Gemini CLI project context for concrete setup.
A new session needs a handoff. Product memory and saved instructions may help, but a native session ID from another provider does not transfer its context.
What goes wrong
Attaching everything can bury relevant evidence. Trimming too aggressively can remove a contract or caller that changes the answer. A compacted summary can omit a requirement. A fresh conversation can discard useful decisions if the handoff is incomplete.
There is no universal number of turns after which every task should restart.
How to check
Choose a requirement that previously went missing. Inspect the actual source, supply the necessary context, and rerun the relevant behavior check. Compare results on similar tasks before adopting a context strategy.
Improvement after trimming is useful evidence, but one better answer does not prove context length was the sole cause. Preserve the reproduction and acceptance checks while experimenting.
Sources
- Anthropic: effective context engineering Tier 1 2026-09-08
- OpenAI: conversation state Tier 1 2026-09-08
- OpenAI: Codex best practices Tier 1 2026-09-08
Something wrong with this page?
Say what you expected and what you got. That is usually the shortest route to a correction, and it goes on the public issue tracker so the fix is visible.