← Back to News

feature

Sep 21, 2026

Layered tool-result compression with exact local recall

ReclaimLLM now reduces repeated and verbose tool output with provider-aware transforms, bounded state, and content-addressed local recall handles.

ReclaimLLM can now reduce large and repeated tool results before they consume more model context. The new pipeline uses deterministic, provider-aware transforms for Claude, Codex, and Gemini, adds bounded input shaping for Antigravity, and preserves exact local results behind recall handles when artifact storage succeeds.

The main additions are stateful result deltas, compact edit receipts, provider-output normalization, recallable result artifacts, typed task-state tracking, and more complete Codex and Cursor capture.

A layered compression pipeline

Supported tool results now pass through a fixed sequence:

  1. Secret redaction
  2. Range-aware read handling
  3. Stateful result delta
  4. Command or provider-specific compaction
  5. Edit receipts
  6. Hash-based deduplication

Each mechanism only handles explicitly recognized tool names and result shapes. Once a mechanism replaces a result, later lossy mechanisms do not process it again.

Errors, failed commands, images, ambiguous content blocks, unknown tools, and unsupported provider shapes pass through unchanged. Compression failures do not interrupt the coding client.

Stateful result deltas

Repeated commands, searches, and directory listings often return mostly the same content. ReclaimLLM now compares consecutive results with the same semantic target and can replace the newer result with its changes.

A delta identifies:

  • Lines added or changed
  • Lines removed or resolved
  • The number of unchanged lines
  • A SHA-256 digest of the complete captured result

The mechanism applies only when the new result overlaps the previous result by at least 60% and the delta is smaller than the original. Failed commands are never converted into deltas.

State is bounded to prevent long sessions from accumulating unlimited local memory: 128 targets, 256,000 characters per result, and 8,000,000 characters per session.

Compact edit receipts

Some coding tools return the complete diff after a successful edit, even though the model already knows the requested change.

For recognized successful edit operations, ReclaimLLM can replace that echoed diff with a deterministic receipt containing:

  • The target file
  • Hunk count
  • Added and removed line counts
  • New-line ranges
  • A SHA-256 digest of the complete result

If the target reported by the provider does not match the requested target, ReclaimLLM leaves the response unchanged.

Failures also remain intact. The receipt path is limited to successful results with recognized diff structures.

Exact local recall

When an enforced compact result is eligible for recall, ReclaimLLM stores the exact original text as a content-addressed local artifact before adding a recall handle.

Artifacts use SHA-256 handles such as:

rclm://artifact/sha256/<digest>

A specific character range can be retrieved with:

rclm recall-result <session-id> <handle> --start 0 --end 4000

Artifact writes are atomic and use owner-only file permissions. Storage is bounded to 32 artifacts and 32 MiB per session, with an 8 MiB limit for an individual artifact.

A recall stub is added only when artifact persistence succeeds and the result remains smaller after adding the stub. Recall artifacts are currently local to the machine that produced them; they are not synchronized across devices.

Provider-specific improvements

Codex capture now pairs both standard function outputs and custom tool-call outputs with their originating calls. Structured content blocks, including non-text blocks, remain structured instead of being flattened during capture.

Cursor capture now preserves explicit empty or falsy results. Historical Cursor sessions that never recorded a result cannot be reconstructed safely and remain unchanged.

Antigravity view_file calls without a bounded range are capped at 200 lines before execution. Supported run_command calls can also use the existing command compressor.

Antigravity currently requires its post-tool hook to return an empty response, so result-side replacements for that provider can be evaluated during replay but cannot be enforced through the current hook contract.

Bounded task-state tracking

ReclaimLLM now maintains a typed local task ledger derived from explicit tool activity.

The ledger can record:

  • Goals and constraints
  • Decisions
  • Files read, searched, created, modified, or deleted
  • Test commands and outcomes
  • Structured errors
  • Next actions
  • Associated recall handles

This is deterministic extraction from known plan fields and tool semantics. It does not ask another model to summarize arbitrary conversation text, avoiding an additional inference call in the hook path.

What replay showed

Across the latest 50 captured sessions, the combined deterministic replay removed 3,086,700 of 7,844,777 text tool-result tokens, or 39.35%.

When the Antigravity 200-line pre-tool read cap was included in the model, the reduction reached 3,254,985 tokens, or 41.49%.

An older 69-session corpus showed a 34.21% reduction. The difference is expected because tool and provider distributions vary between workloads.

A separate model of superseded results estimated a 15.11% reduction in repeated tool-step context. That figure is a context proxy. It is not measured provider billing, output-token reduction, or proof that a live agent will complete a task in fewer tokens overall.

Current limits

The transforms are intentionally conservative, so some compressible results remain untouched.

Replay cannot determine whether compression changes the agent's decisions, creates additional retries, reduces prompt-cache reads, or changes billed input and output tokens. Those questions require paired live evaluations.

We are watching for provider schema changes, tools that should remain uncompressed, tasks that require details currently summarized by receipts or deltas, and workloads where lower result volume causes more follow-up reads.

If you encounter one of those cases, we want the original result shape, provider, tool name, and expected behavior. That feedback will determine which transforms remain enabled by default and which need narrower eligibility rules.