Feature: model-initiated /compact at task boundaries (agentic compaction instead of threshold-only)

Problem

Auto-compaction triggers only near the hard context limit — almost always mid-task, which is the worst possible moment: the summary is written while work is in flight, and quality degrades right when the model needs full context.

Related issues ask for a configurable threshold (#72062, #70431, #31954), but a threshold alone is still blind to task boundaries: 40% reached mid-task is a bad time to compact; 40% reached right after finishing an activity is the perfect time.

Proposal

Let the model decide when to compact, gated by a threshold:

• Expose context usage to the model (or at least a "you're above N%" signal).
• Provide a way for the model to request compaction (a compact tool, or a hook the model can trigger) — allowed only above a user-configurable threshold (e.g. compactAllowedAbove: 40%).
• The model invokes it at clean task boundaries: current activity finished, no work in flight, persistent notes updated.

Why it pays for itself

Per-call input cost scales linearly with context size even with prompt caching — cache reads are billed per token, and the discount applies equally at any size. An activity requiring 50 tool calls executed at ~90% context costs roughly 9× the same activity executed at ~10% context (input component). The one-time cost of a compaction pass (mostly cache reads + a few k output tokens) is amortized within the first 2–3 subsequent calls.

So model-initiated compaction at task boundaries yields both lower cost (every subsequent call is cheaper) and higher quality (a summary written at a clean boundary is far better than one forced mid-task).

Today none of this exists: /compact is strictly host-side, hooks (PreCompact/PostCompact) can only observe, and the model has no context gauge.