research(context): compaction has no cache-prefix-stability awareness (TokenPilot-inspired, arXiv:2606.17016)

[bug-ops]

Description

A recent paper, "TokenPilot: Cache-Efficient Context Management for LLM Agents" (arXiv:2606.17016), identifies a tension in long-horizon LLM agent deployments: context-trimming/compaction that alters the prompt prefix invalidates provider prompt caches (e.g. Anthropic cache_control ephemeral caching), even when only a small amount of content needed to change. TokenPilot's fix is a dual-granularity approach: ingestion-aware compaction (stabilize prefixes at the point content enters context) + lifecycle-aware eviction (evict on a conservative batch-turn schedule rather than ad hoc, so cache-boundary shifts stay infrequent and predictable).

zeph has mature prompt-caching support (crates/zeph-llm/src/claude/, cache_control/ephemeral caching, extensive boundary/padding test coverage — see Aider parity row in .local/testing/playbooks/competitive-parity.md) and a separate compaction/context-budget subsystem (crates/zeph-context/src/manager.rs: CompactionTier/CompactionState/cooldown counters; crates/zeph-core/src/agent/mod.rs:1835 maybe_compact()). These two subsystems appear to have zero cross-awareness in the code today.

Reproduction Steps

1. rg -n "cache_control|prefix.*stab|cache.*boundary|cache.*invalidat" crates/zeph-context/src/*.rs crates/zeph-agent-context/src/*.rs
2. Observe: zero hits.
3. Compare against crates/zeph-core/src/agent/sidequest.rs:344 — an existing "C1 fix: prevent maybe_compact() from firing in the same turn" guard shows turn-level compaction-frequency control already exists, but it targets redundant-compaction avoidance, not cache-prefix economics.

Expected Behavior

Compaction/eviction decisions should account for prompt-cache prefix stability as a cost factor — e.g. preferring append-only/tail-eviction shapes that preserve the cached prefix boundary where sufficient, and treating "will this pass invalidate an expensive warm cache" as an explicit input to the tier/threshold decision.

Actual Behavior

Compaction triggers purely on token-budget thresholds/cooldowns; no code path models the interaction with prompt-cache economics.

Environment

• Version/commit: 3911df2
• Features: n/a (research finding, no live-test run)

Evidence

• Duplicate check: gh issue list --label research (open + closed) searched for "cache invalidat", "prefix stab", "prefix mismatch", "cache continuity", "cache prefix" — no existing coverage.
• Single-paper finding (arXiv:2606.17016), not yet corroborated by a second reference agent — flagged P4/exploratory per protocol.
• Spec marks several [NEEDS CLARIFICATION] items (OpenAI cache semantics, whether zeph-llm tracks breakpoint state today, missing baseline metrics, and whether to fold into related open spec 067-context-paging-visibility).

Spec

.local/specs/081-compaction-cache-prefix-stability/spec.md

[bug-ops]

Second independent source corroborates this gap (CI cycle 1445, 2026-07-20).

arXiv:2602.22402 ("Contextual Memory Virtualisation: DAG-Based State Management and Structurally Lossless Trimming for LLM Agents", Feb 2026, Imperial College London) independently identifies the same core tension this issue tracks — that context-trimming/compaction decisions have real, measurable interaction with prompt-cache economics — from a different angle than TokenPilot:

• Empirical case study (76 real-world coding sessions, not a synthetic benchmark) shows trimming "remains economically viable under prompt caching," with mixed tool-use sessions averaging 39% token reduction and reaching cost break-even within 10 turns.
• This is a data point for the underlying concern (cache-aware trimming has measurable ROI), predating TokenPilot's May/June 2026 paper.

This satisfies the spec's own escalation criterion (.local/specs/081-compaction-cache-prefix-stability/spec.md, "Corroboration status"): "Escalate to P2/P3 only if a second independent source (paper or shipped competitor feature) corroborates the approach." Recommending priority bump P4 → P3 on that basis.

Separately checked CMV's other headline contribution — "structurally lossless trimming" that strips raw tool outputs/base64 images/metadata while preserving messages verbatim — against zeph's existing code: already has a close analog, not a new gap. crates/zeph-context/src/microcompact.rs (sweep_stale_tool_outputs) and crates/zeph-agent-context/src/summarization/pruning.rs (prune_tool_outputs) already do verbatim-preserving stale-tool-output stripping ahead of/independent from LLM-summarization compaction. No new issue filed for that half of the paper.

No code changes made this cycle (read-only CI research session).