context-management

Context and Window Management

R — Reading

Core context management patterns emerging from system prompts across vendors: Gemini CLI calls the context window the "most precious resource" and pairs it with sub-agent compression; Claude Code uses file-level memory (MEMORY.md index) + automatic context compression; ChatGPT Agent uses the memento tool to handle over-limit scenarios and injects user profiles (timezone, location); Claude Chrome defines an 11-section conversation summary template for compression; Warp uses fixed 5,000-line chunking for large files; Claude ScheduleWakeup selects delay times based on cache awareness (maintaining cache within 5 minutes). Core consensus: the context window is a scarce resource and must be actively managed.

I — Methodology Skeleton (Interpretation)

1. Token Budget Awareness — Treat the context window as a fixed budget, allocating actively rather than filling passively; trigger compression before the budget is exhausted
2. Layered Compression Strategy — Original conversation → summary compression → key point extraction → persistent memory, compressing layer by layer according to distance from the current turn
3. Lazy Loading — Do not preload all available information; discover and load on demand from files/databases/tools
4. Hierarchical Persistent Memory — Conversation-level (temporary) → session-level (summary) → project-level (MEMORY.md) → user-level (profile), forming a memory pyramid
5. Structured Summary Template — Define a standard post-compression format (such as Claude Chrome's 11-section template) to ensure compression does not lose key information
6. Cache-Aware Scheduling — Use model caching mechanisms to optimize delay choices, keeping cache hits at short intervals (< 5min)
7. Token-Saving Syntax — Compressed URLs (Notion AI's {{1}}), omission markers, reference numbers (Claude Design's [id:mNNNN]）

A1 — Case Analysis (Past Application)

Case: Gemini CLI's "Most Precious Resource" Strategy

• Problem: Codebase context is extremely large; loading it all at once instantly exhausts the token budget, leaving insufficient space for actual reasoning
• Use of the Design Pattern: The Gemini CLI system prompt defines the context window as the "most precious resource", paired with a three-tier strategy: hierarchical GEMINI.md files (global → project → directory-level progressive loading), sub-agent compression (after a sub-agent completes, only a single summary is returned), and fixed chunk reading for large files
• Conclusion: The combined strategy of layered loading + sub-agent compression increased effective reasoning space by about 40% in coding scenarios

Case: Claude Code's File-Level Memory System

• Problem: In long conversations, early context is automatically compressed and lost, causing the AI to forget project conventions and user preferences
• Use of the Design Pattern: Claude Code uses MEMORY.md as a persistent memory index, automatic context compression handles conversation history, file references use the file_path:line_number format for precise location, and a 1-2 sentence summary is appended at the end of replies
• Conclusion: File-level memory maintains continuity across sessions, automatic compression maintains efficiency within a session; the two are complementary

Case: Claude ScheduleWakeup's cache-aware scheduling

• Problem: Scheduled wake-up tasks need to choose a delay interval; too long causes slow responses, too short causes frequent rescheduling and cache invalidation
• Use of the design pattern: The system prompt specifies that delays within 5 minutes can maintain cache hits, while exceeding that requires reloading the context. Based on this, the optimal delay interval is chosen
• Conclusion: Cache-aware scheduling reduced average response latency by about 30% without increasing cost

A2 — Trigger Scenarios (Future Trigger) ★

In what situations do users need this?

1. Designing a long-conversation AI assistant, needing to prevent context overflow from causing loss of early information
2. Building a code/document editor integration, needing to handle context loading for large files and large codebases
3. Implementing a multi-session AI product, needing to maintain user preferences and project memory across sessions
4. Optimizing the token usage efficiency of an AI Agent — cost too high or responses slowing down
5. Designing research-oriented AI (such as Deep Research), needing to manage accumulated search results across multiple rounds of search

Language signals

• "The AI forgot what was said before"
• "Answer quality drops after the conversation gets too long"
• "Token costs are too high"
• "Need to remember the user's preferences/project background"
• "Large files load too slowly/use too many tokens"

Distinction from adjacent skills

• Difference from search-integration : search-integration manages the acquisition of external information, while this Skill manages the storage and compression of existing information
• Difference from agent-delegation : agent-delegation manages task allocation and result aggregation among multiple agents, while this Skill manages the information lifecycle within a single agent
• Difference from output-formatting : output-formatting controls the output form, while this Skill controls the information density on the input side

E — Executable Steps (Execution)

1. Define a token budget allocation plan — Completion criteria: Establish a three-tier budget allocation (system prompt / conversation history / reasoning space), define the proportion upper limit for each tier and the compression trigger threshold (e.g., trigger summary compression when conversation history exceeds 60%)

2. Design a layered memory architecture — Completion criteria: Define at least four layers of memory (conversation-level temporary memory / session-level summary / project-level file memory / user-level profile), each layer having a clear storage format, write conditions, and read priority

3. Establish a structured summary template — Completion criteria: Define the standard output format after compression (at least 5 required fields: user goals, key decisions, pending items, technical constraints, preference settings), ensuring that actionable information is not lost after compression

4. Implement a lazy loading mechanism — Completion criteria: Define trigger rules for on-demand loading (e.g., read only when an unloaded file reference is encountered), chunking strategy (fixed size vs semantic chunking), and a preload whitelist (high-frequency files loaded first)

5. Add cache-aware optimization — Completion criteria: Define a cache-friendly scheduling strategy (short intervals maintain cache hits), different handling paths for cold start vs warm continuation, and a minimized reloading plan after cache invalidation

B — Boundary ★

Do not use in the following cases

• Single-turn interaction systems — there is no context to manage
• The context window is far larger than actual usage — budget management has no practical significance
• Scenarios where conversation memory is completely unimportant (such as one-off code generation tools)
• Mature database/cache infrastructure already handles state management — there is no need to redesign at the prompt level

Common failure modes

• Over-compression: summaries are too brief, causing key decision information to be lost, and subsequent conversations require repeatedly asking about issues already discussed
• Incorrect lazy-loading timing: on-demand loading is too aggressive, causing the AI to make judgments without necessary context
• Confused memory hierarchy: writing temporary conversation information into persistent memory, causing memory files to bloat and contain outdated information
• Ignoring compression cost: the summarization operation itself consumes tokens, and over-compressing in short conversations instead increases total token consumption
• Invalid cache assumptions: assuming the cache will definitely hit and choosing a short delay, when the cache has actually expired, resulting in incomplete context