5-Layer Context Compression Strategy

Overview

In long-conversation scenarios, the context token count gradually approaches the model's context window limit. The system adopts a cascading scheme of three-layer architecture with five compression strategies, intelligently managing context length while ensuring conversation quality.

Strategy Overview

Layer 1: Preventive Tool Result Truncation

When triggered: Automatically executed before every LLM call (preventive; does not wait for overflow to occur).

Strategy ① — Single Tool Result Truncation

When a single tool result exceeds 50% of the context window, truncate it to budget:

                      
                      Original tool output (excessively long)
│
├── Keep the first N characters (break at a line boundary)
└── Append marker: [truncated: output exceeded context limit]

                    

Key constant:

• SINGLE_TOOL_RESULT_CONTEXT_SHARE = 0.5 (single-tool cap ratio)

Strategy ② — Old Tool Result Compaction

When total input exceeds 75% of the context window, compact starting from the earliest tool results:

                      
                      Tool call history (chronological)
│
├── Newest tool result → keep full content
├── Newer tool result → keep full content
├── Older tool result → [compacted: tool output removed to free context]
└── Oldest tool result → [compacted: tool output removed to free context]

                    

Whitelist mechanism: Compaction is applied only to the following high-output tools:

• Read File, Bash, Grep, Glob, Search Files, Web Fetch, Edit

The output of Write/Create-type tools is always retained, because its output is the basis for subsequent operations.

Key constant:

• CONTEXT_INPUT_HEADROOM_RATIO = 0.75 (total-input cap ratio)

Layer 2: Overflow Detection and Message History Pruning

When triggered: Passively triggered when the LLM returns a context overflow error.

Strategy ③ — Message History Pruning

Prune middle history messages while keeping key messages:

                      
                      Message history
│
├── System Prompt                    ← always retained
├── First user message               ← always retained
├── Messages with _pin: true         ← always retained
├── ........ middle history ........ ← pruned (replaced with a notice)
├── [context compacted: X earlier messages removed]
├── Most recent N messages           ← retained (N = min(6, ⌊total/3⌋))
└── Current message                  ← retained

                    

After pruning, the system automatically repairs orphaned tool pairs (a tool_use with no corresponding tool_result, or vice versa) to ensure the message format is valid.

Layer 3: Intelligent LLM Summarization

When triggered: Triggered when Layer 2 pruning is still insufficient to relieve context pressure.

Strategy ④ — Full Summarization

Use an independent LLM call to produce a structured summary of the history messages:

9-section summary format:

1. User intent and goals
2. Key concepts and terminology
3. Files and paths involved
4. Errors encountered and their solutions
5. Problem-solving approach
6. Key user messages
7. Tasks to be completed
8. Current work progress
9. Next-step plan

Chunking strategy: When messages exceed 50,000 characters, they are split into at most 4 chunks that are summarized separately and then merged into the final summary.

Strategy ⑤ — Partial Summarization Degradation

When full summarization fails, a three-level degradation is performed:

Summary of Key Constants

EMA Token Calibration

The system uses an exponential moving average to dynamically calibrate the chars-per-token estimate:

Compression Flowchart

                      
                      Before every LLM call
    │
    ├── Layer 1: enforceToolResultBudget()
    │   ├── Single-tool truncation (>50% context)
    │   └── Old-tool compaction (total input >75% context)
    │
    ├── shouldPreemptiveCompact() ?
    │   └── Yes → compact() (Layer 2 pruning)
    │
    └── LLM call
        │
        ├── Success → continue
        └── Overflow error → getRetryStrategy()
            │
            ├── compact() (Layer 2)
            │   │
            │   └── Still insufficient → compactWithSummary() (Layer 3)
            │       ├── summarizeMessagesFull() (Strategy ④)
            │       ├── Failure → summarizeMessagesPartial() (Strategy ⑤ Level 1-2)
            │       └── Total failure → bare notice (Strategy ⑤ Level 3)
            │
            └── Retry LLM call (up to 5 times)

                    

What This Means for You

Context compression is the reason behind the "the Agent forgot what came before" phenomenon you may sense in long conversations. It is not a bug, but rather the mechanism by which the system intelligently manages information within a limited context window.

Phenomena you may observe:

• In a long conversation, the Agent suddenly "does not remember" a requirement you mentioned at the beginning → this is Layer 2/3 having compressed the early messages
• The Agent says "based on our earlier discussion..." but the details may not be entirely accurate → after compression, only a summary was retained
• The historical results of tool calls turn into [compacted] → this is Layer 1 having compacted old tool output

How you can respond:

• Say "please remember" for key information: This triggers the memory system to store it, unaffected by context compression
• Restate key requirements: In a long conversation, periodically restate your core requirements
• Choose a large-context model: GPT-4.1 (1M) or Claude (200K) can retain more context than DeepSeek (64K)
• Start a new conversation: If the conversation is already very long and cluttered, starting a new one may be more efficient than continuing

Related Documents

• Agent Loop Engine — where context management sits within the loop
• Model Configuration — the context window size of each model
• List of Supported Models — the model capability matrix