[FEATURE] Model-Driven Tool Output Compression

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

Every tool invocation in Claude Code appends its full output to the conversation context. As the session progresses, the context window fills up with stale tool outputs that are no longer relevant — test results, build logs, file listings, grep outputs, etc.

This has several consequences:

1. Context window exhaustion — Long sessions hit the context limit prematurely, forcing conversation compaction or a fresh start, both of which lose important architectural context.
2. Increased token cost — Every subsequent API call re-sends the entire history, including tool outputs that have already been processed and acted upon.
3. Signal-to-noise degradation — The model spends attention on irrelevant past outputs instead of focusing on the current task.

Concrete Example

See the Use Case Example section below for a detailed before/after.

Proposed Solution

Proposed Solution

Add a flag/option (e.g., --compress-tool-output or a setting in .claude/settings.json) that enables the model to replace a tool's output with a summary after it has been consumed.

Behavior

• After the model processes a tool output and generates its response, it can optionally emit a structured compression directive (e.g., a special tag or metadata field) containing a summary.
• On subsequent turns, the original output is replaced in the conversation history with the compressed summary.
• The compression is model-driven — Claude decides what to keep and what to summarize, since only the model knows what information is still relevant.
• Optionally, a --no-compress flag per tool call could override this for outputs the user wants preserved verbatim.

Why Model-Driven?

Claude already sometimes works around this by piping commands through grep FAIL or tail, but this is:

• Inconsistent — it only does this some of the time.
• Preemptive — the model has to guess what matters before seeing the output.
• Lossy — filtering at the command level can miss relevant information.

Post-hoc compression is strictly better: the model sees the full output, extracts what matters, and then discards the rest.

Alternative Solutions

Alternatives Considered

| Approach | Drawback |
|----------|----------|
| Automatic truncation by line count | Loses relevant information arbitrarily |
| Always pipe through grep/tail | Inconsistent, preemptive, model-dependent |
| Manual /compact by user | Requires user awareness of context pressure; compresses everything, not selectively |
| Sliding window eviction | No semantic understanding of what's important |

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Use Case Example

Running an integration test suite against a Valkey-backed messaging system produces ~300 lines of output — PAUSEs, CONTs, individual PASS lines for 80+ tests. Claude reads the output, confirms everything passed, and proceeds to the next task. But those 300 lines stay in context forever.

Before (current behavior):

=== RUN   TestIntegration_Consumer_ProcessesMessages
=== PAUSE TestIntegration_Consumer_ProcessesMessages
=== RUN   TestIntegration_Consumer_HandlerErrorKeepsMessagePending
=== PAUSE TestIntegration_Consumer_HandlerErrorKeepsMessagePending
... (300+ lines)
--- PASS: TestIntegration_Consumer_DefaultsForBlockTimeout (5.01s)
PASS
ok  github.com/follow/follow-pkg/tests/integration	(cached)

After (with compression):

[Compressed] All 80 integration tests passed (cached). Suites: Consumer (13), HealthChecker (8),
Producer (7), ProgressTracker (7), Reclaimer (11), UploadGuard (7), ValkeyClient (27). ~5s total.

Same information density for subsequent turns. Zero context waste.

Additional Context

This would be especially impactful for:

• TDD workflows with frequent test runs
• Build/compile cycles with verbose output
• Large codebase exploration (find, tree, cat on multiple files)
• CI/CD log analysis
• Any long-running agentic session

This feature also has a significant impact on agent vs. non-agent workflow flexibility. Today, to work around context pressure, many users are forced to run nearly everything inside sub-agents (via the Task tool) — often enforced through a CLAUDE.md instruction like "always use agents for execution." Sub-agents have their own isolated context, so their verbose outputs don't pollute the main conversation. But this is a workaround, not a solution: it adds latency, loses main-thread context, and makes the workflow rigid. With model-driven compression, the main thread can absorb tool outputs directly without context bloat — removing the need to delegate everything to agents, enabling longer sessions, and giving users a more natural and flexible workflow.

Beyond the main thread, this applies equally to sub-agents themselves. Today, sub-agents hit their own context limits quickly when executing multi-step tasks — running tests, reading files, iterating on code. With compression enabled inside sub-agents, they could run significantly longer before exhausting their context, making them viable for complex, multi-phase tasks that currently require splitting across multiple agent invocations.

The feature aligns with Claude Code's goal of enabling extended autonomous coding sessions without running into context limitations.