openclaw - 💡(How to fix) Fix Feature Request: Context Management — Manual Free for Tool/Skill Outputs in Context

Problem

OpenClaws context management is append-only. Once a tool call result is written into the context window, it stays there until compaction or pruning kicks in. The agent (model) or external systems have no mechanism to mark old data as stale or reclaim that context space.

As a consequence, any workflow that involves "read → modify → re-read" of stateful data accumulates redundant, expired data in the context window, rapidly consuming valuable tokens.

Concrete Example: Spreadsheet Read/Write Loop

Imagine a user builds a Tool (or Skill) that reads a spreadsheet and returns its content as a Markdown table. Typical workflow:

1. Read → Model calls read_spreadsheet, receives a 50-row Markdown table. This occupies ~N tokens in context.
2. Modify → Model calls write_spreadsheet to insert a row. Row numbers and positions shift.
3. Re-read → Model needs to verify the latest state before the next edit (to avoid inserting at the wrong position). It calls read_spreadsheet again.

Now the context contains two copies of the spreadsheet:

• Copy 1: the old state (50 rows, now stale)
• Copy 2: the new state (51 rows, current)

Copy 1 is completely useless. Yet it still occupies context tokens. Every subsequent read-modify-read cycle adds another copy. After a few iterations, the context is filled with expired snapshots.

The Memory Analogy

Think of the context window as a block of memory:

• Current behavior: Every tool result is equivalent to malloc() — allocation only, no release. Old data is only handled when memory runs out (compaction), and even then its summarized, not precisely reclaimed.
• Desired behavior: The caller can manually manage the lifecycle of context data — explicitly specifying which data to free. Like Cs malloc() + free(), the caller knows when to free data thats no longer needed.

In other words:

When you no longer need a block of memory, you can free it to reclaim space. The context should support the same capability.

General Scope

This is not limited to tools. It should be a general context management capability available to:

• Tools — tool results can return a trackable identifier for later release
• Skills — Skill instructions can signal "the previous read is stale, please free it"
• Extensions / Plugins — any external system that manages contextual data can participate in this lifecycle

Proposed Mechanism

1. Allocate: Each tool result / Skill output, when written into context, receives a stable, addressable ID.
2. Free: The agent (or external system) can explicitly designate a result ID as "no longer needed," causing it to be removed from context or replaced with a minimal placeholder.

Both operations are initiated by the caller — the system does not auto-judge or auto-reclaim.

Why This Matters

Current Alternatives (Insufficient)

• Compaction: Summarizes old history — lossy, imprecise, only triggers when the window is near full.
• Context Pruning: Trims old tool results based on TTL and static allow/deny lists — no model-side control, no per-result precision.
• Neither supports on-demand, targeted manual free operations.