Compaction and Context Pressure

Conclusion: There Is No Fixed “Multi-Level Compaction,” Only Two Recursively Composable Surface Transformations

Pressure and context overflow are two trigger paths, not two compaction levels. The default compactionRetries: 1 permits one additional summary after the first summary; it does not limit a Session to two lifetime compactions. Later Steps can trigger the policy again and merge an older checkpoint into a newer checkpoint.

1. Separate Mechanisms, Triggers, Attempt Budgets, and Recursive Algebra

Surface₀
  ├─ prune(large tool result)        → Surface₁
  ├─ summarize(balanced head span)   → checkpoint₁ + retained tail
  └─ later summarize(checkpoint₁ …)  → checkpoint₂ + newer tail

This distinction matters. Retry settings answer “how many more attempts may one pressure invocation make?” Recursive checkpoints answer “may a prior result be compacted later?” Their interaction creates the generations visible in a long-running Session.

2. Configuration Resolves Against an Exact Provider / Model Route

Proactive pressure therefore needs two facts: the latest durable request header must identify a route, and that route's adapter must expose context capacity. Overflow is already a Provider fact, so recovery can proceed without the threshold or capacity premise.

3. The Token Meter Estimates the Next Request’s Pressure; It Does Not Tokenize Every Node Exactly

4. Proactive Pressure Runs Between Steps but Cannot See the Entering Batch

claim inbox messages
→ assemble system/tools
→ compute runtime-context candidate
→ dispatch agent/pre-step waterfall
     └─ pressure listener measures current durable Surface
→ append step/start
→ append claimed user/context messages
→ dispatch Provider request

5. Shrinking Mechanism One: Model-Free Middle Pruning of Tool Results

The pressure path does not opportunistically prune below threshold. Once pressure qualifies—or overflow has occurred—it prunes first and remeasures. If that is sufficient, no summary model is called; otherwise, the summary sees the already-pruned Surface. Test source covers all three branches. COMPACT-PRUNE-TEST

6. Shrinking Mechanism Two: Retain a Recent Tail and Summarize a Head-Anchored Span

The pressure path walks backward from the Surface tail until it has accumulated the retention budget, then moves the cut toward the head until it finds a tool-call/result-balanced boundary. It compacts the head rather than selecting scattered messages deemed “unimportant.” The overflow path uses a zero retention budget to release as much space as possible.

7. A Legal Cut Guarantees Tool Pairing, Not a Step or Turn Boundary

The pairing fold scans current Surface order. Every assistant tool call increments a balance, each tool result decrements it, and the fold computes N+1 cuts around N nodes. It rebuilds after a replacement generation change and extends incrementally for ordinary appends.

This gives the precise answer to “how many levels exist?” A log may contain arbitrarily many checkpoint generations, while every transaction still performs one span replacement. The level count is historical recursion depth, not a set of specialized runtime phases.

8. The Summary Call Reuses Conversation Shape but Is Not a Hidden Second Agent Loop

summary request
= current system prompt
+ current ordered tool schemas
+ selected region as model messages
+ one fixed English compaction directive
→ one Provider stream (purpose = "compaction")
→ collect non-empty text only
→ frame as <compacted-summary>…</compacted-summary>

The request retains the original system/tools/region prefix and places one fixed directive at the end, creating a cache-reuse shape when the route is the same. Choosing another provider/model preserves the shape but cannot share a provider cache across routes.

9. A Summary Is a Locked, Revalidated, Multi-Append Log Transaction

10. A Checkpoint Stores Model Text, Source Span, and Actual Call Evidence Separately

11. How Recursive Checkpoints Produce Real Multi-Generation Compaction

Generation 0:  [old raw history .............][recent tail]
Generation 1:  [checkpoint A][recent tail .................]
Generation 2:  [checkpoint B merges A + later history][tail]
Generation n:  [checkpoint N][newest retained tail]

Every replacement advances surface.replaceGeneration, causing pairing and token-pressure projections to update. At the next pressure cycle, checkpoint A has no “never compact” identity; it is simply a user message with provenance. The fixed instruction asks the model to merge an older checkpoint instead of nesting its complete XML framing, but that remains a prompt-level requirement.

12. Overflow Recovery Retries Within the Same Step and Uses Generation Advance as Proof of Progress

A same-Step retry reuses the previously assembled system, tools, and request configuration; the change comes from Session Surface replacement, not a fresh pre-Step assembly. If overflow is dominated by a large system prompt, tool schema, or one indivisible node, Surface compaction may have no legal space to release.

13. Manual /compact Is Idle Maintenance, Not a Concurrent Forced Rewrite

The human command accepts no arguments and maps busy, cancelled, Surface-changed, summary, commit, and persistence failures to distinct results. Success reports shadowed items and tokens and correlates the source command ID with the summary seq. Plugin teardown waits for active handlers to drain. COMPACT-COMMAND

14. Runtime Context Uses Replacement Provenance for Reinjection, with One Conditional Window

The dynamic runtime-context projection remembers the latest owned snapshot still present on Surface. When replacement source seqs shadow that snapshot, the projection clears its retained value. The next project(currentText) therefore emits the current context again, preventing permanent loss after compaction. COMPACT-RUNTIME-PROJECTION

This is a narrow one-request window, not permanent context deletion. Eliminating it would require recomputing the candidate after the waterfall or moving pressure handling before candidate projection.

15. Usage, Pressure, and Shadow Price Are Three Different Observability Surfaces

16. The O(1) Pressure Projection Relies on a Local “Shadow Price Immediately Before Replacement” Protocol

The Surface token projection stores only a running total and one pending claim. A compaction/summary or compaction/prune stages the old price; the next replacement consumes it and applies the signed delta. Any intervening event expires the claim. For historical compatibility, a replacement without a claim degrades to zero delta instead of failing closed.

17. Confirmed Constraints, Gaps, and Deliberate Tradeoffs

These findings should not all be called vulnerabilities. Uncompactable system and tool envelopes are a natural boundary of the Surface seam; partial pruning is a replayable local-progress policy; summary fidelity is the genuine risk surface without a machine-checkable contract.

18. Design Assessment and Verification Status