[FEATURE] Expose partial compaction as /compact --from parameter for non-interactive use

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

Claude Code v2.1.32 added "Summarize from here" to the message selector, enabling partial conversation summarization. Internally, the function ea4 already handles message splitting and partial summarization — it splits the conversation at a selected message index, summarizes only the messages after that point using a partial-summary prompt template, and reconstructs the conversation as [boundary marker, preserved messages, summary, attachments, hook results].

However, this capability is only accessible through the interactive message selector UI (Esc+Esc menu). There is no CLI flag, environment variable, or command parameter that allows specifying the split point programmatically. The code calls ea4 directly from the React-based message selector component with no abstraction layer between them.

This means automated workflows that spawn Claude Code workers (e.g., agentic frameworks, CI pipelines, long-running batch processes) cannot use partial compaction at all. They are limited to full compaction via /compact, which summarizes the entire conversation indiscriminately and destroys recent working context.

Why this matters for agentic use cases: When Claude Code is used as a worker process (claude -p or SDK-based), context management is critical. Auto-compaction at a threshold is a blunt instrument — it triggers at arbitrary points and summarizes everything, including the recent task state the agent needs to continue working. Partial compaction would allow an orchestrator to say "summarize the old exploration history but keep the last N messages where the agent found the solution and is now implementing it."

Proposed Solution

Expose the existing partial compaction logic through the /compact command interface:

/compact --from <message-index>

Or alternatively, a more ergonomic variant:

/compact --keep-last <N>

Where --from <message-index> specifies the split point (messages before it are preserved verbatim, messages after it are summarized), and --keep-last <N> preserves the last N messages while summarizing everything older.

Both parameters should work in non-interactive mode (claude -p) and be compatible with the existing /compact <custom-instructions> syntax, e.g.:

/compact --keep-last 10 "focus on the database migration progress"

Why this is minimal implementation effort

The partial compaction logic already exists and works:

1. ea4 (partial compaction) splits messages at an index, summarizes a subset, and reconstructs the conversation. This is the "Summarize from here" implementation.
2. rW6 (full compaction) summarizes the entire conversation. This is what /compact currently calls.

The feature request is to add a parameter to the /compact command that routes to ea4 instead of rW6 when a split point is specified. The core summarization infrastructure, prompt templates, and conversation reconstruction logic are all already implemented and shipping in production.

Related issues

• #19877 — Claude-invocable conditional /compact (focuses on programmatic triggering; this issue focuses on partial vs. full compaction scope)
• #14258 — PostCompact hook event (complementary; hooks cannot control what gets compacted)
• #24058 — Closed as dup of #19877 (proposed CompactContext tool call)
• #7919 — --keep-recent parameter (similar concept, auto-closed; this issue provides stronger justification via the existing ea4 implementation)
• #2705 — Selective compaction by range (auto-closed; same underlying need)

Motivation for Anthropic

Agentic frameworks are a growing use case for Claude Code. Projects that orchestrate multiple Claude Code workers need programmatic control over context management to avoid context_exhaustion failures. The "Summarize from here" feature proves partial compaction is technically sound — exposing it as a CLI parameter unlocks it for the automated workflows that need it most.

This would also complement the Messages API's server-side compact_20260112 beta with pause_after_compaction, which achieves similar goals at the API level. Having parity at the CLI level would give users a consistent partial compaction story across both interfaces.